3

Though the VPN client successfully connects to the OpenVPN server, it seems to be setting an incorrect and bogus gateway no matter what permutations of push "redirect-gateway local def1" and/or push "route 10.240.0.0 255.255.0.0" are placed/commented/uncommented in the server.conf file.

The server.conf file has this declaration server 10.8.0.0 255.255.255.0, and indeed the server gets assigned 10.8.0.1, but for some reason the client interprets messages sent during the VPN initiation that it should route traffic through a default gateway is assigned at 10.8.0.5. According to Wireshark any subsequent packets get sent to 10.8.0.5 and never receive any responses, as though these packets make it to the VPN TCP endpoint, it seems they never make it to the server's tun0 interface (acording to tcpdump on the server.

Here are the relevant lines of the OpenVPN client (Tunnelblick) log indicating the routing table change immediately after successfully connecting to the VPN:

2015-12-11 02:25:18 /sbin/ifconfig utun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
2015-12-11 02:25:18 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -d -f -m -w -pxxxxxxxxxxx utun0 1500 1543 10.8.0.6 10.8.0.5 init
                                        **********************************************
                                        Start of output from client.up.tunnelblick.sh
                                        No network configuration changes need to be made.
                                        Will NOT monitor for other network configuration changes.
                                        DNS servers '8.8.8.8 208.67.222.222' will be used for DNS queries when the VPN is active
                                        The DNS servers include only free public DNS servers known to Tunnelblick.
                                        Flushed the DNS cache via dscacheutil
                                        /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
                                        Notified mDNSResponder that the DNS cache was flushed
                                        End of output from client.up.tunnelblick.sh
                                        **********************************************
                                        add net 104.196.7.35: gateway 192.168.0.1
                                        add net 0.0.0.0: gateway 10.8.0.5
                                        add net 128.0.0.0: gateway 10.8.0.5
                                        add net 10.240.0.0: gateway 10.8.0.5
                                        add net 10.8.0.0: gateway 10.8.0.5
2015-12-11 02:25:20 Initialization Sequence Completed

Is there any way I can force OpenVPN to send the correct information to the client? Or am I wrong and is there another reason packets correctly sent to the OpenVPN TCP port are not making it to the tun0 interface on the OpenVPN server?

Improve this question

1 Answer 1

Reset to default
4

No, this is correct.

Your OpenVPN works in "net30" topology mode. In this mode OpenVPN process itself is a router. In reality virtual network schema looks like this:

                                   Client3
                                 10.8.0.14/30
                                    |
                                 10.8.0.13/30
Server 10.8.0.1/30 --- 10.8.0.2/30 OpenVPN 10.8.0.5/30 --- 10.8.0.6/30 Client1
                                 10.8.0.9/30
                                    |
                                 10.8.0.10/30
                                   Client2

with everyone including the server having additional route 10.8.0.0/24 via 10.8.0.x (x - their respective inside-OpenVPN next hop address).

I.e. 10.8.0.5 is really an address of OpenVPN router, it is "hidden inside a process". This is required if you want to join Windows into your VPN, as in Windows is not possible to create real TUN interface and it is emualted with TAP and the setup above.

This is also the reason for "iroute" option existence. It is used to set up routes inside this virtual router.

If your never ever want to include Windows clients into your VPN, you could set up topology mode to p2p and have expected direct .1 routes on clients.

Please, refer to OpenVPN manual https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage topology mode section for details.

Improve this answer
1
  • Ah that makes sense! Also in case anyone has the same issue where packets never made it over to the tunnel interface on their Open VPN server and came back corrupt on the tunnel interface on their client, it turned out I had the line comp-lzo in my server.conf but not in my client configuration. Because the client was not expecting the compression, the interface received compressed packets without the necessary interpretation. Removing this from my server.conf solved the problem.
    – Eternal Rubyist
    Jan 3, 2016 at 19:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .