TL;DR, yes, it means that if you make a connection outbound, that the service you connected to can respond. They cannot connect to you unsolicited however, unless you set up port forwarding rules to allow them to.
First, you are confusing Asymetric NAT with Stateful Packet Filtering. NAT does not actually firewall anything, it just allows ports to be translated from source to destination. SPF is whats responsible for allowing only solicited responses to traffic.
TCP is a connection orriented protocol, in that both sides of the transmission negotiate and maintain a virtual connection (a flow of packets that are related, such that the order of packets can be maintained even if they arrive out of order, malformed or missing packets are easily noticed so a resend can be requested, and can perform flow control operations to make sure that traffic does not cause too much congestion).
This connection-orrientation allows the firewall to tell whether a given packet is asking for a new connection, or part of an existing and established one.
SPF is generally set up to allow all outgoing connection attempts, and to allow remote servers to whom a connection has been attempted, to reply in-band within that connection (eg the packet comes from the right source on the right port, has SYN/ACK flags set correctly, and has the correct SYN and ACK values) to come through the NAT.
What SPF generally DOESN'T allow, is a remote server initiating a connection to a service inside the NAT wall. so you can request a remote servers resources, and it can send them to you, but the remote server cannot request your resources.
Port forwarding or Destination NAT allows you to set up a service so that outside servers can initiate connections to it to request resources. you only want to do this if absolutely necessary, as it does open up the service to potential attacks.
Note that with PortForwarding, even once you have a port set up to expose your internal service, you must still allow that port through the firewall, as an incoming connection.
As for what you are seeing with Skype and windows firewall, when it says "block all incomming connections" it means that it will not allow a remote server to create an unsolicited connection to your box. it does NOT mean that it will block replies that are part of a connection initiated from your PC however, so Skype can connect to the skype servers, and those servers can respond as part of that connection.
hope that helps.
1ockquote>
This connection-orrientation allows the firewall to tell whether a given packet is asking for a new connection, or part of an existing and established one. -- This applies to UDP too, right? If I send a UDP packet out and get a response the firewall lets it through because it can tell that the UDP is a reply to an outgoing connection?
– Sacha T Red – 2015-06-04T20:39:13.9402yes and no. UDP is a connectionless protocol, so the applications using the flow do not negotiate a virtual connection, and the individual datagrams do not contain any info that the router can use to allow or deny the connection based on directly observable state. instead, the router keeps track of UDP flows from a given station outbound on a port, and allows in traffic coming back from that remote host on that port for a tightly limited period of time. this allows less flexibility in port mapping like no RPC port shifting, but usually works well enough. it does make UDP more dangerous thoufh. – Frank Thomas – 2015-06-05T02:01:14.387
I understand. So if a UDP reply can make it through NAT (the kind of NAT that only accepts replies from the destination port/address), then in theory it should be able to make it through firewall if the reply is fast enough (less than 200ms or something like that) – Sacha T Red – 2015-06-05T04:59:33.293
That is essentially correct. NAT maps flows, so a UDP response is considered by the firewall to be part of the same flow that NAT is tracking, and is allowed because it is presumed to be part of an existing connection. its just not nearly as explicit as TCP is. – Frank Thomas – 2015-06-05T05:59:11.940
So in theory Skype doesn't actually need to configure firewall to create an inbound rule for remote videochat. Do you have any idea why Skype and TeamViewer do it then? – Sacha T Red – 2015-06-05T14:48:43.817
Because they have features that require a remote server to initiate a connection to you. for instance, with Team view, say you are in the UK on business, and need to remote into your home PC. the Home PC doesn't know that you want to connect to it, so it can't initiate the connection to the PC you are using in the UK. the PC you are on needs to be able to tell your home PC that you want to connect, so the connection needs to originate from outside the firewall. Skype internet phone probably needs the same capability. – Frank Thomas – 2015-06-05T15:07:47.410
So if I disable the inbound firewall rules for TeamViewer and then try to remote in using say TeamViewer quicksupport, it shouldn't work? – Sacha T Red – 2015-06-05T15:15:08.280
that is correct. The Teamviewer guys may have gone to some lengths to get around that with techniques like reverse-tunneling, etc, so I can't gaurentee that that will happen, but if it does rely on ports on your system being open for unsolicited remote connections, then yes. – Frank Thomas – 2015-06-05T15:18:31.373
I just disabled all of TeamViewer's inbound rules for firewall, set firewall to "all inbound traffic are blocked" for public and private, and then remote desktop-ed into my desktop from my phone. – Sacha T Red – 2015-06-05T15:38:15.340
Let us continue this discussion in chat.
– Sacha T Red – 2015-06-05T15:55:05.173