Learn PPTP - NAT Traversal & Firewall Issues

#Introduction

PPTP has had a well-known problem since the beginning: it does not work well behind NAT. Many connections fail not because of wrong configuration, but because the router in the middle does not know how to handle GRE.

Episode 16 explains why GRE is not NAT-friendly, how routers work around this with an ALG, Linux's built-in support through pptp conntrack, and how to configure firewalls with iptables and nftables.

#Why GRE Is Not NAT-Friendly

#The Fundamental NAT Problem

NAT works by translating addresses and ports. It recognizes sessions through tuples such as source IP, destination IP, source port, and destination port. The problem is that GRE has no ports — it only has protocol number 47.

As a result, a NAT router cannot distinguish one GRE session from another. When two clients behind the same NAT try to build PPTP tunnels to the same server, the router does not know which client a GRE packet belongs to, and the connections get tangled.

#A Control Channel That Deceives

Sometimes TCP 1723 control traffic works normally but GRE data never arrives. This is a typical pattern: the control channel is ordinary TCP that passes through NAT, while the GRE data channel fails because there is no matching NAT session.

#The Problem on Home Networks

The most common case happens on home networks: the router runs NAT, and a client behind it tries to connect to the office PPTP server. The TCP 1723 connection succeeds, then GRE stalls because the router did not create a NAT entry for protocol 47.

This is the main reason PPTP often "does not work" from home even though it works from the office's direct internet connection. The problem is not the client configuration but the device in the middle that does not recognize GRE sessions — and the solution is almost always in the router settings, not in the peers file.

#The ALG in Routers

#Application Layer Gateway

To solve this problem, many routers provide PPTP/ALG — a module that recognizes PPTP control packets and creates dynamic NAT rules for the associated GRE traffic.

sudo modprobe nf_conntrack_pptp
sudo modprobe nf_nat_pptp

On Linux, PPTP ALG support is provided by the nf_conntrack_pptp and nf_nat_pptp modules. modprobe nf_conntrack_pptp lets conntrack follow PPTP connections and create NAT entries for GRE automatically. On commercial routers, the equivalent feature is usually called PPTP ALG or PPTP Passthrough.

#When the ALG Makes Things Worse

Some routers implement a buggy ALG that actually breaks connections. If PPTP cannot connect behind a particular router, test by disabling PPTP ALG in the router settings. This is a troubleshooting step that often resolves the problem.

#Firewall Configuration

#Opening Ports with nftables

For modern distributions using nftables, the basic rules are:

sudo nft add rule inet filter input tcp dport 1723 accept
sudo nft add rule inet filter input ip protocol gre accept

nft add rule inet filter input tcp dport 1723 accept accepts the control channel, and the second line accepts the GRE data channel. Both are mandatory — forgetting to open GRE is the most common cause of a dead tunnel.

#Opening Ports with iptables

For systems still using iptables:

sudo iptables -A INPUT -p tcp --dport 1723 -j ACCEPT
sudo iptables -A INPUT -p gre -j ACCEPT

The iptables -A INPUT -p gre -j ACCEPT pattern is the classic way to open protocol 47. Make sure both rules are positioned before any default DROP rule.

#Making Rules Persistent

iptables rules disappear on reboot. Persist them with a package such as iptables-persistent or netfilter-persistent:

sudo netfilter-persistent save

sudo netfilter-persistent save saves the currently active rules to a file that is re-read at boot. Without this step, the PPTP server will stop accepting connections after a reboot — a classic finding when troubleshooting turns out to be purely a persistence problem.

#Source IP Restrictions

#Allowlists in the Firewall

Since PPTP is insecure, do not leave port 1723 and GRE open to the entire internet. Restrict the source to authorized subnets:

sudo iptables -A INPUT -p tcp --dport 1723 -s 203.0.113.0/24 -j ACCEPT
sudo iptables -A INPUT -p gre  -s 203.0.113.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 1723 -j DROP
sudo iptables -A INPUT -p gre  -j DROP

This combination of rules only accepts PPTP from 203.0.113.0/24 and drops the rest. This is one of the hardening steps from episode 15, paired directly with the need to open ports.

#Closing

Episode 16 explained the mystery of PPTP connections failing behind NAT: GRE has no ports, the role of the ALG, pptp conntrack support on Linux, and how to open and restrict access in both iptables and nftables.

Key takeaways:

• GRE has no ports, so NAT cannot distinguish GRE sessions.
• TCP control traffic can pass NAT while GRE data fails.
• PPTP/ALG in routers creates dynamic NAT rules for GRE.
• The nf_conntrack_pptp and nf_nat_pptp modules provide ALG support on Linux.
• Open TCP 1723 and GRE protocol 47 together in the firewall.
• Restrict access sources to authorized subnets so it is not open to the internet.

In the next episode, episode 17, we will discuss PPTP performance and benchmarking — performance characteristics, MPPE encryption overhead, measuring throughput with iperf3, and comparisons with OpenVPN and WireGuard.