Complete site-to-site setup
In this recipe, we set up a complete site-to-site network, using most of the built-in security features that OpenVPN offers. It is intended as a "one-stop-shop" example of how to set up a point-to-point network.
Getting ready
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 22 Linux and OpenVPN 2.3.10. We'll use the secret.key
file from the OpenVPN secret keys recipe here.
We will use the following network layout:
Make sure routing (IP forwarding) is configured on both the server and client.
How to do it...
- Create the server configuration file:
dev tun proto udp local openvpnserver.example.com       lport 1194       remote openvpnclient.example.com       rport 1194       secret secret.key 0       ifconfig 10.200.0.1 10.200.0.2       route 192.168.4.0 255.255.255.0       user nobody       group nobody # use "group nogroup" on some distros       persist-tun       persist-key       keepalive 10 60       ping-timer-rem       verb 3       daemon       log-append /tmp/openvpn.log
- Save it asÂ
example1-7-server.conf
. - On the client side, create the configuration file:
       dev tun       proto udp       local openvpnclient.example.com       lport 1194       remote openvpnserver.example.com       rport 1194       secret secret.key 1       ifconfig 10.200.0.2 10.200.0.1       route 172.31.32.0 255.255.255.0       user nobody       group nobody # use "group nogroup" on some distros       persist-tun       persist-key       keepalive 10 60       ping-timer-rem       verb 3       daemon       log-append /tmp/openvpn.log
- Save it asÂ
example1-7-client.conf
. - Then start the tunnel on both ends. The following is for the server end:
[root@server]# openvpn --config example1-7-server.conf
Here's the code for the client end:
[root@client]# openvpn --config example1-7-client.conf
Now our site-to-site tunnel is established.
- Check the log files on both the client and server to verify that the connection has been established.
- After the connection comes up, the machines on the LANs behind both the end points can be reached over the OpenVPN tunnel. For example, when we ping a machine on the client-side LAN from the server, we will see the following:
How it works...
The client and server configuration files are very similar:
- The server listens only on one interface and one UDP port
- The server accepts connections only from a single IP address and port
- The client has these options mirrored
Here is the set of configuration options:
user nobody group nobody persist-tun persist-key keepalive 10 60 ping-timer-rem
These options are used to make the connection more robust and secure, as follows:
The OpenVPN process runs as user nobody
and group nobody
after the initial connection is established. Even if somebody is able to take control of the OpenVPN process itself, he or she would still only be nobody
and not root
. Note that on some Linux distributions, nogroup
is used instead.
The persist-tun
and persist-key
options are used to ensure that the connection comes back automatically if the underlying network is disrupted. These options are necessary when using user nobody
and group nobody
(or group nogroup
).
The keepalive
and ping-timer-rem
options cause OpenVPN to send a periodic "ping" message over the tunnel to ensure that both ends of the tunnel remain up and running.
There's more...
This point-to-point setup can also be used to evade restrictive firewalls. The data stream between the two endpoints is not recognizable and very hard to decipher. When OpenVPN is run in client/server (see Chapter 2, Client-server IP-only Networks), the traffic is recognizable as OpenVPN traffic due to the initial TLS handshake.
See also
- The last recipe in this chapter, Using IPv6, which builds upon this recipe by adding support for IPv6 traffic
- Chapter 7, Troubleshooting OpenVPN - Routing, in which the most common routing issues are explained