Loading...
 

No Food for Thought

Error 619 when trying to connect a NAT-ed client to a PPTP server - watch your router

admin Saturday October 3, 2015

Today, I realized my PPTP connections from Windows 7 and 8 machines were no longer able to connect to the PoPToP server I setup at the office. Strangely, nothing had changed on the server (still Debian 7 running PoPToP 1.3.4), on the server-side router, and my clients obviously had not both been changed enough to explain the breakage. The Windows error messages were not too precise. Server logs were also unhelpful, apparently pointing to a bug in PoPToP, which timed out after 30 seconds:

daemon.log
Oct  3 16:47:25 deimos pptpd[24176]: CTRL: Client 173.178.241.108 control connection started
Oct  3 16:47:25 deimos pptpd[24176]: CTRL: Starting call (launching pppd, opening GRE)
Oct  3 16:47:25 deimos pptpd[24176]: GRE: Bad checksum from pppd.
Oct  3 16:47:55 deimos pptpd[24176]: GRE: read(fd=6,buffer=804f620,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Oct  3 16:47:55 deimos pptpd[24176]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Oct  3 16:47:55 deimos pptpd[24176]: CTRL: Reaping child PPP[24177]
Oct  3 16:47:55 deimos pptpd[24176]: CTRL: Client 173.178.241.108 control connection finished


I finally realized the change to blame was me switching my TP-Link router from TP-Link's firmware to OpenWrt (15.05). I do not understand much of how PPTP works, but it's quite complicated. Apparently, it uses non-standard GRE packets. Therefore, I am not sure if this is a PPTP bug or an OpenWrt bug, but for me the solution was most simple.

As explained in this description of error 619, there are several possible causes, but even if the client is clearly reaching the server, the issue can be client-side. If there is no firewall on the client OS, you should verify any client-side router, which I did by plugging one of the affected PC-s directly on the modem. The VPN could connect again, which confirmed the router was to blame.

OpenWrt does not have a "PPTP VPN passthrough" option to check, but a package to install (which is not installed by default in Chaos Calmer). Following the instructions on OpenWrt's PPTP NAT Traversal document (installing kmod-nf-nathelper-extra), I managed to get the clients to connect while NAT-ed behind OpenWrt.

Fully Free

Kune ni povos is seriously freethough not completely humor-free:

  • Free to read,
  • free to copy,
  • free to republish;
  • freely licensed.
  • Free from influenceOriginal content on Kune ni povos is created independently. KNP is entirely funded by its freethinker-in-chief and author, and does not receive any more funding from any corporation, government or think tank, or any other entity, whether private or public., advertisement-free
  • Calorie-free*But also recipe-free
  • Disinformation-free, stupidity-free
  • Bias-free, opinion-free*OK, feel free to disagree on the latter.
  • Powered by a free CMS...
  • ...running on a free OS...
  • ...hosted on a server sharedby a great friend for free