This is actually a question out of curiosity, I was just wondering why LFS' TCP and UDP packets reach my machine when supposedly the router firewall should be blocking non default ports for incoming packets.

I've analysed the TCP and UDP traffic generated when a connect and disconnect to a LFS server and the TCP and UDP ports used seem to be chosen randomly.

My modem/router is in a multiport configuration and it links my home LAN to the Internet, so I have to use port forwarding if I want any non default port to be available for my private LAN IP.

So my question is: How do LFS packets sent by servers reach my machine? I guess it has something to do with NAT. Maybe LFS servers are sending packets to ports that are usually open by deafult, and my router changes them while performing NAT and that is why they appear as "random" to me.

I hope this is clear and someone can give me the answer

In a very basic nutshell when you start playing or listing servers your client connects out, which gets noted in the NAT database. Any further communication is then allowed back in which corresponds to this database. This is standard NAT behaviour. Since the server doesn't initiate any inbound connection first any inbound firewall isn't likely to affect this.

In short because your PC is connecting out first, the inbound firewall is irrelevant (in this instance - in others, more sophisticated firewall solutions can differ).

The "random port choosing" is also a design feature in IP communication. Whenever you connect to something you will get a known IP and port to connect to. This is why there are standard port numbers for certain services - such as DNS, HTTP, HTTP over SSL, SMTP, etc. - one end needs to initiate the connection first. However, the other end obviously needs a way of communicating back. A random, unused, port (larger than 1024) is chosen by your client and your IP and that port number is used by the other end to talk back to you.

You might benefit from learning a little more about general networking if you're interested in what's going on under the hood.

Quote from the_angry_angel :

In a very basic nutshell when you start playing or listing servers your client connects out, which gets noted in the NAT database. Any further communication is then allowed back in which corresponds to this database. This is standard NAT behaviour. Since the server doesn't initiate any inbound connection first any inbound firewall isn't likely to affect this.

In short because your PC is connecting out first, the inbound firewall is irrelevant (in this instance - in others, more sophisticated firewall solutions can differ).

The "random port choosing" is also a design feature in IP communication. Whenever you connect to something you will get a known IP and port to connect to. This is why there are standard port numbers for certain services - such as DNS, HTTP, HTTP over SSL, SMTP, etc. - one end needs to initiate the connection first. However, the other end obviously needs a way of communicating back. A random, unused, port (larger than 1024) is chosen by your client and your IP and that port number is used by the other end to talk back to you.

You might benefit from learning a little more about general networking if you're interested in what's going on under the hood.

I'd love to have time to learn these things in depth.

Thanks for the quick answer. I have a question though. I'm alright with everything you explained, but... I'm a bit confused about the UDP part. Since TCP is a connection oriented protocol there's a conversation between the client and the server, and so that conversation has a beginning and an end. But UDP is not connection oriented and it's just like throwing packets to an IP/port hoping they will arrive. So, even if I'm the one that first sends an out-going UDP packet, how does the NAT mechanism know when all the UDP sending/receiving "has finished" so it won't allow further incoming UDP packets from that temporarily accepted IP/port?

I know this is completely unrelated to LFS in any way now, but I'd really appreciate it if you could answer

when i look at the 'conntrack' mechanism on my router, I see it remembers udp packets with some default time to live. 30 seconds for new 'connections' (a packet has been sent) and 150 seconds for assured connections (a packet has been received too). And every time the router receives an udp packet that it knows about, the timer gets reset to 150 seconds.
And if there are no more packets received within that timeout, it will drop any knowledge of that udp 'connection'.

that was just concluded from what i saw on my router - could be slightly different officially, but it's the idea anyway

As Victor says, that's pretty much the general gist of how most NAT implementations handle UDP TCP connections will also have a timeout, although they're much shorter.

Great, thanks a lot to both of you guys. I was guessing it would be some kind of IP/port memory with a timer as you just confirmed