In this recipe, we will troubleshoot a VPN setup where it is the intention that client-to-client traffic is enabled, but the server configuration directive "client-to-client" is missing. In a TUN-style network, it is possible to allow client-to-client traffic without this directive and it even allows the server administrator to apply firewalling rules to the traffic between clients. In a TAP-style network, this is generally not possible, as will be explained in the There's more... section.
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.11. The first client was running Fedora 22 Linux and OpenVPN 2.3.11. The second client was running Windows 7 64bit and OpenVPN 2.3.11. Keep the configuration file basic-udp-server.conf from the Server-side routing recipe from Chapter 2, Client-server IP-only Networks, as well as the client configuration file basic-udp-client.ovpn from the Using an ifconfig-pool block recipe from Chapter 2, Client-server IP-only Networks.
- Start the server using the configuration file,
basic-udp-server.conf:[root@server]# openvpn --config basic-udp-server.conf - Next, start the Linux client.
[root@client]# openvpn --config basic-udp-client.conf - And finally, start the Windows client:
- Next, try to ping the Windows client from the Linux client (make sure no firewalls are blocking the traffic):
[client]$ ping -c 2 10.200.0.3 PING 10.200.0.3 (10.200.0.3) 56(84) bytes of data. --- 10.200.0.3 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 10999ms
It is possible that the host is already reachable, but in that case the firewall on the server is very permissive.
- At this point, it is instructive to set up
iptableslogging on the VPN server:[root@server]# iptables -I FORWARD -i tun+ -j LOGThen try the ping again. This will result in the following messages in
/var/log/messages:... openvpnserver kernel: IN=tun0 OUT=tun0 SRC=10.200.0.2 DST=10.200.0.3 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=40808 SEQ=1 ... openvpnserver kernel: IN=tun0 OUT=tun0 SRC=10.200.0.2 DST=10.200.0.3 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=40808 SEQ=2
The first client 10.200.0.2 is trying to reach the second client 10.200.0.3. This issue can be resolved by adding the client-to-client configuration directive to the server configuration file and restarting the OpenVPN server, or it can be resolved by allowing tunnel traffic to be forwarded:
[server]# iptables -I FORWARD -i tun+ -o tun+ -j ACCEPT [server]# echo 1 > /proc/sys/net/ipv4/ip_forward
When the first OpenVPN client tries to reach the second client, packets are sent to the server itself. The OpenVPN server does not know how to handle these packets and hands them off to the kernel. The kernel forwards the packets based on whether routing is enabled and whether the firewall rules (iptables) allow it. If not, then the packet is simply dropped and the second client is never reached.
By adding the following directive, the OpenVPN server process deals with the client-to-client traffic internally, bypassing the kernel forwarding, and the firewalling rules:
client-to-client
The alternative solution, which is slightly more secure but also less scalable, is to properly set up routing in the Linux kernel.
In a TAP-style network, the above iptables rule does not work. In a TAP-style network, all the clients are a part of the same broadcast domain. When the client-to-client directive is omitted and a client tries to reach another client, it first sends out arp who has messages to find out the MAC address of the other client. The OpenVPN server will ignore these requests and will also not forward them to other clients, regardless of whether an iptables rule is set or not. Hence, the clients cannot easily reach each other without the client-to-client directive, unless tricks like proxy-ARP are used.
- The Enabling client-to-client traffic recipe, from Chapter 3, Client-server Ethernet-style Networks, which explains how client-to-client traffic is set up in a TAP-style environment