Protocol 47 vs TCP port 47: two headers, two firewall rules
A protocol number and a port live in different headers, so one rule cannot replace the other. PPTP splits the two, and a port box cannot express GRE.
Hotel networks and conference firewalls often expose a custom allow box, and somebody types 47 into it expecting PPTP to work. The rule gets created, the tunnel still fails, and the next attempt uses a different number. What went wrong sits in the packet itself: IPv4 has a protocol field that names what follows the IP header, while TCP and UDP have port fields that only exist once you are inside one of those headers. They are not two spellings of the same permission.
The IPv4 header names the next protocol
The protocol field is one byte in the IPv4 header, and it holds a number describing the payload: 6 for TCP, 17 for UDP, 47 for GRE, 50 for ESP. Anything that filters packets reads that value before it looks deeper, because the deeper header only makes sense once the type is known. Change a port later in the conversation and this field has not moved.
A rule written against protocol 47 therefore describes the IP layer. No port takes part in the decision at all.
Ports exist inside TCP and UDP, nowhere else
Ports are sixteen-bit identifiers inside TCP and UDP headers, and their job is to separate conversations sharing one address. A GRE header carries a protocol type value, often an EtherType, plus optional keys used for multiplexing. The phrase port 47 therefore names nothing that a GRE packet can match.
Firewall interfaces differ in how much of this they expose. Some accept a protocol number, some offer a named list, and a few only accept TCP or UDP with ports.
PPTP uses both layers at once
PPTP is the clearest example because it deliberately splits its work across the two. The control connection is a TCP session to port 1723, and the data path is GRE, protocol 47, with no port involved anywhere. A firewall that permits 1723 and nothing else lets the negotiation start and then discards the payload. The tunnel appears to hang after authentication instead of failing to connect, which is why the symptom is often reported as a password problem.
| Path | Outer protocol | Port |
|---|---|---|
| Control channel | TCP, protocol 6 | 1723 |
| Data channel | GRE, protocol 47 | None |
Read the two rows separately when you write the rule, and check each against the vendor syntax. One row needs a port, the other needs a protocol number, and no single entry covers both.
Why a port-forward page cannot express GRE
A forwarding form that accepts only TCP and UDP cannot describe GRE, whatever the form is called. Address translation adds a second difficulty, because GRE has no ports and the translator has to follow the call identifier instead. Some consumer routers ship a helper that handles it; plenty do not, and no additional TCP allow entry will create that behaviour.
Where a modern tunnel is the actual requirement, pick a design that uses TCP or UDP deliberately rather than hoping a translator guesses correctly.
Encapsulation decides what the filter sees
Encapsulation changes the outer packet, and the outer packet is what a rule matches. Native ESP is protocol 50, while NAT traversal wraps ESP inside UDP 4500 so it can survive address translation. A filter that permits UDP 4500 never sees protocol 50, and a filter written for protocol 50 never matches the wrapped form.
Ask which encapsulation the client and the gateway agreed on, then write the rule for that outer shape and nothing more.
Write the rule so somebody can check it
Express every rule as address family, outer protocol, transport ports if any, direction and both endpoints. A reviewer can compare that sentence with a packet capture and reach a verdict. An instruction to open 47 cannot be checked by anyone, which is how it survives in runbooks for years.
Add the test that proves it: connect while capturing on the outside interface, and confirm the outer protocol and port that actually appear in the trace.