Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Joel Newkirk <netfilter@newkirk.us>
To: Mark Ryan <markryan@cfl.rr.com>, netfilter@lists.netfilter.org
Subject: Re: Help with game server
Date: Sun, 22 Dec 2002 03:20:12 -0500	[thread overview]
Message-ID: <200212220320.12931.netfilter@newkirk.us> (raw)
In-Reply-To: <000001c2a95e$b93651c0$0501a8c0@underworld>

On Saturday 21 December 2002 09:06 pm, Mark Ryan wrote:
> I have a linux firewall/router with iptables firewall script.  I am
> trying to run a Medal of Honor game server so that me and a friend can
> play.
>
> I only want him to be able to connect...however I can't seem to get
> the rules right.  It seems that Medal of Honor is using port 12203.  I
> have the following rules but they don't work:
>
> These to allow the connection:
> $IPTABLES -A INPUT -p udp -i $EXT_IF -s 68.99.10.xx -d 67.8.168.xx
> --dport 12203 -j ACCEPT
> $IPTABLES -A INPUT -p tcp -i $EXT_IF -s 68.99.10.xx -d 67.8.168.xx
> --dport 12203 -j ACCEPT
>
> These to forward to internal machine:
> $IPTABLES -t nat -A PREROUTING -p tcp --dport 12203 -i eth1 -s
> 68.99.10.xx -j DNAT --to 192.168.1.5:12203
> $IPTABLES -t nat -A PREROUTING -p udp --dport 12203 -i eth1 -s
> 68.99.10.xx -j DNAT --to 192.168.1.5:12203
>
> Am I doing something wrong?

If the connection won't work, then the answer is obviously "yes"... :^)

You have rules in INPUT for this.  If the connection is coming in at 
67.8.168.xx and being DNATted in PREROUTING to a local machine, then the 
INPUT chain will never see this traffic.  You seem to be constructing 
things based on ipchains' handling - with iptables/netfilter PREROUTING 
(mangle table prerouting chain, then nat table prerouting chain, 
specifically) is the first to see a given packet, then a routing 
decision is made, and the packet goes to either INPUT or FORWARD. 
(either the firewall box itself or forwarding to another machine.)

[IMPORTANT]
Medal of Honor uses the Quake3 engine, so it will probably require the 
Quake NAT helper in patch-o-matic, since the Q3 engine does things like 
embedding IP addresses in the data itself, not just the header. (NAT 
normally only affects packet headers)  This will require you to download 
P-O-M, patch your kernel sources, and recompile your kernel and 
iptables.  The only other solution is to have the server sit directly on 
the public IP, IE the server and the firewall machine the same.

That said, the correct rules for DNATting would probably be:

$IPTABLES -t nat -A PREROUTING -p tcp --dport 12203 -i eth1 -j DNAT --to 
192.168.1.5
$IPTABLES -t nat -A PREROUTING -p udp --dport 12203 -i eth1 -j DNAT --to 
192.168.1.5
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -p tcp --dport 12203 -j ACCEPT
$IPTABLES -A FORWARD -p udp --dport 12203 -j ACCEPT

These five rules are likely all you'll need.  (well, along with the Q3 
issue addressed above) Actually, you only need specific PREROUTING and 
FORWARD rules for whatever the initial connection will be, then EST/REL 
will handle everything else.  I don't know what protocol the initial 
connection uses for MoH though.  (you can try it this way, and if it 
works then "iptables -L -v -n" will show you which rule, udp or tcp, 
caught the initial connections)  

You can specify your friend's IP in the FORWARD rules above if you want 
(and if his IP is static) with the "-s 68.99.10.xx", but specifying 
destination IP is redundant, since the packet is already HERE, and 
specifying the destination port for the DNAT target is unnecessary, 
since it will by default use the same port as the packet started with, 
and change only the destIP.  Also, if you test destIP in FORWARD rules, 
be aware that the DNAT has already changed the destIP, so it will now be 
192.168.1.5, NOT 67.8.168.x...

If you set things up where the game server is the firewall, directly 
addressable at the public IP, then all you would need would be:

$IPTABLES -A INPUT -p tcp --dport 12203 -i eth1 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 12203 -i eth1 -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT

and if you have DROP policy for output then
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
should allow the server to continue to communicate once an outside 
machine makes the initial contact.

Obviously this assumes that you are running the Linux version of Medal of 
Honor for the server...

> Mark

j



      reply	other threads:[~2002-12-22  8:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-22  2:06 Help with game server Mark Ryan
2002-12-22  8:20 ` Joel Newkirk [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200212220320.12931.netfilter@newkirk.us \
    --to=netfilter@newkirk.us \
    --cc=markryan@cfl.rr.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox