Ubuntu 18.04 VPN (PPTP) Connection Works until large packet received

Question

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).

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

Answer 1

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.