Which VPN Ports to Open on a Firewall: Protocol by Protocol
PPTP takes TCP 1723 plus GRE, L2TP/IPsec takes UDP 500 and 4500 plus ESP, and SSTP, OpenVPN and WireGuard each need one port. Here is what to open.
Two separate rules decide whether a VPN tunnel survives a firewall: the port the client dials, and the protocol that carries the payload. Open only the first and the tunnel authenticates, then moves no data. The minimum is one TCP port plus GRE for PPTP, two UDP ports plus ESP for L2TP/IPsec and IKEv2, and a single port for SSTP, OpenVPN and WireGuard. Direction, state tracking and NAT decide the rest.
Start from the port the client dials
Every family has an entry point the client contacts first, and that entry point is what your allow rule has to name. PPTP clients connect to TCP 1723. L2TP/IPsec starts IKE on UDP 500 and shifts to UDP 4500 once NAT traversal is in use, with the L2TP frame itself on UDP 1701 inside the tunnel. SSTP wraps the session in TLS on TCP 443, IKEv2 negotiates on UDP 500 and 4500, OpenVPN defaults to UDP 1194 but is often moved to TCP 443, and WireGuard listens on UDP 51820.
| Family | Rule to add on the gateway | Typical mistake |
|---|---|---|
| WireGuard | UDP port from ListenPort, for the peer address | Assuming 51820 when the config says otherwise |
| OpenVPN | The configured UDP or TCP port, often 443 | Opening 1194 after the server moved |
| SSTP | TCP 443 limited to the gateway IP | Allowing 443 to any destination |
| IKEv2 | UDP 500 and UDP 4500, plus ESP | Allowing only 500 and losing NAT-T |
| L2TP/IPsec | UDP 500, 4500, ESP, and 1701 inside the tunnel | Exposing 1701 to the internet |
| PPTP | TCP 1723 and IP protocol 47 | Writing a rule for TCP 47 |
Treat those numbers as defaults rather than fixed properties. A WireGuard interface uses whatever listen port its configuration declares, and an OpenVPN server can sit on any port the administrator chose. Read the server configuration before you write the rule, because a firewall opened for 1194 does nothing for a server that was moved to 443.
The third column is where most change tickets go wrong. The rule exists, but it points at the wrong destination, the wrong direction, or the wrong transport.
GRE and ESP are protocol numbers, not ports
GRE and ESP have no ports at all, so a firewall form that only accepts port numbers cannot express them. GRE is IP protocol 47 and ESP is IP protocol 50, both matched through the protocol field of the IP header. A rule written as TCP port 47 matches nothing, which is how a PPTP policy looks correct and still drops every packet after the handshake.
Consumer routers hide this behind a passthrough checkbox that installs the protocol rule and, for GRE, the NAT helper needed to map the flow. On a real firewall you add the protocol yourself: permit IP protocol 47 to the PPTP server, permit IP protocol 50 to the IPsec gateway. Where the platform offers no protocol field, encapsulation is the way out, which is why IKEv2 can fall back to UDP 4500 and why OpenVPN and WireGuard never hit the problem.
Check what the rule actually matches before blaming the client. A packet counter that stays at zero on the gateway says the rule never fired, and no amount of client-side reinstalling changes that.
Direction, state and NAT change the answer
A client dialling out and a gateway listening inbound are different requirements, and the same port list can be right in one direction and wrong in the other. A stateful firewall tracks the UDP flow on 500 and 4500 and lets replies back without a second rule. ESP and GRE carry no ports, so a NAT device has nothing to key on and needs a helper or an encapsulation to follow the session.
NAT traversal is the part that gets missed. IKEv2 starts on UDP 500, detects a NAT device, and continues on UDP 4500, so a policy that permits only 500 gives a tunnel that establishes and then goes quiet. L2TP/IPsec makes the same move. If your capture shows the first exchange but no sustained traffic, look for a rule that stops at 500.
Record the direction with every rule. "Allow UDP 4500" means nothing until you say from where to where, and a rule that is right for a roaming client is usually wrong for a site-to-site peer.
Check each path with a capture
Run the capture on the gateway, not on the client: a client only records what arrived. These filters cover the families above and show which stage is missing:
sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50Read the output as a sequence. When negotiation shows up but the payload protocol does not, the drop happens somewhere between client and gateway. When both appear and the page still fails, the firewall is no longer the suspect; look at routing, DNS or the address pool handed to the client.
On a box without tcpdump, the same evidence comes from interface and rule counters. Bytes in but not out on the tunnel interface point at the return path rather than at the initial allow rule.
Leave a rule set you can defend
SSTP on TCP 443 is indistinguishable from ordinary HTTPS to any port-based filter, which is the point when a network allows only web traffic. It is also why the 443 rule should name the gateway as destination instead of the whole internet. Delete temporary any-to-any rules as soon as the tunnel works. Write down which rule matched, the protocol number where there is one, and the direction, so the next person starts from evidence.
Cloud point-to-site gateways make the choice visible: the downloaded profile uses either SSTP on 443 or IKEv2 on 500 and 4500, and you should open only the one the profile actually picks. PPTP is not worth the GRE exception on a modern network, since mobile carriers often drop protocol 47 regardless of your firewall. Before you close the ticket, confirm that the rule matches the port in the server config, that the protocol field is set where the family needs one, and that the destination is the gateway rather than any address.