Click to See Complete Forum and Search --> : Iptables Rules & Hosting Multiplayer Games
Floog
11-19-2003, 11:01 AM
Folks,
I'm having problems making a proper NAT rule that will open up the right ports on my linux router and let one of my LAN clients host multiplayer games over the net.
I can join in and play other games on the net, but when I host a game no one can connect to the my hosting machine.
Here's the relevant specs.:
ISP is Comcast Cable.
eth0 goes out to the net
eth1 goes to the LAN
Here's my current ifconfig -a status:
eth0 Link encap:Ethernet HWaddr 00:04:5A:75:B2:52
inet addr:68.63.116.235 Bcast:68.63.117.255 Mask:255.255.254.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8593 errors:0 dropped:0 overruns:0 frame:0
TX packets:945 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1617430 (1.5 Mb) TX bytes:219880 (214.7 Kb)
Interrupt:5 Base address:0x9400
eth1 Link encap:Ethernet HWaddr 00:50:BA:AF:CA:D1
inet addr:199.201.13.1 Bcast:199.201.13.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:159 errors:0 dropped:0 overruns:0 frame:0
TX packets:193 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:21583 (21.0 Kb) TX bytes:209526 (204.6 Kb)
Interrupt:10 Base address:0x7000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100 (100.0 b) TX bytes:100 (100.0 b)
Everything up and running.
Now here's my /etc/rc.d/rc.firewall. At the end of it you will see my best attempts at crafting a rule that will allow connection attempts to my Racing Game to connect through specified ports to the LAN address where the game is being hosted. I thought the "grammar and syntax" of the rule were correct, but I am still not able to get players from the net connected to my host.
IPTABLES=/usr/sbin/iptables
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe
EXTIF="eth0"
INTIF="eth1"
$DEPMOD -a
$MODPROBE ip_tables
$MODPROBE ip_conntrack
$MODPROBE ip_conntrack_ftp
$MODPROBE ip_conntrack_irc
$MODPROBE iptable_nat
$MODPROBE ip_nat_ftp
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
echo " FWD: Allow all connections OUT and only existing and related ones IN"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j LOG
echo " Enabling SNAT (MASQUERADE) functionality on $EXTIF"
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
# Open Ports to Host EA Sports Formula 1 Racing Games over the net
$IPTABLES -t nat -A PREROUTING -i $EXTIF -p TCP --dport 1345 -j DNAT --to 199.201.13.11
$IPTABLES -t nat -A PREROUTING -i $EXTIF -p TCP --dport 3297 -j DNAT --to 199.201.13.11
$IPTABLES -t nat -A PREROUTING -i $EXTIF -p TCP --dport 3298 -j DNAT --to 199.201.13.11
$IPTABLES -t nat -A PREROUTING -i $EXTIF -p TCP --dport 3299 -j DNAT --to 199.201.13.11
$IPTABLES -t nat -A PREROUTING -i $EXTIF -p TCP --dport 3300 -j DNAT --to 199.201.13.11
$IPTABLES -t nat -A PREROUTING -i $EXTIF -p TCP --dport 17677 -j DNAT --to 199.201.13.11
$IPTABLES -t nat -A PREROUTING -i $EXTIF -p TCP --dport 28900 -j DNAT --to 199.201.13.11
$IPTABLES -t nat -A PREROUTING -i $EXTIF -p TCP --dport 30477 -j DNAT --to 199.201.13.11
Please tell me if my rule is stated wrong or if you think I need additional rules to properly route/filter traffic to the LAN host. Thanks for your time and help.
Floog
Floog
11-19-2003, 11:47 AM
Do you think I may need to turn off the "state --state ESTABLISHED,RELATED" rule in order to allow gamers to get to the ports I'm trying to open to LAN game-hosting machine?
Floog
Originally posted by Floog
echo " FWD: Allow all connections OUT and only existing and related ones IN"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j LOG
Floog
11-19-2003, 08:32 PM
Nope, I tried this and it didn't work, still can't get any players on my hosted game.
Originally posted by Floog
Do you think I may need to turn off the "state --state ESTABLISHED,RELATED" rule in order to allow gamers to get to the ports I'm trying to open to LAN game-hosting machine?
Floog
Floog
11-19-2003, 08:48 PM
I tried this rule and it also doesn't appear to work.
$IPTABLES -t nat -A PREROUTING -p TCP -i eth0 -d 199.201.13.11 --dport 0:65000 -j DNAT --to-destination 199.201.13.11
I thought for sure I would strike gold with this one because it's got "0:65000" port designation, so virtually every port in the world is open to pass data to LAN machine 199.201.13.11
Has anyone dealt with this problem before? I'm beginning to think that my cable provider may be blocking me from hosting games, but it's probably just frustration talking.
Please help if you can.
Thanks,
Floog
userland
11-20-2003, 05:40 PM
Have you tried making a rule for the state NEW on the forward chain to be accepted? I see youve only got established, related, while everything else is being droped.
If im not mistaken the prerouting takes place before the forwarding, which makes it still pass through the forward table. plz correct me if im wrong, im not an iptable wiz..
userland
11-20-2003, 05:48 PM
Originally posted by Floog
Do you think I may need to turn off the "state --state ESTABLISHED,RELATED" rule in order to allow gamers to get to the ports I'm trying to open to LAN game-hosting machine?
Floog
No, you still want the extablished, related on so you can receive data from the internet which originated inside your LAN. I think you would need a chain like:
iptables -A FORWARD -m state --state NEW -dport (udp/tcp whatever that game supports) -d (the machine hosting the daemon) (maybe a -i eth0 wouldnt hurt) -j ACCEPT
Im thinking that the DNAT would do part the real forwarding, but you just need to allow it through in the forward table. If you have a problem, drop the "-d (the machine hosting the daemon)" part of the rule. hope this helps.
Floog
11-21-2003, 02:59 AM
Originally posted by userland
I think you would need a chain like:
iptables -A FORWARD -m state --state NEW -dport (udp/tcp whatever that game supports) -d (the machine hosting the daemon) (maybe a -i eth0 wouldnt hurt) -j ACCEPT
Userland, thanks for the helpful guidance. After reading you comments and then re-reading a David Coulsen tutorial I put together the following:
echo " Rule attempting to let NEW packets come in through eth0"
$IPTABLES -A INPUT -m state --state NEW -j ACCEPT
and
$IPTABLES -t nat -A PREROUTING -p tcp --dport 0:65000 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 0:65000 -i eth0 -j DNAT --to-destination 199.201.13.11
It's working. I've hosted a couple of multiplayer games tonight and players were able to see the game and join in. Now I need to ask you for a little further clarification because I'm a little worried about security to my LAN. Is my first rule above allowing all NEW data coming in through the internet on eth0 to go to every computer on the LAN or is the second rule guiding all the incoming traffic to the LAN machine known as 199.201.13.11.
Eventually I'm going to be running apache to host a website and mailserver on the linux routerbox so I need to make sure the INPUT rule is basically nullifying all the NAT security and leaving my LAN wide open to the net.
Thanks again for your assistance. Obviously you're much more comfortable with iptables concepts at this point than I am. I look forward to hearing from you on this next step.
Best regards.
Floog
Floog
11-21-2003, 03:04 AM
errr......sorry about the rush typing.
Meant to say I need to make sure the INPUT rule ISN'T basically nullifying all the NAT . . .
Floog
Originally posted by Floog
<<snip>>
. . . so I need to make sure the INPUT rule is basically nullifying all the NAT security and leaving my LAN wide open to the net.
jumpedintothefire
11-21-2003, 01:45 PM
Meant to say I need to make sure the INPUT rule ISN'T basically nullifying all the NAT . . .
With out stating each port that you want to use, you just opened up your box to all syn packets on every port from everybody.
I'd use a rule like userland, a "--state NEW" rule with each port defined, just like you did for the PREROUTING rules.
You can do a iptables -L -nv and have a look at the chain counter to see if the rule is being used... /var/log/messages should have the logging for what gets dropped by iptables...
Hope it helps....
Floog
11-21-2003, 02:13 PM
Hi Jerry,
I see exactly what you're getting at, and it is what I suspected: my pants are down and the wind is blowing. :-)
Just one quick follow-up on what you are saying about the INPUT rule I have added:
Is it just the one local machine (199.201.13.11) that is now open to all data from all ports, or have I opened up every box on the LAN to all data from the net through all ports 0 - 65000.
I need to get an understanding of how these filter rules are applied to one machine versus two or more.
I'm going to take your advice and specify only the necessary ports. I need to study up on the difference between TCP, UDP, ICMP, --syn, and --ack packets and what each one does, and how to figure out when you need to allow one and not the other, etc.
I'm not so hot at organizing all these different concepts and applying them to NAT and data filtering rules. Are there any good books that you've read regarding this subject matter? Going step by step with a book may be helpful for me.
Thanks for your time and patience, and basic all-around guru-ish-ness.
Floog
Originally posted by jumpedintothefire
With out stating each port that you want to use, you just opened up your box to all syn packets on every port from everybody.
jumpedintothefire
11-21-2003, 03:24 PM
Not to sure which of your additions, --state NEW, or --dport 0:65000 made it work for you. Try # out the --state NEW rule and retest.
This also has your pants are down and the wind is blowing.
The lan is safe but the box is not....
$IPTABLES -P INPUT ACCEPT
With the default policy of accept, I think that any INPUT (think --state NEW) rule would be useless as you have already allowed the traffic.
If #'ing out the --state NEW still allows the game to work, I'll bet that there are other ports not in your orginal dnat rules that are opened when the game runs, the --dport 0:65000 rule covers all ports, so that covers everything, but no filtering..... Think thats is a bad thing....
Floog
11-21-2003, 04:52 PM
I'll test your suggestion tonight at home by trying to host a few games and enabling/disabling one rule, then the other.
I was curious about whether you can combine an iptables rule with a nat rule all in one string like:
$IPTABLES -t nat -A INPUT -j ACCEPT -p ALL --dport 1345:30477 -i eth0 -j DNAT --to-destination 199.201.13.11
What I'm trying to say above is, accept all the incoming data on ports 1345 - 30477 through eth0 and route them to the proper machine at address 199.201.13.11.
Whether this is syntactically a mess, or not, is beyond me. I guess this is the kind of stuff I am trying to learn.
Thanks again for hangin' in with me.
Floog
Floog
11-22-2003, 04:47 AM
When I mess with the iptables INPUT rule in any way, people on the net cannot see or enter the server. So, I guess I have to leave that rule as is, in order to get packets from the net to pass through eth0 and over to the LAN machine hosting the game.
I was able to change the NAT PREROUTING rule to limit the amount of ports that are open to incoming packets from the net. Here's what the newly modified port rules look like:
echo " Open Ports to Host EA Sports Formula 1 Racing Games over the net"
$IPTABLES -t nat -A PREROUTING -p tcp --dport 1345 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p tcp --dport 3297 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p tcp --dport 3298 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p tcp --dport 3299 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p tcp --dport 3300 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p tcp --dport 17677 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p tcp --dport 28900 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p tcp --dport 30477 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 1345 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 3297 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 3298 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 3299 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 3300 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 17677 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 28900 -i eth0 -j DNAT --to-destination 199.201.13.11
$IPTABLES -t nat -A PREROUTING -p udp --dport 30477 -i eth0 -j DNAT --to-destination 199.201.13.11
I guess if I really want to understand iptables, I need to be able to explain why the "m -state --state NEW" comments are necessary to make it possible to get data to the local LAN machine
Floog
Originally posted by jumpedintothefire
Not to sure which of your additions, --state NEW, or --dport 0:65000 made it work for you. Try # out the --state NEW rule and retest.
This also has your pants are down and the wind is blowing.
The lan is safe but the box is not....
$IPTABLES -P INPUT ACCEPT
With the default policy of accept, I think that any INPUT (think --state NEW) rule would be useless as you have already allowed the traffic.
jumpedintothefire
11-22-2003, 10:03 AM
When I mess with the iptables INPUT rule in any way, people on the net cannot see or enter the server.
OK, you can do something like:
$IPTABLES -A INPUT -m state --state NEW -i eth0 -p tcp --dport 1345 -j ACCEPT
repeat as required...
retest, if eveything is still working,
then head over to an online port scanner (grc.com)
and check it out
If you don't like what you see change
$IPTABLES -P INPUT ACCEPT
to
$IPTABLES -P INPUT DROP
and retest from the beginning...
I have, for the most part, stopped hand coding my iptables rules,
I have been using shorewall (http://www.shorewall.net) to configure my iptable requirements for the past while. Shorewall sets up the required rules based on entries in its config files, I'm starting to forget some of the finer points of raw iptables.... :eek: thats bad....
Floog
11-22-2003, 12:49 PM
hey i like that rule. It looks efficient and compact compared to what I've been coming up with. what is my life turning into when I am more interested in coding netfilter rules than other things like good 'ol western capitalist principles of making money and amassing power at all costs. i've gotta go see my doctor about this. :-)
thanks for the pointer to grc.com, this looks like a great tool.
i guess i feel i need to be comptetent with this firewalling stuff because I am now the only guy where i work who manages the network. if we ever got toasted, everybody would have a great time laughing at me as I try feverishly to recover our data, etc.
thanks for your help and support, Mr. Jump.
Floog
Originally posted by jumpedintothefire
OK, you can do something like:
$IPTABLES -A INPUT -m state --state NEW -i eth0 -p tcp --dport 1345 -j ACCEPT
repeat as required...
retest, if eveything is still working,
then head over to an online port scanner (grc.com)
and check it out
If you don't like what you see change
$IPTABLES -P INPUT ACCEPT
to
$IPTABLES -P INPUT DROP
and retest from the beginning...
I have, for the most part, stopped hand coding my iptables rules,
I have been using shorewall (http://www.shorewall.net) to configure my iptable requirements for the past while. Shorewall sets up the required rules based on entries in its config files, I'm starting to forget some of the finer points of raw iptables.... :eek: thats bad....
jumpedintothefire
11-22-2003, 02:05 PM
what is my life turning into when I am more interested in coding netfilter rules than other things like good 'ol western capitalist principles of making money and amassing power at all costs.
More like the persuit of happiness for me, but money is good too.... :D
That rule need to be repeated for each PREROUTING rule you have, changing the port. it does not replace prerouting.....
I guess if I really want to understand iptables, I need to be able to explain why the "m -state --state NEW" comments are necessary to make it possible to get data to the local LAN machine
You need to learn the 3 way handshake of tcp, "--state NEW" filters the "syn" packets used to start a tcp connection.