Ubuntu vs. Windows VPN routing behavior

Question

Both my home and workplace networks are the same (subnet 10.0.0.x).

When I configure a VPN connection on my Windows 7 machine (PPTP), I can ping any server that is located at my workplace without any static routes involved.

On the other hand, when configuring the same VPN connection on my Ubuntu 14.04 machine, I can't make any connection with the remote network util a static route is created for a specific host on the other network through the tunnel.

I was trying to figure out what was happening on Windows and found the following:

There is a second Default Gateway that leads all traffic to the tunnel, here's the route print output:

Network Destination      Netmask         Gateway       Interface   Metric
        0.0.0.0          0.0.0.0       10.0.0.138         10.0.0.9   4255
        0.0.0.0          0.0.0.0         On-link    192.168.88.102     31
       10.0.0.0    255.255.255.0         On-link          10.0.0.9   4511
       10.0.0.9  255.255.255.255         On-link          10.0.0.9   4511
     10.0.0.255  255.255.255.255         On-link          10.0.0.9   4511
      127.0.0.0        255.0.0.0         On-link         127.0.0.1   4531
      127.0.0.1  255.255.255.255         On-link         127.0.0.1   4531
127.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
 192.168.88.102  255.255.255.255         On-link    192.168.88.102    286
 x.x.x.x         255.255.255.255       10.0.0.138         10.0.0.9   4256
      224.0.0.0        240.0.0.0         On-link         127.0.0.1   4531
      224.0.0.0        240.0.0.0         On-link          10.0.0.9   4514
      224.0.0.0        240.0.0.0         On-link    192.168.88.102     31
255.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
255.255.255.255  255.255.255.255         On-link          10.0.0.9   4511
255.255.255.255  255.255.255.255         On-link    192.168.88.102    286

192.168.88.102 is my IP over the tunnel, 10.0.0.9 is my local IP, 10.0.0.138 is my router, and x.x.x.x is the VPN server public IP.

tracert output:

for the first time:

    tracert -d 10.0.0.83

    Tracing route to 10.0.0.83 over a maximum of 30 hops

    1  10.0.0.9  reports: Destination host unreachable.

    Trace complete.

and for the second time:

    tracert -d 10.0.0.83

    Tracing route to 10.0.0.83 over a maximum of 30 hops

    1    42 ms    33 ms    53 ms  192.168.88.1
    2    35 ms    31 ms    33 ms  10.0.0.83

    Trace complete.

relevant arp output:

remote address:

    arp -a | findstr 10.0.0.83
    10.0.0.83                                   static

local address:

    arp -a | findstr 10.0.0.14
    10.0.0.14             b8-27-eb-37-38-a4     dynamic

while on Ubuntu the default routing list is:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.138      0.0.0.0         UG        0 0          0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 wlan0
192.168.88.1    0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
x.x.x.x         10.0.0.138      255.255.255.255 UGH       0 0          0 wlan0
x.x.x.x         10.0.0.138      255.255.255.255 UGH       0 0          0 wlan0

Adding another default gateway didn't do the trick.

What is the explanation for this behavior and how can I make this happen in Ubuntu?

EDIT:

I'm using the built-in VPN client of Ubuntu (NetworkManager) which is running under root according to syslog. Also, tried adding static routes in the IPv4 Settings configuration panel of the VPN plugin which seemed successful in adding them to the routing table but not acting as Windows does.

Here's the Ubuntu /var/log/syslog from the moment the connection is initiated:

     May 29 16:49:56 hostname wpa_supplicant[823]: wlan0: CTRL-EVENT-SCAN-STARTED 
     May 29 16:49:57 hostname wpa_supplicant[823]: nl80211: send_and_recv->nl_recvmsgs failed: -33
     May 29 16:50:15 hostname NetworkManager[757]: <info> Starting VPN service 'pptp'...
     May 29 16:50:15 hostname NetworkManager[757]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 5123
     May 29 16:50:15 hostname NetworkManager[757]: <info> VPN service 'pptp' appeared; activating connections
     May 29 16:50:15 hostname NetworkManager[757]: <info> VPN plugin state changed: starting (3)
     May 29 16:50:15 hostname pppd[5127]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded.
     May 29 16:50:15 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (Connect) reply received.
     May 29 16:50:15 hostname pppd[5127]: pppd 2.4.5 started by root, uid 0
     May 29 16:50:15 hostname pppd[5127]: Using interface ppp0
     May 29 16:50:15 hostname pppd[5127]: Connect: ppp0 <--> /dev/pts/7
     May 29 16:50:15 hostname NetworkManager[757]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
     May 29 16:50:15 hostname NetworkManager[757]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
     May 29 16:50:15 hostname NetworkManager[757]: <warn> /sys/devices/virtual/net/ppp0: couldn't determine device driver; ignoring...
     May 29 16:50:15 hostname pptp[5132]: nm-pptp-service-5123 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
     May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
     May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
     May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
     May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
     May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
     May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 61002).
     May 29 16:50:16 hostname pppd[5127]: CHAP authentication succeeded
     May 29 16:50:16 hostname pppd[5127]: MPPE 128-bit stateless compression enabled
     May 29 16:50:18 hostname pppd[5127]: local  IP address 192.168.88.102
     May 29 16:50:18 hostname pppd[5127]: remote IP address 192.168.88.1
     May 29 16:50:18 hostname pppd[5127]: primary   DNS address 10.0.0.2
     May 29 16:50:18 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (IP4 Config Get) reply received from old-style plugin.
     May 29 16:50:18 hostname NetworkManager[757]: <info> VPN Gateway: x.x.x.x
     May 29 16:50:18 hostname NetworkManager[757]: <info> Tunnel Device: ppp0
     May 29 16:50:18 hostname NetworkManager[757]: <info> IPv4 configuration:
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Internal Address: 192.168.88.102
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Internal Prefix: 32
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Internal Point-to-Point Address: 192.168.88.1
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Maximum Segment Size (MSS): 0
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Forbid Default Route: yes
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Internal DNS: 10.0.0.2
     May 29 16:50:18 hostname NetworkManager[757]: <info>   DNS Domain: '(none)'
     May 29 16:50:18 hostname NetworkManager[757]: <info> No IPv6 configuration
     May 29 16:50:19 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (IP Config Get) complete.
     May 29 16:50:19 hostname NetworkManager[757]: <info> Policy set 'AO' (wlan0) as default for IPv4 routing and DNS.
     May 29 16:50:19 hostname NetworkManager[757]: <info> Writing DNS information to /sbin/resolvconf
     May 29 16:50:19 hostname dnsmasq[1565]: setting upstream servers from DBus
     May 29 16:50:19 hostname dnsmasq[1565]: using nameserver 10.0.0.2#53 for domain 88.168.192.in-addr.arpa
     May 29 16:50:19 hostname dnsmasq[1565]: using nameserver 10.0.0.138#53
     May 29 16:50:20 hostname NetworkManager[757]: <info> VPN plugin state changed: started (4)
     May 29 16:50:20 hostname dbus[691]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
     May 29 16:50:20 hostname dbus[691]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

Flagged for migration to superuser. Verify your ubuntu pptp client isn't just discarding routes being pushed from upstream and that it has permissions to add additional routes to the routing table. If you want more specific help, provide the name of the pptp client you are using (might be networkmanager if you're using the builtin client). Check your ubuntu syslog (/var/log/<files>) to see if there are any errors reported by pptp and add appropriate output to your question. — Andrew Domaszek, Commented May 29, 2014 at 12:46
Hi Andrew, thanks for the quick answer. I've edited the question. Adding routes isn't the issue but making them act as Windows routes does seems like a problem to me. @AndrewDomaszek — user2980615, Commented May 29, 2014 at 14:11
If nm-pptp doesn't expose ppp's use-routes option, use gsettings, gconf-editor or dconf-editor as your user (or root if you're bringing the connection up for all users), and set the use-routes option to yes. — Andrew Domaszek, Commented May 29, 2014 at 14:27
@AndrewDomaszek, I didn't find any schema neither any documentation pointing to use-routes option. As I mentioned in the question, Windows makes two default routes. When pinging a remote severs (which has the same subnet as my own) it first tries to find it locally and when it fails - a request to the tunnel is sent (as stated in the routing table by the second default gateway). That's not what happens in Ubuntu. — user2980615, Commented May 29, 2014 at 15:00

kasperd · Accepted Answer · 2014-05-29 17:34:04Z

0

As far as I can tell from your output, neither host has a route to reach 10.0.0.83 through the VPN. Both of them have a routing table indicating 10.0.0.83 is directly connected through the physical network.

The Windows output suggest the first trace fails due to an ARP timeout. No host on the directly attached network actually claims to have 10.0.0.83, hence you see an unreachable message from the Windows machine itself.

Next something weird happens, because next attempt appears to be routing through the VPN. This is slightly similar to what you'd expect to see in case of an ICMP redirect message, but not exactly the same.

A packet trace of the actual communication could be revealing. Does anything on the LAN send a packet to the Windows machine, which could explain this change in behavior?

answered May 29, 2014 at 17:34

kasperd

2,9011 gold badge19 silver badges30 bronze badges

Wireshark dump shows an ARP request was made for 10.0.0.83 but was never answered. After a small period of time encapsulated PPP packets are being sent between the public VPN address and the local IP. Nothing indicates a strange behavior... This is totally a Windows built-in mechanism. Is there really no way to imitate such a thing in linux?
– user2980615
Commented May 29, 2014 at 19:04
@user2980615 What exactly is the criteria Windows is using? Will it always fall back to a less specific route, if a more specific route exists, but gives an ARP timeout? It would not be wise to do that in general because that could easily lead to routing loops. I don't know of any specific way to make Linux do that. Instead my recommendation would be to not reuse RFC1918 address space in networks that need to communicate with each other, and then use explicit routes, such that this kind of fallback won't be needed.
– kasperd
Commented May 29, 2014 at 19:10
It is easier for me to make a few static routes between me and some remote servers on top of changing my whole home network subnet. I will keep looking for a smart solution for this issue...
– user2980615
Commented May 30, 2014 at 10:47

Add a comment |

Stack Exchange Network

Ubuntu vs. Windows VPN routing behavior

1 Answer 1

You must log in to answer this question.

Hot Network Questions

Ubuntu vs. Windows VPN routing behavior

1 Answer 1

You must log in to answer this question.

Related

Hot Network Questions