iptables NAT server configuration

2 replies [Last post]
22. September 2005 - 1:21
TC HEADTRIP
Offline
Joined: Sep 2005
Posts:

Yes the in game browser issue. After many hours of searching and searching for a solution, Nobody seemed to have one. So I had to just fuigure it out the hard way.. I am running a linksys WRT54G (wireless broadband router) it's really just an embedded linux box running on a broadcom chip. after watching "tcpdump -i eth0 udp" on my server until my eyes were ready to bleed. all I could see were outbound UDP packets on port 27971 (my chosen port) but never a response. so I added a man-in-the-middle box between my router and modem, same capture chowed the router was MASQUERADING the udp packets on another port (don't remember which, and it doesn't really matter) and then the master browsers were responding on that arbitrary port. Thank gods there is an exploit in the ping function of the router that allows a little script written by Jim Buzbee (jbuzbee@nyx.net) http://funke.lo-res.org/linksys/batbox/wrt54g-0.41/ to stick a copy of busybox on the thing and give you a shell. after getting the shell a quick "iptables -t nat -L" showed the problem instantly.

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE udp -- anywhere anywhere udp spts:5060:5070 masq ports: 5056-5071
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- 192.168.1.0/24 192.168.1.0/24

note that the only way a udp packet on 27971 would get out is on the 2nd rule. a MASQUERADE from ANYWHERE to ANYWHERE, now iptables MASQUERADE's default action is to rewrite the packet to it's next available port (I won't even get started about the bird brains that wrote the udp MASQ engine, that blatantly ignored the fact the UDP is defined to operate this way when a source port is defined. RFC 768 http://www.faqs.org/rfcs/rfc768.html ) so as a solution we just need to INSERT one rule.

iptables -t nat -I POSTROUTING -p udp -m udp --source-port 27971 -j MASQUERADE --to-ports 27971

now the POSTROUTING chain is such

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE udp -- anywhere anywhere udp spt:27971 masq ports: 27971
MASQUERADE udp -- anywhere anywhere udp spts:5060:5070 masq ports: 5056-5071
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- 192.168.1.0/24 192.168.1.0/24

this will force iptables to keep the source port for udp packets on 27971. the server is up and staying on the list because it can actually get a RESPONSE on the correct port!

I hope this comes as some use to somebody, I know I was beating my head into a wall trying to resolve it.

-HeadTrip

Top
22. September 2005 - 17:48
#1
.ALIAS.
Offline
Joined: Sep 2005
Posts:
iptables NAT server configuration

so if i use the port 27971, my server will always show up fast no matter how long its been on?

Top
22. September 2005 - 18:26
#2
TC HEADTRIP
Offline
Joined: Sep 2005
Posts:
iptables NAT server configuration

No this has nothing to do with what port you use. This is a resolution to the fact the a MASQUERADED outbound udp packet going through an iptables gateway configured with a default MASQ rule like

iptables -t nat -A -s <your local network> -d 0.0.0.0/0 -j MASQUERADE

will by default rewrite the source port of the packet

This is a problem because the master browser looks at the source port of the packet to send a CLIENT_INFO to. (IE: the source port of the Heartbeat packet should be the port your server is running on) when this gets rewritten to some abitrary port (ie: 31000) the server tries to send the CLIENT_INFO packet back to that abitrary port (ie: 31000) , given that the server is listning on another port (27971 in my case) it will never see the CLIENT_INFO and therefore never respond to it.. you will drop faster but the port you run your server on dosn't matter as long as your NAT firewall is not rewriting your udp packets to another source port.

I believe there are other factors involved as well (such as ping) as to your placement on the list.

Top