RSS
When two machines running Skype need to communicate directly, but are both behind a NAT firewall, there's a clever trick that's employed to start a communication channel. It works like this:
First, both machines open a connection to a non-firewalled server. The server takes note of the source port (which may have been altered by the firewall) and sends this information to the other party to give it an idea of what port future connections might be coming from.
Client A then attempts to connect to a range of ports on client B's machine. All these requests will fail at client B's firewall, of course. However, in the process a side effect has occurred. Client A has told its own firewall to allow traffic from all of client B's scanned ports! Now, when client B attempts to connect to client A, assuming its outgoing port was previously scanned (which it likely will be), the request will get through to client A's machine.
If all else fails, both machines can use a central server to proxy their connection, but the UDP hole punching trick will typically allow two NAT firewalled machines to communicate directly, which means less latency and a significantly lighter load on the server.
Resources:
How Skype & Co. get round firewalls - Link
RFC3489 STUN - Simple Traversal of UDP through NAT - Link
Client A then attempts to connect to a range of ports on client B's machine. All these requests will fail at client B's firewall, of course. However, in the process a side effect has occurred. Client A has told its own firewall to allow traffic from all of client B's scanned ports! Now, when client B attempts to connect to client A, assuming its outgoing port was previously scanned (which it likely will be), the request will get through to client A's machine.
I don't think this is correct. Portscanning a remote system won't "tell the firewall to allow traffic from [...] the scanned ports". This would be a really lame way to firewall. Instead, firewalls and NAT systems work on established sockets. Another socket connection that is utilizing the same port won't magically get through just because that port has been used recently.
Reply to this comment
Think about how a connection is created in a typical scenario:
You send a packet from 1.2.3.4 port 1234 to 5.6.7.8 port 80. When this packet goes through your NAT router, it creates a lookup table entry that says 1.2.3.4 port 1234 is communicating with outside server 5.6.7.8 port 80.
5.6.7.8 then responds with a packet from 5.6.7.8 port 80 to 1.2.3.4 port 1234. When your NAT router sees this, it looks at the lookup table, checks to see if there was a mapping there, and determines whether to send the packet on (which it does in this case) or discard it.
So essentially, sending a packet to a machine on the other side of your NAT router causes the router to allow incoming packets from that machine, with the specific from and to ports that the original packet contained.
When two clients, both behind their own NAT router, need to talk to eachother, they can coordinate a set of ports with a third-party public server. Then it's a matter of punching holes through their own routers until packets start coming through and both sides see traffic.
FYI, this is made much easier with UDP (as opposed to TCP), as there are no sequence ids to deal with.
Reply to this comment
Why client A scans a range of ports B? Why not use one port?
Reply to this comment
For how long does the firewall stay punched?
Does anyone know a good article about punching a hold in a firewall using TCP?
Yaron
http://topitlinks.com
Reply to this comment
How can i view webcam and call pc to pc in yahoo messenger if i'm only connected in proxy server? why in skype i can view webcam and call pc to pc?
Reply to this comment