0

Background

I've a VPN server running on a draytek modem.

If I connect through the modem from an Android mobile phone, everything works fine.

Whereas if I connect from NetworkManager using pptp, it works for a bit:

  • Connection is OK
  • I can use ssh to connect to a machine at the other end of the pptp link
  • I can 'ls' and get an OK response
  • However, when I 'ls -la' (generating a larger response), the connection freezes
  • Additionally, any http session that has images on the page also freeze

Diagnosis

Messing with MTU

I've managed to get this working OK by adjusting the MTU at the remote end, i.e.:

  • Connect VPN - OK
  • Check the MTU at the local end with ifconfig (it is 1400)
  • ssh to a machine at the other end of the pptp link
  • check the MTU at the remote end with ifconfig (it is 1500)
  • Adjust the MTU at the remote end to 1300 (ifconfig eth0 mtu 1300)
  • ls -la (and everything else) works fine

Unfortunately, I can't go about adjusting the MTU of any other machines I may connect to over the VPN (e.g. google).

Wireshark

I've also used wireshark to capture the transactions, and it looks like one of the last things that is done before the connection freezes is to send a [TCP Window Update] from the client to the other end (in this case ... 192.168.11.200).

Wireshark Capture of 'ls -la' over ssh connection over vpn

Ping

I've logged into the remote machine via the VPN.

This machine's MTU on ppp0 is 1400 (as set by the VPN link establishment in Network Manager). The remote machine's MTU on eth0 is 1500.

I've then pinged this machine from the remote end as follows, and found that any ping packet larger than 1336 is dropped:

steve@remote:~$ ping -M do -c 1 -s 1336 192.168.11.105
PING 192.168.11.105 (192.168.11.105) 1336(1364) bytes of data.
1344 bytes from 192.168.11.105: icmp_seq=1 ttl=63 time=72.1 ms

--- 192.168.11.105 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 72.131/72.131/72.131/0.000 ms


steve@remote:~$ ping -M do -c 1 -s 1337 192.168.11.105
PING 192.168.11.105 (192.168.11.105) 1337(1365) bytes of data.

--- 192.168.11.105 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

IP Route

Note sure if it useful, but here is the output of "ip route" showing the default state of the connections ... is there anything wrong here?

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 1c:4d:70:db:5f:ba brd ff:ff:ff:ff:ff:ff
13: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3

Help ...

I suspect this is something to do with packet size negotiation, which is not working - I'm pretty sure it's not part of the modem configuration, because all of this works fine from an Android client, so everything points to the Ubuntu client.

Q: Has Anyone got any pointers or ideas?

Q: Does anyone know what program / part of Ubuntu is responsible for managing and negotiating TCP packet sizes for an individual TCP connection?

Q: Does anyone know why with an MTU of 1400 at one end, and an MTU of 1500 at the other end, there would be a maximum packet size of 1336 allowed - what's so special about 1336?

Q: I was expecting the response to the pings to have a 'fragmentation required' message with them. Does anyone have any idea what could be stopping this message?

pptp version: 1.9.0 or 1.10.0

Steve

  • 1
    Hmmmm. My 18.04 and 18.10 use a VPN (PPTP) to a router-based VPN server...and it works just fine. Smooth and fast. So the problem is not universal. – user535733 Dec 29 '18 at 21:58
  • I suspected it was my configuration somehow. But I had not tweaked anything from the default. I've just built and tried pptp version 1.10.0 and there is no difference. I suspect it is due to the packet size negotiation that goes on, which is not working correctly, but don't know which program running is actually responsible for this. – SM Clarke Dec 30 '18 at 8:41
0

I had similar issue with VPN client on pppOe connection. The pppOe connection has the correct MTU 1492 and VPN server 1500. When there was incorrect MTU set on pppOe the connection was established, but no streaming was possible. With the correct MTU on client side I was able to connect the stream over VPN.

All you need is to set the correct MTU on the client side internet connection.

  • I'm afraid this solution doesn't work for me. I've tried different outgoing MTUs, including 1492, 1472, 1400 and 1300. The problem is that the MTU negotiation for inbound packets doesn't seem to be working. When I have control over the other end, and adjust the MTU to 1336 or lower, it works fine. But I don't have control over other site's MTUs (e.g. google). – SM Clarke Jan 3 at 18:02
  • You need to determine this without VPN connected on the client side with ping command. – kukulo Jan 3 at 18:42
  • I can set an MTU of the connection before I establish the PPTP link, and I've done a trial set of 1200 which provides plenty of space for a security layer - I still see the ppp0 connection with a higher MTU, and the ppp0 connection in my case goes over the wlp2s0 connection: ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1400 inet 192.168.11.111 netmask 255.255.255.255 destination 192.168.11.1 wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1280 inet 192.168.43.215 netmask 255.255.255.0 broadcast 192.168.43.255 – SM Clarke Sep 22 at 8:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.