Protocol tunnelling is the practice of carrying one network protocol inside another protocol’s payload. It is used to traverse filters, NAT devices or networks that only allow the outer protocol, and can be legitimate for VPNs, encapsulation and bypassing restricted transport paths.
How protocol tunneling works
Protocol tunneling places one protocol inside another protocol’s payload so traffic can cross networks that only permit the outer protocol. The outer session becomes the carrier, while the inner protocol’s packets, commands, or data are embedded and recovered at the destination.
That wrapping can be as simple as encapsulating traffic to preserve compatibility, or as deliberate as using an allowed protocol to move through restrictive firewalls, NAT, or inspection points. The security significance is that policy often sees only the outer layer, not the real application or command path carried within it.
Why defenders care about tunneling
Protocol tunneling is not inherently malicious, because VPNs, transport encapsulation, and some enterprise connectivity patterns depend on it. The same technique becomes risky when it is used to smuggle disallowed services, bypass egress controls, or hide command-and-control traffic inside apparently benign flows.
Defenders therefore treat the technique as a trust-boundary problem, not just a transport problem. A network that allows HTTPS, DNS, or SSH may still be vulnerable if those channels are permitted without considering what is being carried inside them.
Protocol tunneling often overlaps with egress filtering and traffic normalisation, because the central question is whether the allowed outer protocol is being used for its intended purpose or as a container for another communication path. For an ATT&CK-oriented breakdown of that abuse pattern, see the T1572 Protocol Tunnelling Defensive Guide.
Common tunneling patterns and legitimate uses
Legitimate tunneling includes VPNs, secure remote access, site-to-site connectivity, and protocol encapsulation where the outer transport is chosen for reachability or compatibility. In those cases, the goal is usually to preserve confidentiality, integrity, or interoperability while crossing an intermediate network.
Abusive tunneling uses the same mechanics for concealment or policy evasion. Examples include wrapping remote access, file transfer, or covert control traffic inside DNS, HTTPS, SSH, or other commonly allowed services. Those patterns are especially attractive where direct connections are blocked but outbound web or resolver traffic remains open.
Detection becomes easier when the outer protocol no longer behaves like its normal workload. Unusual destinations, long-lived sessions, atypical packet sizes, or unexpected request cadence can indicate that the visible protocol is merely carrying something else. NHIMG’s Beaconing and C2 Detection Guide is useful here because tunneling often shows up as beacon-like network behaviour.
Exposure, controls, and investigation focus
The key exposure is that filtering based only on port or protocol name can miss the real activity. If an environment allows outbound tunnels by design, security teams need to know which tunnels are sanctioned, which endpoints may initiate them, and which telemetry can still reveal misuse.
Investigation usually starts with asset inventory and network policy review: what tunnel software exists, which systems may run it, and which external services are approved. When abuse is suspected, analysts should review proxy, DNS, firewall, and flow logs for destination drift, policy exceptions, and traffic that does not match the expected business use.
If a tunnel platform itself is being abused, platform hardening and token or configuration review matter as much as packet analysis. NHIMG’s Cloudflare Tunnel and trycloudflare abuse page is a practical example of how tunnel abuse can be detected, blocked, and responded to in the field.
For broader remote-access exposure, compare tunnel use with established remote connectivity controls and hardening practices. The VPN Security Guide helps frame where legitimate tunneling fits, and where a perimeter device or remote-access path becomes the real security boundary.
Risk and Threat Considerations
Protocol tunneling creates a visibility gap because defenders may permit the outer protocol while failing to inspect or govern the inner one. That makes it attractive for bypassing egress restrictions, hiding command-and-control, and moving data through channels that look ordinary at first glance.
Failure mechanism: Controls that trust the outer protocol alone can be bypassed when the inner payload is not validated, normalised, or policy-checked, allowing covert traffic to blend into permitted network paths.
Impact: Attackers can maintain persistence, exfiltrate data, or operate covert management channels while avoiding simple port-based blocking and some forms of content inspection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1572 — Protocol Tunneling | Defines protocol tunneling as an adversary technique used to carry traffic inside another protocol. |
| Recommendation — Map observed traffic to T1572 and hunt for covert channels, egress evasion, and tunnel-based C2. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity and confidentiality of data at rest are protected | Tunneling can conceal or protect payloads in transit, so transport confidentiality and integrity controls matter. |
| DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Detecting tunneling depends on monitoring network flows, destinations, and protocol anomalies. | |
| Recommendation — Protect permitted tunnels with authenticated encryption and verify payload handling inside allowed paths. Monitor network services for anomalous outer-protocol use and investigate traffic that breaks normal baselines. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Protocol tunneling is primarily a network monitoring and defense problem when it bypasses allowed transport paths. |
| Recommendation — Instrument perimeter and internal network telemetry to detect unauthorized tunnels and policy violations. | ||
| OWASP API Security Top 10 | API7 — Server Side Request Forgery | Some tunnel abuse patterns exploit server-side request paths to reach restricted networks through permitted services. |
| Recommendation — Review server-side outbound request paths for unintended proxying or tunnel-like access to internal resources. | ||
Practitioner Guidance
Why practitioners should care: Treat tunneling as an approved-path governance issue, not just a firewall exception. If your environment permits VPNs, reverse tunnels, or transport encapsulation, define which uses are sanctioned and which telemetry proves they are operating within policy.
What to watch for: Watch for repeated outbound sessions that do not match the business role of the host, especially when the destination, cadence, or payload size is inconsistent with normal application behaviour. That mismatch is often the earliest practical clue that the outer protocol is carrying something else.