Server does not show up in master list

[css]

What kind of port forwardings do you have on your Modem?

Dump all UDP data on your Linux box to/from eth1 and eth0. All Source game packets are UDP. Then you can know for sure which route the packets are going. I'm 99% sure that the TF2 client doesn't send five stupid random packets to random ports (I leave 1% chance for Valve doing something weird in the latest updates).

My guess is that NAT goes wrong somewhere and that's why the ports seem weird. The "random" ports might be originally source ports where somebody sent some query and is now expecting to get response in the same port.

[SerajewelKS]

css Wrote:What kind of port forwardings do you have on your Modem?

The ones listed in the first post. (There are a few others that I do not wish to disclose, but they are all TCP rules and additionally are not in the range of ports we are discussing.)

css Wrote:Dump all UDP data on your Linux box to/from eth1 and eth0.

That's a great way to break DNS. I could just dump everything from 49152:65535 to 192.168.8.10 but as I said that will have exactly the same effect as processing them at the modem since the server is not listening on those ports.

css Wrote:I'm 99% sure that the TF2 client doesn't send five stupid random packets to random ports (I leave 1% chance for Valve doing something weird in the latest updates).

You're welcome to contradict me with your sniffing logs. No offense, but I know what I'm seeing over here.

css Wrote:My guess is that NAT goes wrong somewhere and that's why the ports seem weird. The "random" ports might be originally source ports where somebody sent some query and is now expecting to get response in the same port.

No, I am sniffing on eth1 when I refresh with my client. Aside from the fact that eth1 is on the same side of the NAT rule as the client, destination ports are only modified when a packet enters a NAT network. Only source ports/addresses are modified when leaving and the source information is not odd here, only the destination.

[css]

Do "tcpdump -ni eth0 'udp and port not 53'" and "tcpdump -ni eth1 'udp and port not 53'". It won't break anything - and given the situation it doesn't matter if DNS doesn't work for a while.

The most likely reason why you don't have working TF2 server behind a NAT - even though hundreds other server admins do - is that you have two devices doing NAT in your network. Do you see other server admins saying here they don't get their server online because TF2 uses some random ports for querying the server?

What happens when the Linux box gets the packet back from the Modem when it does "hairpin"? Does the Linux box get confused there?

Here's how it goes without NAT:

Code:

tcpdump -i eth0 -n 'host 74.55.237.131'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:28:53.369892 IP 111.222.333.444.39716 > 74.55.237.131.27015: UDP, length 25
10:28:53.516268 IP 74.55.237.131.27015 > 111.222.333.444.39716: UDP, length 106

I did "qstat -a2s 74.55.237.131:27015" to get that network traffic. My computer is the 111.222.333.444.

Note that the reply packet from 74.55.237.131:27015 is going to >~40000 port. Your NAT probably messes this up somehow, or you are reading the data in the wrong place and assume that it should have some other destination address.

Let me say once more that I've had the same setup as you have, but I had the Linux box bridging connections from the Modem. Even in that kind of setup I had to be careful which iptables rule (INPUT or FORWARD) I'm using, or which network interface (eth0, eth1, br0) I'm sniffing.

You've got double-NAT (modem + linux), which is the most likely cause for all network problems. Because of the double-NAT you probably should have double port forwardings in modem and Linux. You've only told what you have on your Linux, but how's the modem configured? What does the modem do when it sees new packet coming to port 27015? What does the modem do when it sees new packet coming to port 27015?

[SerajewelKS]

I finally figured it out. The issue was actually quite simple, though it took me a while to figure out what it was.

You were correct that NAT was involved, though not at any of the points we were looking at. When packets left the router box for the Internet everything looked good. But the modem was mapping the source port, and apparently the master server ping doesn't include the port to connect on -- the server assumes the port that it sees the ping coming from. In other words after a few minutes there were about five or so "servers" registered from my server cause each ping was coming from a new source port. So it was not double-NAT being the problem per se (theoretically you can layer NAT as many times as you want and things should still work) but the behavior of the modem's NAT mechanism.

It was easily fixed by changing the modem settings to give the "LAN device" (my router box in this case) the external IP address. So the modem just doesn't do NAT at all anymore.

Well that part was easy. Configuring the router to do hairpin NAT was another deal entirely but the end result after my tweaking is that other people can see my server. And so can I (yes, on the Internet tab). Since I have a dynamic IP the hack required to do hairpin NAT is pretty ugly, but apparently it works.

I managed to get three other people playing on my server before my ISP decided that it would be a good time to go down for 15 minutes. Damn AT&T...

Thanks for your suggestions and your patience.


As a side note, I heard an awful lot on these forums about modems that "just can't host srcds." I wonder if the problem is source port mapping? I wonder if someone (maybe me) could put together a howto on checking for this condition and fixing it?