When an Open Tunnel Becomes a Private-Network Bridge
This series examines the security exposure of open tunnelling hosts: Internet-facing systems that accept encapsulated traffic without adequately identifying or restricting the remote peer. The focus is not GRE as a protocol in isolation, but the relationship among a public tunnel endpoint, the NAT state or private LAN beside it, and a remote sender who can submit packets. The practical goal is to learn how to trace that traffic across the endpoint and judge what boundary it can cross.
A tunnel is usually described as a private route through a public network. That description is useful, but incomplete. A tunnel endpoint does not merely carry traffic; it receives a packet, removes one layer of headers, and decides what to do with what remains. If that endpoint accepts an encapsulated packet from an arbitrary source, the supposedly private route can become a public input into the forwarding system. The important question is therefore not simply whether a tunnel is present. It is who is allowed to use the decapsulator, and what the decapsulated traffic is allowed to reach.
That distinction matters because tunnelling itself is not suspicious. Organizations use tunnels to connect otherwise separate networks, reach a private service from a remote site, support a VPN, or carry a payload across a network that does not natively route it. In all of those cases, encapsulation solves a transport problem. The security problem begins when the endpoint’s transport behavior is allowed to decide, implicitly, that any packet capable of reaching the public address is entitled to participate in the private path.
A tunnel carries packets; it does not automatically establish trust
Encapsulation is a way to place one packet inside another. The inner packet—the payload—keeps the addressing and protocol information needed for its eventual destination. An outer delivery header gets it to a tunnel endpoint. That endpoint removes the added headers and then serves or forwards the inner packet according to the surrounding network’s rules. In a normal site-to-site arrangement, the two ends are known in advance, and those rules are part of a larger design that determines which packets are legitimate.
The two layers answer different questions. The outer header answers, “Where should this encapsulated object be delivered?” The inner header answers, “After it is opened, where should the payload go?” A router can be correct about the first question while having no reliable answer to the second question’s security implications. Once decapsulation occurs, the inner source, destination, protocol, and sometimes broadcast behavior become inputs to ordinary host and network processing. The endpoint must connect that processing to a policy about trusted peers; otherwise a successful delivery to the outer address is doing more work than an administrator may realize.
RFC 2784 defines Generic Routing Encapsulation, or GRE, in deliberately general terms: an arbitrary network-layer protocol can be carried over another arbitrary network-layer protocol. Its format identifies the payload and provides optional integrity checking for the GRE packet, but the specification does not decide when a packet should be encapsulated or which remote system may submit one. An optional checksum can help detect corruption; it does not, by itself, establish who sent the packet. The RFC’s security discussion makes the same distinction from another angle. Routing can follow the ordinary IPv4 model, but filtering may need to inspect the contents inside the GRE packet or terminate the tunnel at a firewall.
That separation is central to the research subject. A packet can be correctly formed according to an encapsulation format and still be unacceptable because it came from an untrusted peer. Protocol mechanics answer how to unwrap the packet. Deployment policy must answer who may cause the unwrap and which interfaces may receive the result. IPIP and GRE, as studied in the paper, do not provide authentication or encryption by default. Security therefore depends on controls around the tunnel as much as on the tunnel header itself.
This also explains why the paper is not claiming that every GRE or IPIP endpoint is dangerous. A fixed remote endpoint, source filtering, reverse-path checks, a firewall, or a restricted forwarding policy can prevent arbitrary traffic from becoming useful after decapsulation. The relevant subject is the open configuration, not the protocol name printed on the outside of the packet. An endpoint that accepts only a known peer and an endpoint that accepts any source may use the same encapsulation format while presenting very different attack surfaces.
What makes a tunnelling host open
The paper uses a specific definition. An open tunnelling host has a tunnelling interface without authentication or encryption and without a specified remote tunnelling endpoint. When the remote address is left empty, the host can decapsulate packets arriving from any source instead of limiting them to a known tunnel peer. It may then serve the inner packet locally or forward it onward.
The definition combines two missing decisions. The first is whether the packet and its peer have been authenticated or protected. The second is whether the endpoint has a constrained set of places from which tunnel traffic may arrive. Removing both decisions leaves the endpoint with a simple mechanical rule: if the outer packet reaches the tunnel interface and looks decodable, process what is inside. That rule may be convenient for a multipoint arrangement or an experiment, but it also makes the public interface an input to private-network processing.
That missing peer decision changes the endpoint’s role. Imagine a remote sender addressing an outer packet to the public tunnel host. Inside it is another packet whose source and destination were chosen by the sender. Once the outer layer is removed, the endpoint sees an ordinary inner packet and may process it through its normal forwarding path. The sender has supplied input to that path without first proving that they belong to the tunnel.
The simplest consequence is a one-way proxy. The endpoint forwards traffic toward a victim, so the victim sees the proxy’s address rather than the sender’s direct address. If the surrounding network allows source spoofing, the endpoint can also carry traffic with a misleading source. This creates a useful vessel for denial-of-service traffic and can conceal the sender’s origin from the victim. But one-way means exactly what it says: the endpoint may forward the sender’s traffic without providing a reliable route for replies back to that sender. Sending through a host and receiving through it are separate capabilities.
The proxy label is useful because it shifts attention from the tunnel’s intended purpose to the endpoint’s actual behavior. The host may have been configured to connect two legitimate networks, but if it accepts arbitrary outer sources, an unrelated sender can borrow its forwarding position. The victim does not need to know whether the inner packet came from a normal tunnel peer, a misconfigured router, or an attacker. The endpoint has already performed the trust-sensitive action: it accepted the packet and released the inner traffic into another path.
The following model captures the boundary without treating every consequence as identical:
The diagram’s branches are not interchangeable attack recipes. They are different consequences of allowing an untrusted packet to enter a trusted processing path. With only ordinary forwarding, the result may be a one-way proxy. If the endpoint also owns a stateful NAT, the inner packet may interact with connection tracking that was designed to record traffic from the private side. If address translation returns replies to the sender, the endpoint becomes a two-way proxy. If the endpoint carries Ethernet frames into a bridge, the reachable surface can include the LAN’s broadcast and configuration traffic.
The bridge hidden inside the endpoint
The paper’s most important shift is from “an open host can forward traffic” to “an open host can touch the state and interfaces that protect a private network.” In controlled Linux experiments, the authors show that a NAT-enabled open tunnel can be used to fingerprint active private addresses and inject traffic toward clients behind the NAT. The mechanism depends on how decapsulated packets influence connection-tracking state, so it is not a universal bypass of every NAT. Reverse-path filtering, firewall policy, TCP behavior, and the services actually running on private clients all matter.
This is why the private address range alone is not a sufficient security boundary. A private address is normally protected by the fact that the public side cannot originate a valid path to it. But if an open tunnel injects a packet into the gateway’s internal processing path, the address is no longer being evaluated only by the ordinary Internet-facing interface. The gateway may treat information carried by the packet as evidence about a connection that should exist. A control intended to protect the private side can therefore be undermined by the way the tunnel endpoint feeds the control’s state.
A related configuration can give the sender a return path. The paper calls the result a two-way proxy and demonstrates that it can support a TCP handshake with a target while the target sees the proxy’s address. Two such proxies can also be induced to forward traffic toward each other, creating a loop whose impact depends on translation, spoofing, and path conditions. The feedback channel is the crucial escalation: the sender can observe what the endpoint causes, not merely send into it. That difference expands the possible abuse from concealed traffic generation to interactions that depend on replies and application state.
Layer 2 tunnelling changes the picture again. GRETAP carries Ethernet frames rather than only routed IP payloads. When an open GRETAP interface is bridged to a private interface, broadcasts and local-network protocols can cross the boundary. The paper demonstrates consequences involving MAC-address exposure, ARP, DHCP, IPv6 router advertisements and DNS configuration, and re-encapsulation loops. These findings are tied to the tested Linux behavior and to conditions such as address prediction; they do not mean that every GRETAP host permits every demonstrated attack. The important architectural change is that the endpoint is no longer just deciding where an IP packet should be routed. It is participating in the LAN’s local delivery domain.
The authors’ Internet measurements show why this is an operational issue rather than an isolated laboratory curiosity. Across nine scans, they report 438,280 probed addresses identified as potentially vulnerable. When both probed and replying addresses are counted, the paper reports 446,277 unique collected addresses across 127 territories and 1,861 autonomous systems. Those are measurements of observable behavior, not a list of confirmed compromises. The scan methods were deliberately less intrusive than the follow-on attacks, and the GRETAP broadcast result in particular can include hosts that forward broadcasts without satisfying every condition of the demonstrated LAN attacks.
The distinction between possibility and proof is part of the finding. The controlled experiments establish that particular combinations of tunnel behavior, NAT state, bridge configuration, and operating-system behavior can produce the reported effects. The Internet scans estimate how often useful signals appear in the wild. They do not independently verify the private topology or the success of every attack against each responding address. A serious response must preserve both facts: the exposure class is real, and the headline count still needs to be interpreted according to what the probe actually measured.
The durable question is therefore a systems question: what untrusted input can the endpoint decapsulate, which state can that input change, which interface can it cross, and can the resulting traffic return or loop? The answer determines whether the tunnel is simply a transport, a one-way proxy, a path into a stateful gateway, a two-way relay, or an unintended bridge into the private network. The next step is to examine the first transition closely—what decapsulation does, and what the endpoint fails to decide when it accepts a packet from an arbitrary source.