From Packet Forwarding to Network Reachability
The open-tunnelling-host problem is best judged by capability, not by protocol label. One-way proxying, NAT-state manipulation, and two-way proxying all begin with an endpoint accepting an encapsulated input, but they give the sender different powers because different state owners and return paths become involved. The useful judgment is to identify what the sender can send, receive, alter, or reach—and then ask what changes when the payload is an Ethernet frame rather than an IP packet.
The distinction prevents two opposite mistakes. One mistake treats every open endpoint as though it already provides complete access to a private network. The other treats a one-way forwarding result as harmless because no reply is guaranteed. The evidence supports neither shortcut. It describes an escalation of possible capabilities whose conditions must be traced separately.
The same opening, different capabilities
At the starting point, the sender has found a tunnel endpoint that decapsulates traffic from an arbitrary source. That fact establishes an untrusted input into the host’s packet-processing path. It does not yet specify the outcome. The endpoint may forward the inner packet toward a public target, feed it into a NAT connection tracker, translate a reply back to the sender, or deliver an Ethernet frame to a bridge. The surrounding system determines which branch is available.
A compact comparison makes the differences visible:
| Capability | State or interface that matters | What the evidence supports | What it does not establish |
|---|---|---|---|
| One-way proxying | Ordinary forwarding after decapsulation | Traffic can be sent through the endpoint; the target may see the endpoint’s address | A readable reply or access to an arbitrary private service |
| NAT-state path | Connection tracking and translation on the gateway | Private addresses may be fingerprinted; under the tested conditions, traffic can reach a private client and responses can return | A universal bypass of every NAT, firewall, or private application |
| Two-way proxying | A translation mapping that preserves the return path | The sender can receive replies and, in the demonstrated case, complete a TCP exchange through the proxy | An arbitrary spoofed identity or success against every target |
| Layer 2 path | A GRETAP interface joined to a private bridge | Ethernet broadcasts and local-network protocols may reach the LAN | Proof that every demonstrated LAN attack works on every responding host |
The table is not a ranking of four unrelated vulnerabilities. It is a map of how the same missing peer decision can interact with progressively more powerful surrounding machinery. A one-way proxy borrows the endpoint’s position in the forwarding path. The NAT case borrows the gateway’s assumptions about where a connection began. The two-way case borrows a translation mapping that connects both directions of an exchange. The Layer 2 case borrows membership in the LAN’s local delivery domain.
This is also why “reachability” has more than one meaning. A sender may be able to make a packet reach a target without being able to observe the target’s reply. They may be able to make a NAT record a flow without being able to complete a useful application session. They may receive a TCP response through a two-way proxy without being able to select any source identity they want. A bridge may deliver a broadcast frame to many hosts, but a particular LAN protocol may still require an address, a reply, or a device behavior that is not present.