next »

[Phaëton]

How does skype 'answer' calls without a forwarded port in the NAT?

or uTorrent serve data from behind a firewall without a DMZ or NAT table entry?

Does skype phone home on a strobe like, 'are there any incoming calls?' over and over?

Im thinking about designing a p2p style cloud application and im asking because I want to know if
on the client side Im gonna be able to set up a server to 'listen' for a request, or
do i phone a 'switch application' that will relay a status every time i ping it from the client
and then relay the messages through a server in the cloud?

I hope this makes sense.  I know i can use ajax to send requests every x seconds, and get a
'incomingmessage waiting' or 'incomingmessage null' signal and use the ajax response
answer as an 'incoming' stream to the client ... thats my best guess.
any other techniques to 'listen' client side? ServerSocket style?

[perkiset]

When your machine fires up it opens an outgoing connection to the Skype central switch, which allows for bidirectional discussions. In other words, since your app punched an outgoing hole through the wall, there's now the ability for Skype to push back at you. Same as GoToMyPC and similar.

At the socket level, if you can get a user to start an app that talks to you, then you can talk to them. This is how a great bulk of trojans work. Start a connection to, say, TFTP (a common vector for this sort of thing) and then you can talk with the machine at leisure. If you think about it, it's even how a website works: you open a socket to the server and await the response. There's no inbound pinhole that allows for this activity. The way that this can be shut down is called egress filtering, which means that packets going *out* get filtered as much as packets coming in. Not a lot of folks do that because it can be a management nightmare.

[nop_90]

http://en.wikipedia.org/wiki/UDP_hole_punching
It only works with UDP. You basically punch a hole thru the firewall.
It supposedly can be done with TCP but I have not tried it.
Problem with UDP unlike TCP is does not guarantee packet delievery. If that is important then u make some sort of TCP like proto overtop UDP.

If you have access to the actual TCP stack on the machine, you could make a driver that swaps the SYN and FIN flags on the TCP packet. (i think that is the flags, look up TCP packet on web).
That way incoming TCP appears to be outgoing 

[perkiset]

I was perhaps too aggressive with the term "punching a hole" - by initiating a connection, you have gone through the firewall and now packets can be bidirectional - at least appear to be. The important part is that packets coming southbound into the firewall need to be in response to a stateful outbound request - otherwise the normal blocking occurs.

I think it's actually like this: exe on client machine sends a request to server with a TTL of something like 10 seconds (timing is changed to protect the innocent). in 9 seconds, server response with "I'm still here" and the client kicks off another. If there's a phone call, then the response comes back immediately with "There's a phone call!" And the client initiates connection to the peer. Just like a web page that takes too long, the stateful firewall will hang on to your request until the TTL dies or there is a response, leaving room for an instant "pseudo-push" be "responding" to the internal request.

[nop_90]

You may be right about many things perks, and u may know more about DBs etc then me, but in this case u are absolutely wrong
The "term" "hole punching" is literally how it works.

How does skype 'answer' calls without a forwarded port in the NAT?

The question deals with NAT, but with firewall usualy a similar technique can be used, since firewall and NAT are basically the same thing.
The wikipedia article, like most things spouts a lot of crap.

Simplest way to understand.
You have 2 machines A and B
A is in an internal network behind a NAT, its IP address (as in off the interface) is 192.168.10.1
B is actually on the internet. Is IP address is 72.14.254.104
A wants B to be able to send UDP packets directly

A fires off 2 UDP packets to B. The first packet will be blocked. The 2nd packet opens the NAT.
When the 2nd packet goes thru the NAT the NAT rewrites the From Address. So if origional from addy was 192.168.10.1:3000
The NAT might rewrite it to 69.14.254.104:4531. It will create a "binding" meaning all packets from 192.168.10.1:3000 will be remapped to 69.14.254.104:4531
The binding will stay open for ussually 10 minutes (depends on router, ussually u fire a keep alive packet every minute).

Ok. B recieves Packet. It sees the addy is 69.14.254.104:4531
It now knows the NAT internet address is 69.14.254.104. It now can send UDP packets to 69.14.254.104:4531 and know A will get them.

If both A and B are behind a NAT, similar technique can be used with a 3rd machine which is on the net.
In this case A and B both fire punching packets at C.
C then passes the NAT address of A and B to the respective machines.

I have not worked with this for ages.
When I worked with it back in ~2002 it worked with almost every NAT we came across. Again NAT where not as uniform as they are now.
I suspect it works with all NAT now days, unless admin has actually disabled UDP traffic.

[perkiset]

I know very little of UDP, having spent more time with TCP. So I think from that perspective.

Great stuff. I am so very rarely wrong it's wonderfully refreshing 

[isthisthingon]

HTTPS/SSL proxy through IE, for example, will work as well: http://www.skype.com/intl/en-us/support/user-guides/firewalls/technical/.