Why blocking VPN ports does not stop unauthorized tunnels

A firewall rule denies the traffic it matches. It does not deny every use of a connection it permits, and that gap is where most unauthorized-tunnel policies fail. Blocking the ports of whichever client was popular five years ago leaves anything that rides 443 untouched, and it says nothing about a device that can rewrite its own routes. Build the control around authority and destinations, then read the flows you actually allow.

Why a port list is not a policy

Ports are a transport-layer concept, and several tunnel technologies do not use one at all. Others deliberately share a port with ordinary web traffic because that port is the one guaranteed to pass. A rule keyed on a historical port therefore enumerates a handful of implementations rather than the class of behaviour. It also ages badly: the moment a provider changes defaults, the list describes the past.

Worse, a successful block on one port can be read as evidence that the whole problem is solved, which then delays the controls that would have mattered.

Protocol numbers and ports are different namespaces

GRE is assigned IP protocol number 47. It is not TCP port 47 and not UDP port 47, and a filter written for a port does not touch it. ESP and AH sit at protocol numbers 50 and 51 with the same property. Encapsulated traffic can also hide inside a permitted connection, which is why a category or signature can help but never certifies purpose on its own. Confidence and coverage belong to a specific product and release, not to the concept.

nft list ruleset | grep -nE 'gre|esp|ah|47|50|51'
cat /proc/net/protocols | head -20
ss -tn state established '( dport = :443 )'

The first command shows what you actually wrote; the second shows the protocol table the stack knows about; the third shows how many sessions are using the web port right now. None of them tells you what those sessions are for. TLS interception is a separate decision with its own trust, privacy and client-compatibility costs. It is not a prerequisite for denying a named destination, and it is not a guarantee of tunnel recognition either.

Control the authority the device has

A device that can change its own routing table and filtering has capabilities an ordinary application does not. Admission and configuration management are what remove that capability, and they act regardless of which port the tunnel would use.

That means approved attachments get their declared role rather than unrestricted permission to forward for other devices, and it means installation and network-administration rights are part of the policy instead of an afterthought.

Observe the flows that remain. Correlate device identity, assigned role and flow metadata, and treat classification as evidence with limits rather than a verdict.

conntrack -L | awk '{print $1, $4, $5}' | sort | uniq -c | sort -rn | head
ip -br addr show
ip route show default

A long-lived encrypted session or a large byte count is not proof of misuse: backups, support tools and site links look the same. Keep collection scoped to the investigation and retain what you find under the process that owns it.

Make the exceptions explicit

Every environment has destinations that must stay reachable for updates, authentication and recovery. Write them down with a purpose and an owner, and review them instead of discovering them one outage at a time.

When the business genuinely permits a broad external service, assess the authority that service supplies rather than assuming the destination label makes every use acceptable.

An unreviewed exception is a hole with a ticket number. An exception with a name, a reason and a review date is a decision.

Accept with a written plan, not a slogan

Acceptance has two halves: the approved work still succeeds, and the specific prohibited cases fail under an authorized test. Both need to be written before the change and repeated after it.

Include endpoint and policy changes in that review, because a route added on a laptop can undo a filter that was working perfectly at the edge.

The deliverable is an owned egress boundary with a known list of remaining risk. Claiming that a few closed ports ended unauthorized VPN use is not that.