OpenVPN offers several options to monitor the clients connected to a server. The most commonly used method is using a status file. This recipe will show how to use and read the OpenVPN status file. We will also focus on some subtleties of the status file in a TAP-style setup.
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 first client was running Fedora 20 Linux and OpenVPN 2.3.10. The second client was running Windows 7 64 bit and OpenVPN 2.3.10. For the Linux client, keep the client configuration file example3-1-client.conf at hand. For the Windows client, keep the client configuration file example3-2-client2.ovpn at hand.
- Create the server configuration file by adding a line to the
example3-1-server.conf.file:status /var/log/openvpn.status
Save it as
example3-7-server.conf. - Start the server:
[root@server]# openvpn --config example3-7-server.conf - First, start the Linux client using the configuration file from the earlier recipe and ping a host on the remote network:
[root@client1]# openvpn --config example3-1-client.conf [root@client1]# ping 10.198.0.1
- After the VPN is established, list the contents of the
openvpn.statusfile (as user root):[root@server]# cat /var/log/openvpn.status OpenVPN CLIENT LIST Updated,Wed Mar 2 17:34:39 2016 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since client1,192.168.4.65:50183,10024,10159,Wed Mar 2 17:26:48 2016 ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref 5e:52:73:5c:6a:ce,client1,192.168.4.65:50183,Wed Mar 2 17:27:06 2016 GLOBAL STATS Max bcast/mcast queue length,1 END
- Start the Windows client:
- Ping a host on the remote network:
[WinClient2]C:> ping 10.198.0.1 - List the contents of the status file again on the server:
[root@server]# cat /var/log/openvpn.status OpenVPN CLIENT LIST Updated,Wed Mar 2 17:40:22 2016 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since client1,192.168.4.65:50183,10024,10159,Wed Mar 2 17:27:08 2016 client2,192.168.4.64:50186,18055,9726,Wed Mar 2 17:26:48 2016 ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref 5e:52:73:5c:6a:ce,client1,192.168.4.65:50183,Wed Mar 2 17:27:06 2016 00:ff:17:82:55:db,client2,192.168.4.64:50186,Wed Mar 2 17:27:16 2016 GLOBAL STATS Max bcast/mcast queue length,1 END
Each time a client connects to the OpenVPN server, the status file is updated with the connection information. The OPENVPN CLIENT LIST and ROUTING TABLE tables are the most interesting tables, as they show the following:
- Which clients are connected
- From which IP address the clients are connecting
- The number of bytes each client has received and transferred
- The time at which the client connected
The routing table also shows which networks are routed to each client. This routing table is filled when clients start sending traffic that needs to be routed. The ping commands in the recipe were used to trigger the routing table entries.
When comparing this example with a TUN-style setup there are many similarities but also some differences:
The major difference in the status file when using a TAP-style network compared to a TUN-style network (see the Using the status file recipe from Chapter 2, Client-server IP-only Networks) is in the ROUTING TABLE. The recipe from the previous chapter shows this:
10.200.0.2,client1,192.168.4.65:56764,<Date>
Whereas, in this recipe, we see the following:
5e:52:73:5c:6a:ce,client1,192.168.4.65:50183,<Date>
The address 5e:52:73:5c:6a:ce is the randomly chosen MAC address of the tap adapter on the client1 machine.
Note that when a client disconnects, the status file is not updated immediately. OpenVPN first tries to reconnect to the client based on the keepalive parameters in the server configuration file. The server configuration file in this recipe uses this:
keepalive 10 60
This tells the server that it will ping the client every 10th second. The OpenVPN server will double the second argument: if it does not get a response after 2 * 60 seconds, the connection is restarted. The server will also tell the client to ping the server every 10 seconds and to restart the connection after 60 seconds if it does not get any response.
If the client explicitly closes the connection using the explicit-exit-notify directive or when a TCP-based setup is used, the server does not wait for ping responses from the client.
- The Using the status file recipe from Chapter 2, Client-server IP-only Networks, which explains how the status file can be configured and used for IP-only style networks