VPN Tunnel Never Connects: Where the Packets Actually Stop

The client keeps retrying, the log stops before the handshake completes, and the server records nothing at all. That pattern points away from credentials and toward the path: something between the two ends declines to carry the protocol the tunnel needs. Decide where packets stop before touching either configuration, because a filtered protocol and a wrong password produce the same friendly error in most clients. The tests are ordered by cost, cheapest first.

Prove Where the Traffic Stops

Capture on the client's outbound interface and on the server at the same moment. Compare what left with what arrived, and note which direction the difference appears in.

Nothing at the server means the path or the first NAT is dropping traffic, while arrivals without replies point at a firewall on the server or a return route that does not exist. A router that terminates tunnels frequently keeps no useful log, so the capture becomes the record. Write down the destination port and the protocol number, since both failures render identically in a client dialog.

PPTP Dies Without Protocol 47

PPTP carries control on TCP 1723 and its data inside GRE, which is IP protocol 47 rather than a port number. Forwarding 1723 alone produces the classic outcome: the connection authenticates, then goes quiet, because no rule exists for the protocol that carries the payload. The client cannot distinguish that from a rejected password, which is why the capture has to come before the configuration edits.

Passthrough runs in the opposite direction from an inbound forward, and firmware uses one label for both often enough to confuse everyone. On a Linux client the local firewall can drop GRE long before the router is involved, so protocol 47 needs its own rule and the conntrack helper has to be loaded. Ubuntu's ufw keeps those rules in the before file, since ordinary allow rules cannot express a protocol number. Reload the firewall afterwards rather than rebooting the machine.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP and IPsec Behind Two NATs

L2TP inside IPsec needs UDP 500 for the key exchange, UDP 4500 once NAT is detected, and ESP as protocol 50. Each of those is filtered independently, so a rule that permits one proves nothing about the other two. Two routers in series translate every packet twice, and the endpoints no longer agree on what was negotiated.

Bridge the outer modem, or turn off NAT on the inner router, so the public address reaches the device that terminates the tunnel. Where neither is possible, the tunnel has to be initiated from inside the double-NAT boundary rather than terminated there.

Carrier Networks and Address Sharing

A WAN address inside 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 or 100.64.0.0/10 means the router has no public address, and no inbound forward from the internet can reach it. Carrier-grade NAT additionally filters protocols it does not expect, and GRE is a frequent casualty on mobile links. Compare the WAN address on the router itself, not the address a lookup site reports for a client behind it.

Running the same router on a wired line separates a carrier finding from a configuration error in a single test. Where the carrier refuses the protocol, the remaining options are a different transport on 443 or a tunnel initiated from inside.

Read the Listener List Before You Close Ports

An alarming port scan is often just the feature set that ships enabled. Inventory the listeners, match each socket to a feature, then disable the feature instead of blocking the port, so the two views cannot drift apart.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEther's defaults are a good example: TCP 443, 992 and 5555, with the L2TP/IPsec and DNS-tunnel features adding their own sockets. Turning those features off removes the listeners instead of hiding them, and the probe from an outside host tells you whether the carrier lets the port through at all. A listener that answers locally can still be closed upstream, so compare the router's own WAN address with what an outside service reports.