PPTP Server Behind a Home Router: Fix 1723 and GRE First

PPTP behind a home router fails in two unrelated ways, and mixing them up wastes an evening. One failure is a forwarding gap: the router passes TCP 1723 and drops IP protocol 47, so the client hangs at error 619. The other is a size problem: the tunnel comes up, authenticates, then freezes when a full-size packet has to cross. Working out which of those you have is the first real step; the rest compares what your router can express, not which brand is better.

Two transports, and only one of them has a port

PPTP splits across two transports: a control connection on TCP 1723, and PPP frames wrapped in enhanced GRE, which is IP protocol 47. GRE has no port number, so a rule written as forward port 1723 cannot cover it no matter how the web interface words the field. A consumer router usually offers a checkbox called PPTP passthrough instead of a protocol rule, and that checkbox does two jobs: it allows protocol 47 through the firewall, and it teaches NAT how to track the GRE flow. On a Linux router those jobs are separate modules and separate rules, which is why a half-configured passthrough still produces a working control channel. Find out which half is present before you change anything.

The server's own firewall must also allow protocol 47 from the router address. A host firewall that accepts only 1723/tcp reproduces error 619 from inside the LAN, which makes a broken forward and a broken host rule look identical.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

If the modules are missing, load them with sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre and make the load persistent, because a reboot that forgets the helper turns a working tunnel back into error 619. The forward rule only needs to accept protocol 47 toward the server address, not the whole LAN. The RFC 2637 definition separates the control and data paths, which is why no single port-forward screen describes PPTP completely.

Passthrough checkbox or an explicit protocol rule

A passthrough checkbox that only opens the firewall is closer to correct than an ALG that rewrites call identifiers. The firewall half is predictable, since either protocol 47 is accepted or it is dropped and the counters say which. The rewriting half is where vendors differ, because PPTP call identifiers are per tunnel and a NAT that edits them has to track every call it touches. When one client connects and two do not, the ALG is the first suspect.

A destination NAT rule for 1723 also has an ownership problem. If a stale rule still sends 1723 to a host that stopped running the server, packets land on a closed port and the router's own PPTP service stops answering, which reads like a firewall failure but is really a stale target. Read the rule and its destination before adding a second one. On routers that terminate PPTP themselves, the WAN rule competes with the built-in service, so pick one owner for 1723 and protocol 47.

Two clients behind the same NAT are the case that separates a plain forward from a clever one. Forwarding protocol 47 without rewriting call identifiers usually behaves better than a helper that tries to fix them.

Size the tunnel before you blame the router

PPTP shrinks the usable payload, and the shrink is arithmetic rather than mystery. Every tunnel packet carries an outer IP header, an enhanced GRE header, a PPP header and, with encryption, an MPPE header. When the path cannot carry the resulting frame, small packets pass, the login completes, and the session stalls the first time a file transfer or a TLS handshake sends a full-size packet.

Work the number out instead of guessing it. Enhanced GRE costs 8 bytes, PPP costs 4, MPPE costs 4, and the outer IP header costs 20, so the tunnel eats 36 bytes before any payload. On a PPPoE WAN that tops out at 1492, the largest PPP MTU that fits is 1492 minus 36, which is 1456. Set mtu and mru to that value in the PPP options and retest with a non-fragmenting ping.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

The ping measures the path, not the tunnel: 1464 bytes of payload plus 28 bytes of IP and ICMP headers fills a 1492-byte frame exactly. If that ping fails, lower the number until it passes and subtract 36 from the result. A tunnel MTU set above the path limit produces the freeze with no log line that mentions size at all.

PPTP, L2TP/IPsec or OpenVPN on the same router

The same router can carry any of the three common tunnels, and the difference is what it has to express. PPTP needs two rules in two different layers. L2TP over IPsec needs UDP 500 and 4500 for the key exchange and, unless NAT-T carries it, protocol 50 for the payload. OpenVPN needs one UDP port and no helper at all.

The L2TP column is not automatically friendlier than GRE. ESP is IP protocol 50 and has no port either, so a router that struggles with protocol 47 may struggle with protocol 50 for the same reason. NAT-T exists to wrap ESP inside UDP 4500, and when both ends support it the protocol-50 rule becomes unnecessary. That is a property of the endpoints, not of the router's PPTP checkbox. Confirm which encapsulation the client actually negotiated before writing rules for both.

OpenVPN is the option with the fewest moving parts on the router side. One UDP port, one forward, no connection-tracking helper and no call-identifier rewriting. The trade is a client that has to be installed rather than a built-in dialer, which is often the only reason PPTP stays in the conversation.

What to repair and what to replace

Fixing the forward and the MTU gives you a tunnel that works, not one you should keep. PPTP's MSCHAPv2 authentication has been attackable for years, and a working tunnel moves credentials that can be recovered offline. If the remote device can run L2TP/IPsec or OpenVPN, treat the repair as a temporary measure with a date on it.

The decision comes down to what the far end supports and how long the arrangement has to last. A legacy appliance that only speaks PPTP gets the repair; anything that can install a client gets migrated.

Before closing the ticket, confirm the client survives a large transfer rather than a login, and that the router still holds its protocol-47 rule after a reboot. A tunnel that passes one file copy and dies after the next firmware update was never finished.