Protocol Tunnelling and Port Forwarding

What Protocol Tunnelling and Port Forwarding Does

Protocol tunnelling carries one network protocol inside another, while port forwarding redirects traffic from one host or port to another. Both techniques change the visible path of communication without necessarily changing the application doing the talking.

That distinction matters because the outer channel can look normal even when the inner traffic is unusual. In practice, the security question is not just whether the connection succeeds, but whether the encapsulated or redirected path is expected, approved, and observable.

Why Attackers Use It

Attackers value protocol tunnelling and port forwarding because both can bypass simple filtering and make prohibited traffic blend into permitted flows. If defenders only inspect destinations, ports, or protocol names at the edge, the real purpose of the connection can be hidden inside a legitimate-looking transport.

These techniques also support command-and-control, internal reconnaissance, and access to services that should not be directly reachable. A tunnel can carry management traffic, remote shells, or other interactive sessions through infrastructure that would otherwise block those paths. For a deeper view of the command-and-control patterns that often rely on tunnelling, see the Command and Control (C2) Guide.

How Defenders Identify Exposure

Exposure usually shows up in the relationship between allowed network paths and actual business need. If an environment permits forwarding, proxying, VPN-style relaying, or custom encapsulation, defenders should verify which systems are authorised to use it, what destinations are expected, and whether the resulting traffic is logged well enough to distinguish normal use from abuse.

Asset inventory also matters because tunnelling becomes more dangerous when internal services are assumed to be hidden by default. The most important checks are whether a service is reachable from outside the intended trust boundary, whether a firewall rule or proxy exception creates an unintended path, and whether DNS, HTTP, SSH, or other permitted channels are being used as carriers for unrelated traffic.

Detection, Containment, and Recovery

Detection is strongest when network telemetry is matched against expected protocol behaviour. Unusual byte patterns, long-lived sessions, repeated reconnects, atypical ports, and remote access that does not fit the application profile can all indicate tunnelling or forwarding abuse. Encrypted transport does not eliminate the need for monitoring, it shifts attention to metadata, endpoint signals, and egress behaviour.

Containment usually means closing the specific relay path, not just blocking a single destination. If the tunnel is used for intrusion, defenders should also review the endpoints that created it, because the forwarding path may have been enabled to support persistence, lateral movement, or data exfiltration. After remediation, validate that no alternate path or leftover proxy rule still permits the same access pattern.

Risk and Threat Considerations

Protocol tunnelling and port forwarding create a visibility gap between what defenders think is being carried and what is actually moving across the network. That makes them attractive for covert access, bypass of perimeter controls, and hidden reach into internal services.

Failure mechanism: The control failure is usually an inspection or trust-boundary failure, where permitted transport is assumed to be benign even though the encapsulated traffic is not. Attackers exploit that gap to move command-and-control, remote administration, or internal access through channels that appear legitimate.

Impact: The result can be stealthier persistence, harder-to-detect lateral movement, and exposure of services that were never meant to be externally reachable. In mature environments, the risk is less about the tunnel itself and more about the unreviewed exception that makes it possible.

Practitioner Guidance

What to watch for: Treat unexpected forwarding rules, uncommon relay services, and tunnels that do not map to a documented use case as governance signals, not just traffic anomalies. The key judgment is whether the organisation can explain why the path exists, who owns it, and what normal behaviour looks like.

Governance implication: Forwarding and tunnelling should be explicitly approved, documented, and reviewed as part of network change control. Where a service needs indirect access, define the permitted source, destination, and duration of that access so the exception stays narrow and observable.

Practitioner takeaway: If the network path itself is the control bypass, monitoring only the destination is not enough.

Related resources from NHI Mgmt Group

• How should teams secure a self-hosted code server without relying on port forwarding?
• Why is port forwarding a poor pattern for remote access to devices outside your control?
• How should teams reduce the friction and risk of SSH access to remote devices without relying on port forwarding or exposed public endpoints?
• Why do traditional port forwarding and NAT workarounds create security and operational risk for remote access?