This feature allows one or more public IP addresses (and optionally a specific protocol and port number for each IP address) to be NATed at the server into the VPN tunnel and then routed to a specific client.
There are two ways you can setup DMZ in OpenVPN Access Server.
You can created DMZ users through the "User Permissions" page on the Admin UI:
Click on User Permission, click Show next to the user and select Yes under Configure DMZ IP address, then enter the ip address:(tcp or udp)/port number.
You can setup DMZ through the OpenVPN Access Server backend.
The config-key spec (in user properties) is as follows:
dmz_ip.0 : IPAddr[:'tcp'|'udp'/port] dmz_ip.1 : IPAddr[:'tcp'|'udp'/port] ...
For example, suppose we have an unattended client called 'dragonfly'
that runs a web server. We want to expose a public IP address on the AS server (188.8.131.52) that will be NATed to dragonfly.
Add the DMZ IP key:
./confdba -u --prof dragonfly --mod --key dmz_ip.0 --value '184.108.40.206:tcp/80'
If we would like to NAT all traffic to 220.127.116.11 instead of just port 80 traffic, use:
./confdba -u --prof dragonfly --mod --key dmz_ip.0 --value 18.104.22.168
Now restart the server using either the admin UI or:
./sacli -a [user] -p [pw] start
At this point, the DMZ rule should be operational. You should be able to go to http://22.214.171.124 (without a VPN client) and you will be connected to the web server running on the dragonfly client.
A few notes about the implementation:
* We NAT both the source and destination IP addresses.
The destination address is NATed to the VPN IP address of the client (which may be dynamic or static). The source address is NATed to the VPN gateway IP address of the first OpenVPN daemon running on the machine (in the case that more than one daemon is running). So for example, if the VPN dynamic IP subnet is set to 10.8.0.0/24, clients receiving connections via a DMZ address will see it as coming from 10.8.0.1.
* The DMZ IP address may be any IP address that is routed to the AS server machine, and may include IP addresses that are already bound to network interfaces. Further, by using a DMZ IP address with a specific protocol/port defined, only traffic to that protoco/port will be NATed into the VPN tunnel, so if the DMZ IP address is also bound to an interface on the server machine, that interface could still handle other traffic.
* Clients connected to the VPN where reroute_gw is defined will be able to access a DMZ IP address through the tunnel.
* A DMZ IP address will work with a VPN client that uses either a static or dynamic VPN IP address.
* We validate that clients do not declare DMZ IP addresses that conflict with each other.
* This feature makes heavy use of the iptables SNAT, DNAT, and MARK modules.
* We use bit positions 9 through 26 in the iptables packet mark If the DMZ IP feature is not used, only bit position 26 of the packet mark is used. In order to be compatible with the MARK module going back as far as RHEL4, we use --set-mark rather than --and-mark or --or-mark (which were added later). This means that when our iptables logic sets the mark value, it cannot prevent itself from zeroing bits in the packet mark outside the positions
9 through 26 that we actively use.
* This feature, of course, is subject to the limitations of NAT, and will not work with protocols that don't play well with NAT.