
NAT-to-NAT direct connections with no proxy/STUN needed - metabrew
http://samy.pl/pwnat/
======
tptacek
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.

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.

~~~
alecco
The forest, dude, the forest.

Think about the masses behind home NAT routers and P2P. From my comments on
reddit
[http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser...](http://www.reddit.com/r/programming/comments/bjc0g/pwnat_serverless_nat_to_nat_udp_hole_punching_for/c0n2kpp?context=3)

    
    
        Server publishes it's NAT external IP and a hash of its (RSA) public key.
        [ICMP] Client MAC(client public key + server public key hash) -> Server
          (Server checks the key hash the client got is valid)
        [UDP] Server MAC(server public key + hash of client public key) -> Client
          (Client checks the public key hash matches the server's public key) ...
    
        The publishing first step could be just an URI like:
        pwnat://<server external ip>/pubkey_hash:<pub key hash>
        The hash could be base64 encoded in just 24 chars. Of course this
        is thinking out loud. There are protocols for this already.
    

Thats of course drafty and not really checked, but you can get the idea and
improve on it. It looks very doable.

Also think about P2P and privacy, so far the middle men (e.g. Skype) would
know who is talking to who. This is a major step.

And there's plenty of space on the spoofed ICMP reply to put anything relevant
to start a conversation (randomized ports, hashes, keys, nonce).

~~~
tptacek
You're right. It's a big deal. It's just not a big deal for corporate
networks.

~~~
alecco
Yeah, it's not for corporate networks.

But, for example, corporate network (and security) could benefit from this,
too. Virtual P2P meetings could be done this way without a third party central
server or the need to install a special server software. The meeting initiator
can send an email with an URI and everyone else just clicks on it running the
relevant client software. Much better security-wise than most scenarios
nowadays.

Cross-continent meetings are a major pain when it's over VPN or centralized.

~~~
latitude
> _Much better security-wise than most scenarios nowadays._

Can you elaborate on this?

~~~
alecco
Note I'm kind of thinking out loud, and in this idea was about P2P
conferencing, so it's not for local network or well connected offices. More
like a very typical scenario of several people connecting from different
locations (e.g. working from home plus remote offices.)

Using a VPN (centralized) adds a lot of latency and degrades the experience.
Using a third party service (MS, WebEx, Lotus) often adds trusting them with
your dearest corporate secrets and allows them (and the authorities on their
respective countries) to spy on the conference or even simply detect your
users's IPs to direct attacks to their more vulnerable home computers full of
interesting data.

With some service set up like this the users can just have an "initiator"
"server", who's software just checks its NAT external IP (thousands of
existing free services and web pages give you this) and creates a meeting URI.
They send it by some secure channel (e.g. email over vpn) to the other
parties. The rest conenct to the initiator "server" and discover each other's
IP. If the protocol is carefully designed the clients and server can have a
shared secret on the URI to avoid Man-in-the-middle. Voilà!

This can easily be an open source product with zero server costs (unlike
WebEx, Skype, MS.) Of course, this works only for clients with NAT access and
others should connect in other ways (e.g. HTTPS and/or UPnP.)

My point was that even the corporate network and security teams can benefit
from this in some way. It's not just to set up quake servers on college
networks.

------
tophercyll
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.

Provided everything goes okay, I'll try to post our data as a follow up.

~~~
huhtenberg
You should make a test version of your p2p client and ask here (and, say, on
Reddit and p2p-hackers list) to help test it. You will get a few hundred
sample points in a matter of hours.

------
latitude
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:

(a) the client knows server's external ("Internet") IP

(b) there is exactly one server behind the NAT device

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.

------
billpg
Isn't 3.3.3.3 an IP inside the General Electric Company? What happens if they
ever decide to use it?

------
00joe
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.

~~~
tptacek
Because the ICMP message is a case where NATs are already programmed to allow
arbitrarily-sourced traffic to pass. The point is that the trick discovers the
client's address, so they can establish direct 2-way comms.

------
jbeda
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.

~~~
jbeda
For something similar check out scottlu's FWD —
[http://www.scottlu.com/2008/05/fwd-tool-for-peer-to-peer-
por...](http://www.scottlu.com/2008/05/fwd-tool-for-peer-to-peer-port.html).
It uses xmpp as the signalling channel and the ICE implementation from
libjingle. This is the P2P stack we built for Google Talk several years ago.
If you get this stuff right you can establish a direct connection when both
parties aren't behind a full cone NAT — 90+% of the time.

------
davidu
I know Samy well. Probably more than 10 years.

He's one of the best of the best. I'd hire him in a second if he'd let me.

------
alecco
This was dead-ed to allow this re-submission (thanks metabrew).

There is a great discussion @reddit
[http://www.reddit.com/r/programming/comments/bjc0g/pwnat_ser...](http://www.reddit.com/r/programming/comments/bjc0g/pwnat_serverless_nat_to_nat_udp_hole_punching_for/)

------
malbs
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?

~~~
huhtenberg
Source is talking to the external IP of destination's NAT device and vice
versa. They are not talking using their internal IPs.

------
rubyrescue
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?

~~~
d4rt
On most firewalls this should be trivial. On an Cisco ASA:

access-list BLOCK_TIMEEXCEEDED deny icmp any any time-exceeded

(iirc) and then apply the acl. You should block all hosts as any could be
chosen by the person. They could change 3.3.3.3 to any other IP.

NAT is not a security mechanism and does not ensure your hosts are protected.
Denying tunneling of any kind is difficult as there are tunnels over most
protocols. I'm not aware of any perfect prevention or detection technique, but
detection could in the case of a moderate amount of data transit could
possibly be done via analysis of netflow records.

~~~
tophercyll
And in fact they almost certainly will choose a different host. Our plan is to
just buy an extra IP for one of our VPS machines and leave it unused.

------
deutronium
Anyone mind posting the arguments for the server and client you're using. The
server side segfaults for me.

Mine are:

Server: ./pwnat -s 2221

Client: ./pwnat -c ClientIP 3333 RemoteIP 2221

------
vijayshankar
Is there a possible segfault at line 108 in udpclient.c? pport is a junk
pointer at this line: sprintf(pport, "2222");

~~~
wingo
In v0.2-beta, the line reads `sprintf(pport_s, "2222");'.

------
defenestrator
how exactly is this different than netcat -u ?

