Handing out the public IPs

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 2Client-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.

Getting ready

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 2Client-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 address
  • 10.0.0.19: Not available
  • 10.0.0.20 -10.0.0.25: Available for VPN clients
  • 10.0.0.26: Not available
  • 10.0.0.27: The LAN address of the OpenVPN server itself
  • 10.0.0.28 -10.0.0.29: Not available
  • 10.0.0.30: The router on the remote LAN

How to do it...

  1. 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 as example10-12-server.conf.

  2. Next, create the proxyarp-connect.sh script:
            #!/bin/bash 
            /sbin/arp -i eth0  -Ds $ifconfig_pool_remote_ip eth0 pub 
            /sbin/ip route add ${ifconfig_pool_remote_ip}/32 dev tun0 
    
  3. Save it as /etc/openvpn/cookbook/proxyarp-connect.sh.
  4. Similarly, create the proxyarp-disconnect.sh script:
            #!/bin/bash 
            /sbin/arp -i eth0  -d $ifconfig_pool_remote_ip 
            /sbin/ip route del ${ifconfig_pool_remote_ip}/32 dev tun0 
    
  5. Save it as /etc/openvpn/cookbook/proxyarp-disconnect.sh.
  6. 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
    
  7. Next, start the client. The IP address assigned to the client should be 10.0.0.20.
  8. Use the client to browse the Internet and check its IP address by surfing, for example, to http://www.whatismyip.com.

How it works...

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 2Client-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.

There's more...

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.

See also

  • The Proxy-ARP recipe from Chapter 2Client-server IP-only Networks, which explains in more detail how the Linux/UNIX Proxy-ARP feature works
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.40.56