Overview
This series explains how an open tunnelling host—an endpoint without authentication, encryption, or a specified remote peer—can turn public packet delivery into one-way forwarding, NAT-state manipulation, a reply-capable proxy, or GRETAP access to a private LAN. It traces each state and interface transition, interprets nine Internet-wide scans as bounded exposure signals, and matches defenses to peer authorization, inner filtering, state isolation, bridge containment, and loop control. The evidence shows conditional capabilities, not universal compromise.
Learning outcomes
- An open tunnel is defined by unrestricted peer admission, not by GRE or IPIP alone.
- One-way forwarding does not imply a readable reply; return paths require additional NAT and routing state.
- NAT-state and GRETAP exposure are conditional interactions with connection tracking, bridges, Linux behavior, and local services.
- Internet-wide scan counts show widespread candidate behavior, not confirmed compromise or universal exploitability.
- Effective defense follows the path: authorize peers, filter inner traffic, isolate state, contain broadcasts, and detect loops.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What is an open tunnelling host?
An open tunnelling host has a tunnel interface without authentication or encryption and without a specified remote endpoint. It can decapsulate traffic from arbitrary sources and may serve or forward the inner object.
Can an open tunnel reach private clients?
It can under the paper’s tested NAT conditions, but open decapsulation alone does not prove private-client access. Connection tracking, simultaneous-open TCP behavior, reverse-path filtering, firewall policy, and a responsive service all matter.
What do the paper’s Internet-wide scan results show?
They show public addresses exhibiting behavior associated with open tunnelling, not confirmed compromise of their private networks. The nine scans measured bounded signals, and packet loss, overlap, time, and probe design limit what each result proves.
How should organizations secure an open tunnelling host?
Organizations should authorize explicit peers first, then constrain inner traffic and the state or interfaces it can reach. Depending on the design, use a protected underlay, isolate NAT state, contain broadcasts, and detect re-encapsulation loops while testing routing constraints.