In this recipe, we will configure a bridged OpenVPN server so that it uses an external DHCP server to assign addresses to the OpenVPN clients to further increase the integration of remote clients with the clients already present on the server-side LAN.
We use the following network layout:
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.10. The client was running Windows 7 64 bit and OpenVPN 2.3.10. For this client, keep the client configuration file example3-2-client2.ovpn from the Enabling client-to-client traffic recipe at hand.
- Create the server configuration file:
proto udp port 1194 dev tap0 server-bridge push "route 0.0.0.0 255.255.255.255 net_gateway" 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 user nobody group nobody # use "group nogroup" on some distros daemon log-append /var/log/openvpn.log
- Save it as
example3-6-server.conf. - Start the server:
[root@server]# openvpn --config example3-6-server.conf - Start the Windows client:
- After the VPN connection is established, verify the IP address and the routing tables:
[WinClient]C:> ipconfig /all [...] Ethernet adapter tapwin32-0 Connection-specific DNS Suffix . : lan Description . . . . . . . . . . . : TAP-Win32 Adapter V9 Physical Address. . . . . . . . . : 00-FF-17-82-55-DB Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.4.66 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.4.254 DHCP Server . . . . . . . . . . . : 192.168.4.254 DNS Servers . . . . . . . . . . . : 192.168.4.254 [...] [WinClient]C:> netstat -rn [...] 0.0.0.0 0.0.0.0 192.168.3.1 192.168.3.22 10 0.0.0.0 255.255.255.255 192.168.3.1 192.168.3.22 1 0.0.0.0 0.0.0.0 192.168.4.254 192.168.4.66 1 Default Gateway: 192.168.3.1 [...]
- And finally, check that we can reach other hosts in the server-side LAN:
[WinClient]C:> ping 192.168.4.64 Pinging 192.168.4.64 with 32 bytes of data: Reply from 192.168.4.64: bytes=32 time=3ms TTL=64 Reply from 192.168.4.64: bytes=32 time=1ms TTL=64 Reply from 192.168.4.64: bytes=32 time=1ms TTL=64 Reply from 192.168.4.64: bytes=32 time<1ms TTL=64
Here is the server directive:
server-bridge
Without any parameters, this directive instructs OpenVPN to not allocate a pool of IP addresses for the clients. So, all of the incoming DHCP requests from the clients are forwarded out over the bridge. The DHCP server on the server-side LAN then replies with an IP address.
The tricky part here is that the DHCP server almost always also returns a default gateway, which will be the LAN gateway. If a remote client sets its default gateway to the gateway of the LAN, funny things will happen, as in most cases the direct route to the OpenVPN server will be lost.
The following directive instructs the OpenVPN client to add an explicit default route via the net_gateway, which is always the LAN gateway at the client side:
push "route 0.0.0.0 255.255.255.255 net_gateway"
For Windows clients, this trick works and the default gateway remains intact.
For Linux clients, it is easier to tweak the dhclient and network-scripts settings. However, this is distribution-dependent.
With the default gateway intact, the OpenVPN client is properly assigned an address from the DHCP server on the server side.
When using an external DHCP setup, keep in mind the following.
The proper solution is to configure the DHCP server such that DHCP requests from the VPN clients do not get a default gateway assigned. This adds a burden to the administration of the server-side DHCP server.
In this case, it also makes sense to explicitly set a unique MAC address in each client configuration file using the following, for example:
lladdr CA:C6:F8:FB:EB:3B
On Linux, the MAC address is computed randomly when the TAP interface comes up, so each time the OpenVPN client is stopped and started, a new IP address is allocated. It is also possible to create a permanently fixed, static MAC address by using the system configuration scripts to bring up the TAP device before OpenVPN is started.
It is also possible to use an external DHCP server without using bridging. If the TAP adapter is configured before OpenVPN is started and the server configuration file from this recipe is used, then an external DHCP server can be used using the Linux dhrelay command:
[root@server]# dhrelay -i tap0 -i eth0
Make sure to list both the TAP adapter and the Ethernet adapter to which the external DHCP server is connected. By combining this with a proxy-arp script (see the
Proxy ARP recipe from Chapter 2, Client-server IP-only Networks), it eliminates the need to use bridging in most cases.
On RedHat, Fedora, and OpenSuSE-based systems, the TAP adapter is brought up using a script /etc/sysconfig/network-scripts/ifup-tap0 and the following command:
[root@client]# /sbin/ifup tap0
By adding the line to the /etc/sysconfig/network-scripts/ifup-tap0 file, the dhclient script ignores the gateway that is assigned from the DHCP server:
GATEWAYDEV=eth0
A similar hack can be developed for Debian/Ubuntu-based systems.