The Security Lesson of Open Tunnelling

An open tunnel becomes a bridge into a private network when the endpoint accepts an untrusted encapsulated input and then lets that input use the state or interfaces that make the private network reachable. This final synthesis reconnects the paper’s central subject—open tunnelling hosts—to the four capabilities it demonstrates: one-way forwarding, NAT-state manipulation, two-way proxying, and GRETAP access to a LAN. The durable judgment is not that every tunnel is unsafe, but that a tunnel must be evaluated by who may cause decapsulation, what state the resulting traffic can change, and whether replies or local frames can cross the boundary.

That model is more useful than either a protocol-level verdict or a single vulnerability label. GRE is an encapsulation format; NAT is a stateful translation system; a bridge is a local delivery system. None of those names, by themselves, says whether an Internet sender can use the system as an authorized peer. The risk appears when their interfaces are joined without an effective trust decision.

A single failure, four levels of exposure

The common starting condition is open decapsulation. The paper defines an open tunnelling host as one with a tunnelling interface that lacks authentication or encryption and does not specify a remote tunnelling endpoint. With the remote address left empty, the host can decapsulate traffic from any source and serve or forward the inner object. This is narrower than saying that every unauthenticated tunnel is exposed: a deployment may restrict peers, filter traffic, validate sources, or limit forwarding even when the underlying protocol does not provide those properties by default.

The first consequence is a one-way proxy. An arbitrary sender supplies an outer packet addressed to the public endpoint and chooses the inner source and destination. The endpoint removes the outer layer and forwards the inner packet. If the surrounding network permits the source behavior, the target sees traffic coming through the endpoint rather than directly from the sender. That can conceal the sender from the target or carry spoofed denial-of-service traffic. But the path is one-way: successful forwarding does not guarantee that a reply will travel back to the sender.

The important transition is from packet origin to state ownership. A one-way proxy borrows the endpoint’s position in the routing path. If the same endpoint also owns a NAT, the decapsulated packet can enter connection tracking. NAT normally remembers the address, port, protocol, and transport state of a flow initiated by a private client, then uses that record to translate replies. An inner packet with a private source that arrived through an open tunnel can challenge the provenance assumption behind that record.

In the paper’s controlled Linux experiments, this interaction lets a remote off-path attacker test which private addresses appear active and then manipulate TCP state so traffic can reach a private client and responses can return. The demonstrated path relies on simultaneous-open TCP behavior and on the gateway accepting the relevant inner source and state transitions. Reverse-path filtering, firewall rules, the gateway implementation, the private client, and the service behind it all bound the result. The paper shows a conditional path through a stateful boundary, not a universal bypass of every NAT.

The third level adds a reliable return channel. A two-way proxy is a NAT-enabled open host whose translation state lets replies reach the sender. The target sees the proxy’s address, while the sender receives the target’s response through the proxy. That feedback can support a TCP handshake and application-layer interaction under the conditions demonstrated by the authors. It expands the attacker’s options because a response can guide the next action, but it does not provide an arbitrary identity. The proxy’s address remains the visible source, and the handshake requires the source-handling behavior described in the paper.

Two two-way proxies can also turn the return path into a forwarding loop. Compatible mappings cause each endpoint to send traffic toward the other.