Windows VPN and PPTP Connectivity TimeoutsIn my pursuit for a personal cloud and convenient secure remote file system so as to be able to develop directly on the server I have researched, tested and decided against SFTP, WebDAV, and SMB/NFS over internet. The only approach still standing is the built in Windows VPN and PPTP + SAMBA/CIFS:
However there was one bug that prevented some sites/services from working and timing out; the /var/log/syslog showed the following intermittently:
Apr 19 10:15:15 sh1 pptpd: GRE: accepting packet #107 Apr 19 10:15:15 sh1 pptpd: GRE: accepting packet #108 Apr 19 10:15:15 sh1 pptpd: GRE: accepting packet #109 Apr 19 10:15:15 sh1 kernel: mppe_compress: osize too small! (have: 1404 need: 1408) Apr 19 10:15:15 sh1 kernel: ppp0: ppp: compressor dropped pkt Apr 19 10:15:15 sh1 kernel: mppe_compress: osize too small! (have: 1404 need: 1408)
This due to the way MPPE Microsoft point-to-point Encryption encodes data which results in the packet size being bigger then what was agreed in the VPN handshake - is my guess. There is a reported bug from 2005 which sadly hast not yet been addressed.
Fixing the issue by increasing the MTUYou can't fix this issue by modifying the MTU/MRU settings in '/etc/ppp/options' directly, you have to adjust the MTU after the PPP connection is up and this can be accomplished by adding a custom 'ip-up' script. Below is my work around script, place it into file '/etc/ppp/ip-up.d/mppefixmtu' and ensure that it is executable ('chmod +x mppefixmtu'):
#!/bin/sh CURRENT_MTU="`ifconfig $1 | grep -Po '(?<=MTU:)([0-9]+)'`" FIXED_MTU="`expr $CURRENT_MTU + 4`" ifconfig $1 mtu $FIXED_MTU echo "Increased MTU for $1 to $FIXED_MTU (from $CURRENT_MTU) to fix MPPE Microsoft Point-to-Point bug #330973"
TroubleshootingYou can review script errors by examining the file '/var/log/ppp-ipupdown.log', however if the file doesn't exist then you must create it to enable ip-up/ip-down script logging - don't forget to restart pppd.
As always if you found this useful feel free to follow me here or via twitter @danielsokolowski.