- •Credits
- •About the Author
- •About the Reviewers
- •www.PacktPub.com
- •Table of Contents
- •Preface
- •Introduction
- •Shortest setup possible
- •OpenVPN secret keys
- •Multiple secret keys
- •Plaintext tunnel
- •Routing
- •Configuration files versus the command-line
- •Complete site-to-site setup
- •3-way routing
- •Introduction
- •Setting up the public and private keys
- •Simple configuration
- •Server-side routing
- •Routing: subnets on both sides
- •Redirecting the default gateway
- •Using an 'ifconfig-pool' block
- •Using the status file
- •Management interface
- •Proxy-arp
- •Introduction
- •Simple configuration—non-bridged
- •Enabling client-to-client traffic
- •Bridging—Linux
- •Bridging—Windows
- •Checking broadcast and non-IP traffic
- •External DHCP server
- •Using the status file
- •Management interface
- •Introduction
- •Certificate generation
- •xCA: a GUI for managing a PKI (Part 1)
- •xCA: a GUI for managing a PKI (Part 2)
- •OpenSSL tricks: x509, pkcs12, verify output
- •Revoking certificates
- •The use of CRLs
- •Checking expired/revoked certificates
- •Intermediary CAs
- •Multiple CAs: stacking, using --capath
- •Introduction
- •Initializing a hardware token
- •Getting a hardware token ID
- •Using a hardware token
- •Selecting a PKCS#11 certificate using the management interface
- •Generating a key on the hardware token
- •Private method for getting a PKCS#11 certificate
- •Pin caching example
- •Introduction
- •Using a client-side up/down script
- •Windows login greeter
- •Using client-connect/client-disconnect scripts
- •Using a 'learn-address' script
- •Using a 'tls-verify' script
- •Using an 'auth-user-pass-verify' script
- •Script order
- •Script security and logging
- •Using the 'down-root' plugin
- •Using the PAM authentication plugin
- •Introduction
- •Cipher mismatches
- •TUN versus TAP mismatches
- •Compression mismatches
- •Key mismatches
- •Troubleshooting MTU and tun-mtu issues
- •Troubleshooting network connectivity
- •How to read the OpenVPN log files
- •Introduction
- •The missing return route
- •Missing return routes when 'iroute' is used
- •Source routing
- •Routing and permissions on Windows
- •Troubleshooting client-to-client traffic routing
- •Understanding the 'MULTI: bad source' warnings
- •Failure when redirecting the default gateway
- •Introduction
- •Optimizing performance using 'ping'
- •OpenSSL cipher speed
- •Compression tests
- •Traffic shaping
- •Tuning UDP-based connections
- •Tuning TCP-based connections
- •Analyzing performance using tcpdump
- •Introduction
- •Linux: using NetworkManager
- •MacOS: using Tunnelblick
- •Windows Vista/7: elevated privileges
- •Windows: using the CryptoAPI store
- •Windows: updating the DNS cache
- •Windows: running OpenVPN as a service
- •Windows: public versus private network adapters
- •Windows: routing methods
- •Introduction
- •Including configuration files in config files
- •Details of ifconfig-pool-persist
- •Connecting using a SOCKS proxy
- •Connecting via an HTTP proxy
- •Connecting via an HTTP proxy with authentication
- •Using dyndns
- •IP-less setups (ifconfig-noexec)
- •Introduction
- •Inline certificates
- •Connection blocks
- •Port sharing with an HTTPS server
- •Routing features: redirect-private, allow-pull-fqdn
- •OCSP support
- •New for 2.2: the 'x509_user_name' parameter
- •Index
Chapter 8
Missing return routes when 'iroute' is used
This recipe is a continuation of the previous one. After ensuring that a single VPN client can reach the server-side LAN, the next step is to make sure that other hosts behind the VPN client can reach the hosts on the server side LAN.
In this recipe, we will first set up a VPN as is done in the Chapter 2 recipe Routing: subnets on both sides. If no return routes are set up, then the hosts on the client-side LAN will not be able to reach the hosts on the server-side LAN and vice versa. By adding the appropriate routes, the issue is resolved.
Getting ready
We use the following network layout:
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, example2-5-server.conf, from the Chapter 2 recipe, Routing: subnets on both sides, at hand, as well as the client configuration, basic-udp-client.conf, from the
Chapter 2 recipe Server-side routing.
How to do it...
1.Start the server:
[root@server]# openvpn --config example2-5-server.conf
2.Next, start the client:
[root@client]# openvpn --config basic-udp-client.conf
…Initialization Sequence Completed
211
Troubleshooting OpenVPN: Routing
3.At this point, it is possible to ping the remote VPN IP and all the interfaces that are on the VPN server itself, and vice versa:
[client]$ ping -c 2 192.168.200.1
PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
64 bytes from 192.168.200.1: icmp_seq=1 ttl=64 time=25.2 ms 64 bytes from 192.168.200.1: icmp_seq=2 ttl=64 time=25.1 ms
[client]$ ping -c 2 10.198.0.10
PING 10.198.0.1 (10.198.0.10) 56(84) bytes of data.
64 bytes from 10.198.0.10: icmp_seq=1 ttl=64 time=24.7 ms 64 bytes from 10.198.0.10: icmp_seq=2 ttl=64 time=25.0 ms
[server]$ ping -c 2 192.168.200.2
PING 192.168.200.2 (192.168.200.2) 56(84) bytes of data.
64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=25.0 ms 64 bytes from 192.168.200.2: icmp_seq=2 ttl=64 time=24.6 ms
[server]$ ping -c 2 192.168.4.64
PING 192.168.4.64 (192.168.4.64) 56(84) bytes of data.
64 bytes from 192.168.4.64: icmp_seq=1 ttl=64 time=25.2 ms 64 bytes from 192.168.4.64: icmp_seq=2 ttl=64 time=24.3 ms
4.The routing table on the server shows that the remote network is routed correctly:
[server]$ netstat -rn | grep tun0
192.168.4.0 192.168.200.1 255.255.255.0 UG 0 0 0 tun0
192.168.200.0 0.0.0.0 |
255.255.255.0 U 0 0 0 tun0 |
5.When we try to ping a remote host on the server-side LAN it fails, as it was the case in the previous recipe. Vice versa, when we try to ping a client-side LAN host from a host on the server-side LAN, we see:
[siteB-host]$ ping -c 2 192.168.4.66
PING 192.168.4.66 (192.168.4.66) 56(84) bytes of data.
--- 192.168.4.66 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
6.By adding the appropriate routes on the gateways at both the sides, the routing is restored. First, the gateway on the server-side LAN:
[gateway1]> ip route add 192.168.4.0/24 via 10.198.0.10
Here, 10.198.0.10 is the LAN IP address of the VPN server.
212
Chapter 8
7.Next, the gateway/router on the client-side LAN:
[gateway2]> ip route add 10.198.0.0/16 via 192.168.4.64
Here, 192.168.4.64 is the LAN IP address of the VPN client.
After this, the hosts on the LANs can reach other.
How it works...
Similar to the previous recipe, when a host on the Site A's LAN attempts to make a connection to a host on the Site B's LAN packets that are sent with a source and destination IP address:
Source IP = 192.168.4.64 : Site A's LAN address
Destination IP = 10.198.1.12: Site B's LAN address
The remote host will want to reply with a packet with the source and destination IP addresses swapped. When the remote host wants to send the packet, it forwards the packet to the
LAN gateway. However, the LAN gateway also does not know where to return the packets to, and will forward them out to its default gateway. When the packets reach a router that is
connected directly to the Internet then the router usually will decide to drop (throw away) the packets, causing the host to become unreachable.
A similar problem occurred in the previous recipe, but now the IP addresses of the packets are the actual Site A's and Site B's LAN IP addresses.
By adding the appropriate routes on both the sides, the problem is alleviated.
When troubleshooting this sort of routing issue, it is very important to start at the innermost network (the actual VPN, in this case) and then work your way outwards:
First make sure the VPN endpoints can see each other
Make sure the VPN client can reach the server LAN IP and vice versa
Make sure the VPN client can reach a host on the server-side LAN
Make sure a host on the server-side LAN can see the VPN client
Make sure a host on the client-side LAN can see the VPN server
Finally, make sure a host on the client-side LAN can see a host on the server-side LAN and vice versa
There's more...
Again, a quick and a dirty solution to the above issue is outlined in the Chapter 2's recipe
Server-side routing. In that recipe, masquerading is used to make it appear as if all the traffic is coming from the OpenVPN server itself. Especially, when connecting subnets over a VPN this is not advisable, as masquerading makes it impossible to tell which client is connecting to which server and vice versa. Therefore, a fully-routed setup is preferred in this case.
213
Troubleshooting OpenVPN: Routing
See also
Chapter 2's recipe, Routing: subnets on both sides, which explains in detail how to set up routing on both the client and the server side.
All clients function except the
OpenVPN endpoints
This recipe is again a continuation of the previous one. The previous recipe explained how to troubleshoot routing issues when connecting a client-side LAN (or subnet) to a server-side
LAN. However, in the previous recipe, an omission in the routing configuration was made on purpose. In this recipe, we will focus on troubleshooting this quite common omission.
Getting ready
We use the following network layout:
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, example2-5-server.conf, from the Chapter 2 recipe Routing: subnets on both sides at hand, as well as the client configuration, basic-udp-client.conf, from the
Chapter 2 recipe Server-side routing.
How to do it...
1.Start the server:
[root@server]# openvpn --config example2-5-server.conf
214
Chapter 8
2.Next, start the client:
[root@client]# openvpn --config basic-udp-client.conf
…Initialization Sequence Completed
3.Add the appropriate routes on the gateways at both the sides:
[gateway1]> ip route add 192.168.4.0/24 via 10.198.0.10 [gateway2]> ip route add 10.198.0.0/16 via 192.168.4.64
After this, all the hosts on the LANs can reach other.
4.We verify this by pinging various machines on the LANs on either of the sides:
[client]$ ping -c 2 10.198.0.10 [server]$ ping -c 2 192.168.4.64 [siteA-host]$ ping -c 2 10.198.0.1 [siteB-host]$ ping -c 2 192.168.4.66
All of them work. However, when the VPN server tries to ping a host on the client-side LAN, it fails:
[server]$ ping -c 2 192.168.4.66
PING 192.168.4.66 (192.168.4.66) 56(84) bytes of data.
--- 192.168.4.66 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1009ms
Similarly, the client can only reach the LAN IP of the server and not any of the other hosts.
5.On Linux and UNIX hosts, it is possible to explicitly specify the source IP address:
[server]$ ping -I 10.198.0.10 -c 2 192.168.4.66
PING 192.168.4.66 (192.168.4.66) 56(84) bytes of data.
64 bytes from 192.168.4.66: icmp_seq=1 ttl=63 time=25.5 ms 64 bytes from 192.168.4.66: icmp_seq=2 ttl=63 time=24.3 ms
That works! So, there is a problem with the source address of the packets.
6.By adding an extra route for the VPN subnet itself, to the gateways on both the ends, this issue is resolved:
[gateway1]> ip route add 192.168.200.0/24 via 10.198.0.10 [gateway2]> ip route add 192.168.200.0/24 via 192.168.4.64
215
Troubleshooting OpenVPN: Routing
7.Now, the VPN server can reach all the hosts on the client's subnet and vice versa:
[server]$ ping -c 2 192.168.4.66
PING 192.168.4.66 (192.168.4.66) 56(84) bytes of data.
64 bytes from 192.168.4.66: icmp_seq=1 ttl=63 time=25.3 ms 64 bytes from 192.168.4.66: icmp_seq=2 ttl=63 time=24.9 ms
How it works...
To troubleshoot issues like these, it is very handy to write out all the source addresses and the destination addresses of the LANs involved. In this case, the problem occurs when the VPN server wants to connect to a host on the client-side LAN. On the VPN server, the packet that is sent to the client-side host is sent out of the VPN interface directly. Therefore, the source address of this packet is set to the IP address of the VPN interface itself. Thus, the packet has the following IP addresses:
Source IP = 192.168.200.1: VPN server's IP address
Destination IP = 192.168.4.66: Site A's LAN address
The remote host will want to reply with a packet with the source and destination IP addresses swapped. When the remote host wants to send the packet, it forwards the packet to the
LAN gateway. However, the LAN gateway also does not know where to return the packets to, and will forward them out to its default gateway. When the packets reach a router that is connected directly to the Internet that router usually will decide to drop (throw away) the packets, causing the host to become unreachable.
This problem occurs only on the VPN server and VPN client. On all other hosts on the client-side and server-side LAN, the LAN IP address is used and routing works as configured in the previous recipe.
By adding the appropriate routes on both the sides the problem is resolved.
There's more...
A good use of NAT'ing in this recipe would be to remove any references to the VPN IP range from the routing tables. This can be done by just masquerading the VPN endpoint addresses. If this is done, the extra routes are no longer needed on the gateways on both the LANs. For example, by adding a NAT'ing rule on the server:
[root@server]# iptables -t nat -I POSTROUTING -i tun0 -o eth0 \
-s 192.168.200.0/24 -j MASQUERADE
216