With the topology subnet feature that OpenVPN offers, it becomes feasible to hand out public IP addresses to connecting clients. For this recipe, we will show how such a setup can be realized. We will re-use a technique from the Proxy-ARP recipe from Chapter 2, Client-server IP-only Networks, to make the VPN clients appear as if they are a part of the remote network. If a dedicated IP address block is available for the VPN clients, then this is not required. The advantage of using the proxy-arp method is that it allows us to use only part of an expensive public IP address block.
For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.12. The client computer was running Windows 7 64 bit and OpenVPN 2.3.11. Keep the client configuration file, basic-udp-client.ovpn, from the Using an ifconfig-pool block recipe from Chapter 2, Client-Server IP-Only Networks.
To test this recipe, a public IP address block of 16 addresses was used, but here, we will list a private address block instead (10.0.0.0/255.255.255.240). This block is used as follows:
10.0.0.18: This is used for the server's VPN IP address10.0.0.19: Not available10.0.0.20-10.0.0.25: Available for VPN clients10.0.0.26: Not available10.0.0.27: The LAN address of the OpenVPN server itself10.0.0.28-10.0.0.29: Not available10.0.0.30: The router on the remote LAN
- Create the server configuration file:
mode server tls-server proto udp port 1194 dev tun ifconfig 10.0.0.18 255.255.255.240 ifconfig-pool 10.0.0.20 10.0.0.25 push "route 10.0.0.27 255.255.255.255 net_gateway" push "route-gateway 10.0.0.30" push "redirect-gateway def1" tls-auth /etc/openvpn/cookbook/ta.key 0 ca /etc/openvpn/cookbook/ca.crt cert /etc/openvpn/cookbook/server.crt key /etc/openvpn/cookbook/server.key dh /etc/openvpn/cookbook/dh2048.pem persist-key persist-tun keepalive 10 60 topology subnet push "topology subnet" script-security 2 client-connect /etc/openvpn/cookbook/proxyarp-connect.sh client-disconnect /etc/openvpn/cookbook/proxyarp-disconnect.sh #user nobody #group nobody daemon log-append /var/log/openvpn.log
Note that this server configuration cannot be run as user
nobody. Save the configuration file asexample10-12-server.conf. - Next, create the
proxyarp-connect.shscript:#!/bin/bash /sbin/arp -i eth0 -Ds $ifconfig_pool_remote_ip eth0 pub /sbin/ip route add ${ifconfig_pool_remote_ip}/32 dev tun0 - Save it as
/etc/openvpn/cookbook/proxyarp-connect.sh. - Similarly, create the
proxyarp-disconnect.shscript:#!/bin/bash /sbin/arp -i eth0 -d $ifconfig_pool_remote_ip /sbin/ip route del ${ifconfig_pool_remote_ip}/32 dev tun0 - Save it as
/etc/openvpn/cookbook/proxyarp-disconnect.sh. - Make sure that both the scripts are executable, then start the server:
[root@server]# cd /etc/openvpn/cookbook [root@server]# chmod 755 proxy-connect.sh proxy-disconnect.sh [root@server]# openvpn --config example10-12-server.conf
- Next, start the client. The IP address assigned to the client should be
10.0.0.20. - Use the client to browse the Internet and check its IP address by surfing, for example, to http://www.whatismyip.com.
Some notes on the server configuration file, the directives:
ifconfig 10.0.0.18 255.255.255.240 ifconfig-pool 10.0.0.20 10.0.0.25
Set up a pool of (public) IP address for the clients to use. Because not all of these addresses are available in the /28 block, we cannot simply use:
server 10.0.0.18 255.255.255.240
The next statement is to ensure that the VPN server itself is reached via the regular network and not via the VPN tunnel itself:
push "route 10.0.0.27 255.255.255.255 net_gateway"
In order to redirect all traffic via the VPN tunnel, we need to explicitly state the new default gateway and redirect-gateway:
push "route-gateway 10.0.0.30" push "redirect-gateway def1"
Normally, the following statement will also cause the topology setting to be pushed to the VPN clients:
topology subnet
But, as we're not using the server directive, this does not happen automatically. By explicitly pushing the topology, we ensure that the clients will also use the correct settings.
The client-connect and client-disconnect scripts are very similar to the ones used in the Proxy-ARP recipe from Chapter 2, Client-server IP-only Networks. By using a handy feature of the Linux arp command, we can make the remote clients appear to be part of the local network.
The topology subnet feature was introduced in OpenVPN 2.1 and is essential to making this recipe practical. Without this feature, each client would be handed out a miniature /30 network, which means that each client would use up to four public IP addresses. This made the deployment of handing out public IP addresses to VPN clients very expensive.
- The Proxy-ARP recipe from Chapter 2, Client-server IP-only Networks, which explains in more detail how the Linux/UNIX Proxy-ARP feature works