In this recipe, we will use the proxy-arp feature of the Linux kernel to make the VPN clients appear as part of the server-side LAN. This eliminates the need to use bridging, which is desirable in most cases.
This recipe uses the PKI files created in the first recipe of this chapter. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9. The client was running Windows 7 64 bit and OpenVPN 2.3.10. For the server, keep the server configuration file, basic-udp-server.conf, from the Server-side routing recipe at hand. For the Windows client, keep the corresponding client configuration file, basic-udp-client.ovpn, from the Using an ifconfig-pool block recipe at hand.
We use the following network layout:
- Create the server config file by adding the following lines to the
basic-udp-server.conffile:script-security 2 client-connect /etc/openvpn/cookbook/proxyarp-connect.sh client-disconnect /etc/openvpn/cookbook/proxyarp-disconnect.sh
Save it as
example2-12-server.conf. - Create the
proxyarp-connect.shscript:#!/bin/bash /sbin/arp -i eth0 -Ds $ifconfig_pool_remote_ip eth0 pub
Then create the
proxyarp-disconnect.shscript:#!/bin/bash /sbin/arp -i eth0 -d $ifconfig_pool_remote_ip
- Make sure that both the scripts are executable:
[root@server]# cd /etc/openvpn/cookbook [root@server]# chmod 755 proxyarp-connect.sh [root@server]# chmod 755 proxyarp-disconnect.sh
- Start the server:
[root@server]# openvpn --config example2-12-server.conf - Then, start the Windows client using the OpenVPN GUI:
After a client has successfully connected, the arp table on the OpenVPN server will have a new entry:
10.198.1.130 * * MP eth0
From a machine on the server-side LAN, we can now ping the VPN client:
[siteBclient]C:> ping 10.198.1.130
Note that no special routing is required on Site B's LAN. The VPN client truly appears as being on the LAN itself.
The proxy-arp feature is supported by most UNIX and Linux kernels. It is used most often for connecting dial-in clients to a LAN, and nowadays, also by ADSL and cable Internet providers. When the OpenVPN client connects, an IP address is borrowed from Site B's LAN range. This IP address is assigned to the OpenVPN client. At the same time, a special ARP entry is made on the OpenVPN server to tell the rest of the network that the OpenVPN server acts as a proxy for 10.198.1.130. This means that when another machine on Site B's LAN wants to know where to find the host with 10.198.1.130, then the OpenVPN server will respond (with its own MAC address).
A proxy-arp setup has its own set of applications as well as challenges. Some of them are listed here:
Note that in this example we did not use:
user nobody group nobody
We did this because it would have prevented the proxyarp-* scripts from working. In order to execute the /sbin/arp command, root privileges are required. Therefore, it is not possible to switch to user nobody after the OpenVPN server has started. Alternatively, one can configure sudo access to the /sbin/arp command to circumvent this.
Sending broadcast traffic over a network where proxy-arp is used is tricky. For most purposes (for example, Windows Network Neighborhood browsing), proxy-arp will work. For some applications that require all the clients to be a member of a full broadcast domain, using proxy-arp might not suffice. In that case, Ethernet bridging is a better solution.
- The Checking broadcast and non-IP traffic recipe from Chapter 3, Client-server Ethernet-style Networks