Troubleshooting OpenVPN: Routing
There's more...
Windows XP and higher versions include a Run As Administrator service that allows a user to temporarily run a program with a higher privilege level. This mechanism was expanded in Windows Vista/7 and was made the default when launching applications. This has actually been the cause for numerous questions on the openvpn-users mailing list when running OpenVPN on these platforms. The Run As service can also be used on Windows XP, but it works differently than on Windows Vista/7.
See also
Chapter 10, OS Integration, containing recipes on how to integrate OpenVPN into the Microsoft Windows operating system, amongst others.
Troubleshooting client-to-client traffic routing
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.
Getting ready
We use the following network layout:
222
Chapter 8
Install OpenVPN 2.0 or higher on three computers. Make sure the computers are connected over a network. 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 5
Linux and OpenVPN 2.1.1. The first client was running Fedora 13 Linux and OpenVPN 2.1.1.
The second client was running Windows XP SP3 and was running OpenVPN 2.1.1. Keep the configuration file, basic-udp-server.conf, from the Chapter 2 recipe Server-side routing at hand, as well as the client configuration file basic-udp-client.conf from the same recipe. For the Windows XP client, keep the client configuration file basic-udp-client.ovpn from the Chapter 2 recipe Using an 'ifconfig-pool' block at hand.
How to do it...
1.Start the server using the configuration file, basic-udp-server.conf:
[root@server]# openvpn --config basic-udp-server.conf
2.Next, start the Linux client.
[root@client]# openvpn --config basic-udp-client.conf
3.And finally, start the Windows client:
4.Next, try to ping the Windows client from the Linux client (make sure no firewalls are blocking the traffic):
[client]$ ping -c 2 192.168.200.3
PING 192.168.200.3 (192.168.200.3) 56(84) bytes of data.
--- 192.168.200.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.
223
Troubleshooting OpenVPN: Routing
5.At this point, it is instructive to set up iptables logging on the VPN server:
[root@server]# iptables -I FORWARD -i tun+ -j LOG
Then try the 'ping' again. This will result in the following messages in
/var/log/messages:
…openvpnserver kernel: IN=tun0 OUT=tun0 SRC=192.168.200.2 DST=192.168.200.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=192.168.200.2 DST=192.168.200.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 192.168.200.2 is trying to reach the second client 192.168.200.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
How it works...
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.
224
Chapter 8
There's more...
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.
See also
Chapter 3's recipe, Enabling Client-to-Client Traffic, which explains how client-to-client traffic is set up in a TAP-style environment.
Understanding the 'MULTI: bad source' warnings
In this recipe, we focus again on a VPN configuration where we try to connect a client-side
LAN to a server-side LAN. Normally, this is done by adding a client-config-dir directive to the OpenVPN server configuration, and then by adding the appropriate CCD file. However, if the CCD file is not found or is not readable, then the VPN connection will function properly, but the hosts on the client-side LAN will not be able to reach the hosts on the server-side LAN and vice versa. In this case, the OpenVPN server log file will show messages of the form MULTI: bad source, if the verbosity is set high enough.
In this recipe, we will first set up a VPN as is done in the Chapter 2 recipe Routing: subnets on both sides, but with a missing CCD file for the client. Then, we will show how to trigger the
MULTI: bad source warnings and what can be done to resolve the issue.
Getting ready
We use the following network layout:
225
Troubleshooting OpenVPN: Routing
Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. 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 5 Linux and OpenVPN 2.1.1. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the configuration file, basic-udp-server.conf, from the Chapter 2 recipe Server-side routing at hand. For the client, keep the configuration file basic-udp-client.conf Chapter 2 recipe
Server-side routing at hand. .
How to do it...
1.First, make sure the client CCD file is not accessible:
[root@server]# chmod 700 /etc/openvpn/cookbook/clients
2.Start the server using the configuration file, example2-5-server.conf, and with increased verbosity:
[root@server]# openvpn --config example2-5-server.conf --verb 5
3.Next, start the client to connect successfully:
[root@client]# openvpn --config basic-udp-client.conf
…Initialization Sequence Completed
However, when a host on the client-side LAN tries to reach a machine on the server-side LAN, the following message appears in the OpenVPN server log file:
… openvpnclient1/client-ip:58370 MULTI: bad source address from client [192.168.4.66], packet dropped
In this recipe, the root cause of the problem can be resolved as done in the Chapter 7 recipe
Troubleshooting client-config-dir issues: fix the permissions of the directory /etc/openvpn/ cookbook/clients and reconnect the OpenVPN client.
How it works...
In order to connect a remote LAN to an OpenVPN server, two server-configuration directives are needed:
route remote-lan remote-mask
client-config-dir /etc/openvpn/cookbook/clients
And also a CCD file containing the name of the client certificate. The CCD file contains:
iroute remote-lan remote-mask
226