Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NAT-to-NAT direct connections with no proxy/STUN needed

samy.pl

Post reply on HN
Print view View original

21–30 of 37 posts

Re: NAT-to-NAT direct connections with no proxy/STUN needed

#21

Post by 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.

Re: NAT-to-NAT direct connections with no proxy/STUN needed

#22

Post by dotBen »

tophercyll wrote: post #13

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.

This sounds like an interesting project, do let us know!

Re: NAT-to-NAT direct connections with no proxy/STUN needed

#23

Post by latitude »

alecco wrote: post #18
tptacek wrote: post #14

Earlier quoted context omitted.

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

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 scenari…

> Much better security-wise than most scenarios nowadays.

Can you elaborate on this?

Re: NAT-to-NAT direct connections with no proxy/STUN needed

#24

Post by huhtenberg »

tophercyll wrote: post #13

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.

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.

Re: NAT-to-NAT direct connections with no proxy/STUN needed

#29

Post by aidenn0 »

tptacek wrote: post #6

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…

This is clearly only designed for home NATs. The simple fact of the matter is that most home users don't want to know how to forward ports so that they can use p2p software.

This allows one to write software so that such users can use p2p software without having a central server to discover IP addresses.

Re: NAT-to-NAT direct connections with no proxy/STUN needed

#30

Post by huhtenberg »

malbs wrote: post #28

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?

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