Cheat sheet version: one side sends packets to a bogus IP, the other side sends ICMP TTL Exceeded packets back. Some NATs will pass the TTL Exceeded packets because that's how traceroute works; the ICMP packets are indistinguishable from "real" traceroute responses. Once both sides know each other's IP addresses, they open a tunnel by simultaneously talking outbound UDP to each other.<p>This is a clever trick for home NATs, but most corporate networks are doing more than NAT'ing; they're dropping everything but DNS and HTTP from a proxy.
We're experimenting with this technique in our peer-to-peer software. Unfortunately we probably won't have data on what percentage of the time it works for a few weeks.<p>Provided everything goes okay, I'll try to post our data as a follow up.
The trick with priming NAT for receiving bogus inbound TTL-Exceeded ICMP packets is really clever. However keep in mind that this method assumes that:<p>(a) the client knows server's external ("Internet") IP<p>(b) there is exactly one server behind the NAT device<p>Latter is obviously quite limiting unless the "3.3.3.3" changes for every server and the client learns it together with server's external IP. This in turn means that the client still needs to communicate with some 3rd party, so this method only partly alleviates the need for the 3rd party during the tunnel setup process, but it does not completely eliminate it.
Ok, so ICMP is easy to turn off. But why couldn't this technique be done over UDP or TCP? The server could send a UDP packet to a known "fake" address and the client could spoof its source address to penetrate the nat.
This looks to be two things: a way of discovering ips and communicating them without STUN and a simple nat traversal using UDP. Th first is a little clever but not super interesting as signalling channels are a dime a dozen. The second is essentially a small subset of ICE and will fail if anyone remaps ports.
This was dead-ed to allow this re-submission (thanks metabrew).<p>There is a great discussion @reddit <a href="http://www.reddit.com/r/programming/comments/bjc0g/pwnat_serverless_nat_to_nat_udp_hole_punching_for/" rel="nofollow">http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser...</a>
I might be showing my ignorance here, I'm not a network guy, but a vast majority of internal networks use 192.168.1.0/24 192.168.1.1/24 and so on. What happens when the source and destination networks both use the same class C addresses?
very clever. how hard is it for the paranoid IT guy to block ICMP time exceeded packets inbound for 3.3.3.3 but not for other hosts, to stop servers from discovering clients?
Anyone mind posting the arguments for the server and client you're using. The server side segfaults for me.<p>Mine are:<p>Server:
./pwnat -s 2221<p>Client:
./pwnat -c ClientIP 3333 RemoteIP 2221