Hacker News new | comments | show | ask | jobs | submit login

Well, you need a 3rd machine to route traffic between two machines if both are behind NAT^. It was my understanding that supernodes were (also) used for this.

^Unless you can predict the translated source port

No hole punching method will work for all combinations of firewall at each end of the intended communications channel. If connecting the clients directly in either direction after the initial negotiation fails then Skype (and tools like it) will instead send the data via a 3rd host (which sits in the middle and acts as a bridge between the two TCP streams).

If they get a wiretap order and your client can normally achieve a direct connection with a particular user, they could just emulate connection failure and the clients would revert to using the proxy without informing the user (after all, they are designed to do that for the sake of resilience of the user experience). You can probably see where the traffic is going, the client may even tell you without you having to dig far, but you won't know if you are going via the middle-man server(s) because of a general network issue that is stopping a direct connection being possible or if it is because of a wire-tap.

Doesn't contradict the parent post. For hole punching you need to know the source (host+port) your peer sends traffic from. If the source port is randomised (or already used by someone for udp if nat prevents sharing), hole punching will fail.

That's where the third party supernode comes in; the sending peer tells the supernode which source port it is using to send to the non-supernode.

If you're natted, the source port seen by supernode doesn't have to be the same as the one seen by others. Someone on your network may be talking to the same supernode already, so the conflict has to be resolved by some remapping in the nat.

You then retry with an alternate supernode.

Unless your NAT is randomising ports by default. Then you will always get the wrong answer.

No. I don't know why you're not listening to what he's saying. I can tell you, from currently writing code that does STUN negotiation, unless you have two peers behind full-cone NAT (which is rather rare actually), you do not need to know what the port mapping/translation is.

I have a sideband connection to a server, and I tell it to route my negotiation packets to my peer's sideband connection. I literally never even touch a UDP port or connection, and the library I uses establishes a connection using STUN(-light). And from having read the source, it doesn't explicitly determine or set the mapping (using uPNP) either.

In my work with VoIP that situation was pretty much the default assumption. I agree that it's only the double NATed situation that's hard to handle, but stay by my opinion that sometimes it's just impossible to resolve without a middle man. But it depends on many things - clients, routes, number of people in local network using the same application, etc. Sometimes you just have to fall back to proxying everything.

>stay by my opinion that sometimes it's just impossible to resolve without a middle man

Right, that's why TURN is part of ICE.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact