I've just switched from an old Linux install (Debian squeeze) to a new one (Linux Mint 17.3) for my router (I am using a full desktop PC with a Linux install as my router). The Linux PC connects directly to my DSL modem and negotiates a PPPoE connection, then routes internet connections for all my other devices.

As far as I can tell, I've set it up the same as the previous Debian install. I had a simple rc.local script to set up iptables, and it's the same on the new box and it's getting run (I have ensured this by running /etc/rc.local from a root console). I've also setup DNS on the new box.

Most of the stuff works the same, but I am having one problem: the VPN on my Windows box no longer manages to connect. Looking at Wireshark, I notice that the initial PPTP packets seem to be successfully sent and received, but then there is a "Set-Link-Info" packet sent from my Windows box, and then the Windows box starts setting "PPP LCP Configuration Request" packets. At this point, it receives no response. The Wireshark capture going over my old Debian setup showed that at that point it got responses, eventually resulting in a "PPP LCP Configuration Ack".

I really can't figure out what else to check. I don't understand why the PPTP connection is getting stuck here with my new setup. Any ideas as to how I can troubleshoot?

Note: Here's the /etc/rc.local I have (it's the same on both installs) that sets up my entire iptables configuration:

#!/bin/sh -e

echo "*** Running rc.local ***"

# First up, make sure 'net.ipv4.ip_forward=1' exists, uncommented, in /etc/sysctl.conf (just do this manually)
echo "MAKE SURE net.ipv4.ip_forward=1 EXISTS, UNCOMMENTED, IN /etc/sysctl.conf OR NAT WILL NOT WORK!!!"
echo ""

# Firewall variables
#WAN_IFACE="eth0"         # At the time of writing, this is the NIC built into the mobo
WAN_IFACE="ppp0"         # Virtual PPP interface when using PPPoE
LAN_IFACE="eth1"         # At the time of writing, this is the extension NIC card
LAN_IP=""  # Class-C internal network

# Setup iptables... flush existing rules
iptables -F
iptables -t nat -F
set +e
# Set +e here to continue on error; iptables may give an error if this chain doesn't currently exist and we try to delete it
iptables -X LOGGING
set -e

# Set default policies for chains
iptables -P INPUT DROP

# Allow all local loopback access
iptables -A INPUT -i lo -p all -j ACCEPT
iptables -A OUTPUT -o lo -p all -j ACCEPT

# Allow incoming traffic for established connections
iptables -A INPUT -i $WAN_IFACE -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $WAN_IFACE -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $LAN_IFACE -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $LAN_IFACE -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow incoming ICMP traffic
iptables -A INPUT -p icmp -j ACCEPT

# Uncomment lines in this section to allow unsolicited incoming traffic on ports
## Open common service ports
## SSH
#iptables -A INPUT -i $WAN_IFACE -p tcp --destination-port 22 -j ACCEPT
## HTTP (8080 + 8081)
#iptables -A INPUT -i $WAN_IFACE -p tcp --destination-port 8080 -j ACCEPT
#iptables -A INPUT -i $WAN_IFACE -p tcp --destination-port 8081 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --destination-port 8080 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --destination-port 8081 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --destination-port 53 -j ACCEPT
# Local Samba connections
iptables -A INPUT -p tcp --syn -s $LAN_IP --destination-port 139 -j ACCEPT
iptables -A INPUT -p tcp --syn -s $LAN_IP --destination-port 445 -j ACCEPT

# NAT setup - allow the NAT masquerading

# Allow forwarding of packets between the Internet and local network interface(s)

# Logging setup
iptables -N LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix="IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

# Logging; uncomment the below to log dropped input packets to syslog (verbose; only use for debugging!)
echo "Uncomment the necessary lines in rc.local to enable iptables logging..."
#iptables -A INPUT -j LOGGING

echo "*** Finished running rc.local ***"

exit 0


I've been doing some more investigation into this, and the Wireshark analysis of what's being put out by my Linux router reveals one very significant difference. Here are the two screenshots, first from my old Debian box whose routing works, and second from my new Mint box where it doesn't:

Wireshark on Debian squeeze

Wireshark on Linux Mint 17.3

I've replaced the IP addresses with red and blue stripes to indicate my Linux router's public IP address, and the remote address with which we are communicating in order to establish a VPN connection through the PPTP protocol. Also, my Windows machine's IP address on the local network is outlined in green.

The thing to notice is what happens after the PPTP protocol finishes and we switch to PPP LCP packets. On the Debian box, it continues to convert the source address of these packets to my public IP address before sending them out to the public internet. But on my Linux Mint box, the source address of packets being sent out is still kept as the local network address of my Windows machine that's trying to establish the connection. It's sending packets out to the internet with a local class C source address - of course they're not getting routed!

The question is, what is causing the breakdown of NAT here on my Linux Mint box that isn't happening on the Debian box? The iptables are the same, the /etc/network/interfaces are the same. I don't know... but maybe this discovery will help someone here to help me with the problem. :-)

  • The answers from derobert and Miroslav Banov together will get PPTP working, but please note that PPTP is thoroughly broken. At this point, you could just go ahead and not encrypt anything at all :) Sep 6, 2018 at 11:24

2 Answers 2


In order for NAT to work, you need to have a protocol-specific helper module loaded. By default, you're only going to have ones for TCP and UDP loaded.

That's why you're seeing your PPTP traffic (which is actually PPP over GRE) escaping without NAT. That module is nf_nat_proto_gre, at least as of Linux 4.4.

A similar story applies to connection tracking (without which GRE packets aren't going to be considered part of an established or related connection). That's nf_conntrack_proto_gre.

It turns out that PPTP requires special handling too (I'd guess it embeds IP addresses inside the PPP negotiation, but I haven't checked). That special handling is provided by nf_nat_pptp and tracking of PPTP connections is provided by nf_conntrack_pptp.

A modprobe ip_nat_pptp should get your VPN working. Dependencies between the modules will wind up loading all four. To make it continue working across boot, add nf_nat_pptp to /etc/modules.

(No, I have no idea where this is documented, sorry!)

  • Are ip_nat_pptp and nf_nat_pptp synonymous? Both seem to work interestingly.
    – Jez
    Apr 12, 2016 at 17:57
  • @Jez yeah, they are ip_nat_pptp is an alias for nf_nat_pptp. I should probably use the non-alias in the answer for clarity, but they'll both work just fine.
    – derobert
    Apr 12, 2016 at 18:01
  • Although I loaded the ip_nat_pptp module, still I am not able to connect to the remote VPN server. Is there anything else to do ? I have also the same iptables configuration as mentioned above. Jun 17, 2019 at 9:15
  • 1
    @Shyamkkhadka See also Miroslav Banov's answer, if you're on a half-recent kernel. Or better yet, use the CT target (in the raw table) to set the helper explicitly.
    – derobert
    Jun 17, 2019 at 17:56

The answer by derobert is correct. But with the newer kernel versions there is another problem - the default value of net.netfilter.nf_conntrack_helper is changed to 0 for security reasons.

See related:

The easy fix is to make it 1 again. Add at the bottom of /etc/sysctl.conf

net.netfilter.nf_conntrack_helper = 1

Then either reboot or run sysctl -p

  • 2
    Of course, with any sysctl.conf changes, one doesn't need to reboot, just have to issue sysctl -p.
    – Xmister
    Oct 2, 2019 at 15:53
  • Thanks Xmister, added sysctl -p Sep 28, 2020 at 12:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .