A very common use of a VPN is to route all of the traffic over a secure tunnel. This allows one to safely access a network or even the Internet itself from within a hostile environment (for example, a poorly protected, but properly trojaned Internet caféteria).
In this recipe, we will set up OpenVPN to do exactly this. This recipe is very similar to the Server-side routing recipe, but there are some pitfalls when redirecting all of the traffic over a VPN tunnel.
The network layout used in this recipe is the same as in the Server-side routing recipe.
This recipe uses the PKI files created in the first recipe of this chapter. Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Fedora 20 Linux and OpenVPN 2.3.9. Keep the server configuration file, basic-udp-server.conf, at hand along with the client configuration file, basic-udp-client.conf, from the Server-side routing recipe.
- Create the server configuration file by adding a line to the
basic-udp-server.conffile:push "redirect-gateway def1"
Save it as
example2-7-server.conf. - Start the server:
[root@server]# openvpn --config example2-7-server.conf - In another server terminal, enable IP-traffic forwarding:
[root@server]# sysctl -w net.ipv4.ip_forward=1 - Start the client:
[root@client]# openvpn --config basic-udp-client.confYou will observe something like this:
- After the VPN is established, verify that all of the traffic is going over the tunnel:
The first address in the
tracerouteoutput is the address of the OpenVPN server, hence all of the traffic is routed over the tunnel.
When the client connects to the OpenVPN server, a special redirect statement is pushed out by the server to the OpenVPN client:
push "redirect-gateway def1"
The configuration option def1 tells the OpenVPN client to add three routes to the client operating system:
192.168.96.101 via 192.168.4.1 dev eth0 0.0.0.0/1 via 10.200.0.1 dev tun0 128.0.0.0/1 via 10.200.0.1 dev tun0
The first route is an explicit route from the client to the OpenVPN server via the LAN interface. This route is needed as otherwise all the traffic for the OpenVPN server itself would go through the tunnel.
The other two routes are a clever trick to overrule the default route so that all of the traffic is sent through the tunnel instead of to the default LAN gateway. The existing default route to the LAN gateway is not deleted due to the def1 parameter.
There are many parameters and flags related to the redirect-gateway directive. A subset of these parameters is listed here as well as some other special use cases.
Originally, OpenVPN supported only the following directive:
push "redirect-gateway"
This is used to delete the original default route and replace it with a route to the OpenVPN server. This may seem like a clean solution, but in some cases, OpenVPN was unable to determine the existing default route. This often happened to clients connecting through mobile connections. This also used to create routing lockups, where all of the traffic was routed through the tunnel, including the packets sent by the OpenVPN client itself.
With the current version of OpenVPN, there are several flags for the redirect-gateway directive:
local: This flag tells OpenVPN to not set a direct route from the client to the server. It is useful only if the client and server are in the same LAN, such as when securing wireless networks.block-local: This flag instructs OpenVPN to block all of the network access to the LAN after the VPN tunnel is established. This is achieved by routing all of the LAN traffic into the tunnel itself, except for the traffic to the OpenVPN server itself.bypass-dhcp: This flag adds a direct route to the local DHCP server. If the local DHCP server is on a separate subnet, this will ensure that the DHCP addresses assigned to the non-VPN interfaces will continue to be refreshed. This option is picked up automatically by a Windows client. On other operating systems, a plugin or script is required.bypass-dns: This flag adds a direct route to the local DNS server. In large-scale networks, the DNS server is often not found on the local subnet that the client is connected to. If the route to this DNS server is altered to go through the VPN tunnel after the client has connected, this will cause, at the very least, a serious performance penalty. More likely, the entire DNS server will become unreachable. It is picked up by a Windows client automatically and requires a plugin or script on other operating systems.!ipv4: This flag was added in OpenVPN 2.4 and it instructs OpenVPN to not redirect any IPv4 traffic over the VPN tunnel. It is useful only in combination with the flagipv6. We will go into detail more in the next recipe.ipv6: This flag was added in OpenVPN 2.4 and it instructs OpenVPN to also redirect all IPv6 traffic over the VPN tunnel. We will go into more detail in the next recipe.
Apart from the redirect-gateway directive, OpenVPN has a second, comparatively less well-known, option called redirect-private. This option takes the same parameters as the redirect-gateway directive, but it instructs OpenVPN to make no changes to the default routes at all. It is used most often in combination with the bypass-dhcp, bypass-dns, ipv6, and block-local flags.
In some cases, the redirect-gateway parameter is a bit too restrictive. You might want to add a few routes to local networks and route all other traffic over the VPN tunnel. The OpenVPN route directive has a few special parameters for this:
net_gateway: This is a special gateway representing the LAN gateway address that OpenVPN determined when starting. For example, to add a direct route to the LAN192.168.4.0/24, you would add the following to the client configuration file:route 192.168.4.0 255.255.255.0 net_gateway
vpn_gateway: This is a special gateway representing the VPN gateway address. If you want to add a route that explicitly sends traffic for a particular subnet over the VPN tunnel, overruling any local routes, you would add the following option:route 10.198.0.0 255.255.0.0 vpn_gateway