How NAT State Opens a Path Inward
NAT-enabled open tunnelling hosts expose a different weakness from ordinary one-way forwarding: an untrusted inner packet can become input to a state machine that was designed to protect private clients. The focus here is the transition from identifying a live private address to injecting traffic and receiving a response. Understanding that transition makes it possible to judge the paper’s result precisely, including the role of simultaneous-open TCP behavior, reverse-path filtering, and the services actually running behind the gateway.
A NAT gateway is often treated as a simple address-rewriting device. That description explains the visible result—private addresses appear on the Internet as one global address—but hides the mechanism that makes the result usable. NAT must remember which internal flow created a mapping, which ports and protocol are involved, and which stage a stateful protocol such as TCP has reached. The security of the private side depends partly on that remembered history.
NAT is a state machine, not just a rewrite
Suppose a client on a private network opens a connection to a server on the Internet. The client’s private source address cannot be used as a normal public return address, so the gateway translates the source to its global address. It may also translate the source port. At the same time, it records enough information to associate the server’s reply with the original private client.
That record is commonly described as connection tracking. It includes the addresses, ports, and protocol that identify the flow, along with a state for protocols whose exchanges have stages. For TCP, a gateway does not merely see unrelated packets; it tries to distinguish an attempted connection, a reply to that attempt, an established exchange, and a closing or failed flow. The record persists long enough to make the translated conversation work and to reject traffic that does not fit an expected flow.
This state is what gives NAT its familiar protective effect. An outside host normally cannot send a new connection directly to an arbitrary private client because there is no existing mapping that tells the gateway where the packet belongs. The private address is not routable from the public Internet, and the gateway has no connection history authorizing an unsolicited inbound exchange. NAT is not a complete firewall, but its stateful behavior creates an important barrier when the inputs reaching the state machine have the expected provenance.
The word provenance matters here. Connection tracking sees packet fields and the interface or path through which processing occurs; it does not possess a human understanding of whether a packet represents an honest action by a private client. Under ordinary conditions, a packet claiming to come from an internal address arrives from the internal side, while a packet from the public side has a public source. Those conditions are useful shortcuts for the system’s decisions. An open tunnel can undermine them by allowing an outer Internet sender to supply an inner packet that appears to belong to the private side.
The open endpoint is often the same host as the NAT gateway in the paper’s threat model. It may be a VPN server or a home-router-like system with an Internet-facing interface, a tunnelling interface, and a private network behind it. It blocks ordinary outside connections to private clients. The attacker is remote and off-path: they do not already sit on the private LAN and do not need a session with the gateway’s management service. Their advantage is that the gateway accepts an encapsulated packet from an arbitrary source and passes the decapsulated result into its normal processing path.
The outer packet and the inner packet then play different roles. The outer packet reaches the public endpoint. After decapsulation, the inner source can be a private address and the inner destination can be selected to create a useful flow. If the gateway accepts that inner traffic as ordinary input, connection tracking may record a flow whose fields look plausible even though the packet did not originate through the interface normally associated with the private address.
This is the hidden coupling between the tunnel and NAT. The tunnel does not need to rewrite the NAT table directly. It only needs to feed traffic into the processing path that updates the table. A component intended to provide reachability between networks is now influencing a component intended to remember and police connections. The security consequence emerges from their interaction, not from either component viewed in isolation.
An administrator who checks only the NAT rule may therefore miss the relevant question. The rule can correctly translate private addresses and reject ordinary unsolicited traffic while the tunnel interface provides an alternate way to create or alter the state on which those decisions depend. The meaningful review asks where a decapsulated packet enters the state machine, which source it claims, which interface the gateway expects for that source, and whether the packet can create a mapping or advance a TCP exchange.
From a private-address probe to traffic injection
The paper separates the attack into two related capabilities. First, the remote sender can test which private addresses behind the NAT appear active. Second, after learning enough about a client and the gateway’s state, the sender can inject traffic and receive responses from that client. The distinction is important: discovering that a private address produces a response is not the same as completing a useful application connection.
The address-identification phase uses the open tunnel as a way to send traffic that carries a private inner source. The packet is directed so that the attacker can observe how the gateway handles it. If an address is allocated and active, the resulting behavior differs from the behavior for an unallocated address. The response, or its absence, becomes a signal about the private network. The source describes this as fingerprinting hosts behind the NAT, not as an unrestricted view of the entire private topology.
The signal comes from the gateway’s stateful behavior. When the decapsulated traffic is forwarded, the NAT records an outgoing-looking flow involving the tested private address and the attacker. That state can cause later packets to be translated and delivered in ways that an ordinary Internet-originated connection would not be. The attacker is using the endpoint’s own connection-tracking assumptions as a source of information about what exists behind the gateway.
This does not mean that every private address can be queried successfully. An address may not be allocated. A host may not respond to the relevant protocol. A firewall may reject the traffic. The NAT or tunnel implementation may handle the inner source differently. The paper’s result is that, under the tested conditions, the open tunnel provides a path for this kind of active fingerprinting and state manipulation; it is not a claim that private address space becomes a transparent directory.
The second phase addresses the harder problem of creating a connection to a private client. A normal outside SYN is usually not enough because the gateway has no reason to associate it with a private host. The paper instead uses simultaneous-open TCP behavior. In a simultaneous open, both sides’ connection attempts contribute to the TCP state rather than one side simply initiating and the other merely accepting. That gives the attacker a way to make the gateway see a sequence of packets that fits a state transition it is willing to track.
The attack therefore targets two state machines at once. The private client has TCP behavior that determines whether it treats the exchange as meaningful. The NAT gateway has connection tracking that determines whether packets are translated and forwarded. The open tunnel is the channel that lets the remote sender place carefully chosen inner traffic into the gateway’s view of the exchange. Once the states line up, the sender can complete the connection from the perspective of the private client, inject application traffic, and receive responses through the translation.
The authors demonstrate the capability with a private client running an HTTP service. That example makes the consequence concrete without implying that HTTP is special. The important property is an unauthenticated service that will respond after the transport connection is established. The tunnel does not magically grant access to every application; it makes it possible to reach services that the combined tunnel, NAT, firewall, TCP, and application conditions permit.
The distinction between a forged source and a translated connection also matters. In the one-way proxy case, the attacker can try to make a victim see traffic as coming from the open endpoint or another chosen source, subject to filtering. In the NAT case, the attacker’s goal is to make the gateway maintain a usable mapping to a private client. The result may expose a real conversation through the gateway even though the sender is not physically on the private side. These are related uses of an open decapsulator, but they depend on different state and should not be described as one generic “tunnel bypass.”
The interaction can be summarized as follows:
The diagram is a model of the dependency chain, not a recipe for constructing attack packets. It shows why the attack requires more than an open interface. The endpoint must decapsulate the traffic. The NAT must admit the resulting source and update connection tracking. The private client must respond to the relevant exchange. The return path must preserve enough state for the attacker to observe the response. Failure at any of these stages reduces the result from private-client access to a dropped or one-way packet.
Reverse-path filtering is a boundary, not a universal answer
The paper identifies reverse-path filtering at the tunnelling interface as a major limit on the NAT attack. Reverse-path filtering checks whether a packet’s source address is plausible for the interface on which it arrived. A decapsulated packet claiming to come from a private address may be expected to arrive through the private-facing interface, not through the public tunnel interface. In strict mode, the gateway can treat that mismatch as evidence that the packet is spoofed and drop it before connection tracking can make it useful.
The Linux behavior reported by the authors makes the setting operationally important. They state that Linux defaults to reverse-path filtering being disabled, although some distributions enable it in startup scripts. Loose mode does not impose the same check as strict mode. Enabling strict filtering can therefore block the initial state-manipulation packet, but it may also break legitimate asymmetric routing. A multihomed host can receive a packet on one interface and correctly send the reply through another; strict source validation may reject that traffic even when the route is intentional.
This is a recurring systems lesson. A control can close one transition because it rejects a source-interface combination, yet still be unsuitable as the only defense because it changes assumptions elsewhere. The right question is not “is reverse-path filtering good?” in the abstract. It is whether the deployment can enforce a source-to-interface relationship without breaking the routes and tunnel uses it needs, and whether another path can still feed untrusted inner traffic into connection tracking.
Other conditions bound the paper’s result as well. The demonstrated environment uses Linux virtual machines, a configured NAT, and an open IPIP or GRE interface. Real gateways may differ in how they track TCP, apply firewall rules, handle source validation, or process packets arriving from a tunnel interface. A private network may have no responsive service on the tested port, or its application may require authentication even after the transport connection succeeds. The paper supports a conditional statement: an open NAT-enabled tunnel can expose private clients when these behaviors align.
That qualification should not be mistaken for reassurance. A security boundary is still materially weaker when an attacker can influence the state that enforces it. The number of conditions describes the attack’s applicability, not the absence of risk. It tells an operator what to verify: whether the tunnel endpoint and NAT share a host, whether arbitrary-source decapsulation is enabled, how reverse-path filtering is configured, whether encapsulated traffic updates connection state, and which private services accept unauthenticated connections.
The paper’s proposed defenses follow the same mechanism. Reverse-path filtering can reject the injected private-source packet. Restricting simultaneous-open connections to ports where they are expected narrows the state transition that an attacker can exploit. More directly, if the tunnelling host is also the NAT, encapsulated TCP packets can be prevented from altering connection-tracking state. That approach addresses the hidden coupling itself rather than hoping that the inner source will always look suspicious.
The central conclusion is narrower and stronger than “NAT is broken.” NAT’s ordinary protection assumes that its state reflects legitimate connection initiation. An open tunnel can make an Internet sender look as though they are supplying traffic from the private side, and the gateway may then record or act on that traffic. The vulnerability is the combination of unrestricted decapsulation and stateful translation. Once that combination is understood, the next question is what happens when the translation not only accepts the attacker’s input but also returns replies reliably. That is the step from private-network reachability to a two-way proxy.