RE: Doing MASQ for Asheron's Call

RE: Doing MASQ for Asheron's Call

[Daniel Chemko]

Warning Hack alert!!!

Ok, here is one way to bend the rules in the most inflexible hard coded
hack that I could think of without recompiling.

Conntrack cannot fix this problem because the AC protocol is broken.
There, I said it. Two machines behind cannot connect to the same server
with the same source and destination ports. That is one reason why
turbine made it worse and allowed you to change the port ranges used to
connect. At that point it became nearly impossible to write a proper
iptables module. 

If you want to write it properly, you need to statefully inspect every
packet that uses UDP. One better would be to have command line arguments
into the kernel module which filters the IP addresses searched for the
one coming from the Microsoft servers. You cannot use port filtering
since the originating port from the client can and must be a
self-defined port number.

1. In order to get multiple AC's to work behind a firewall, you must set
the port ranges on each client machine differently. Machine 1 == 9000
Machine2= 9100, etc.. This can be done in the AC configuration screen if
you run the ac binary directly. The following script doesn't use the
conntrack, so it must be hard coded for every user. It is probably
simpler to do it this way unless you have a lot of dynamically people
playing AC.

I am writing this from memory so there are probably simple errors
within. This is also assuming a basic restrictive firewall is already
configured.

#!/bin/bash

NET_AC=666.666.666.0

CLIENT1_IP=1.1.1.1
CLIENT2_IP=2.2.2.2
CLIENT1_PORTS=9000:9010
CLIENT2_PORTS=9100:9110

iptables -A FORWARD --destination ${NET_AC}/24 -p udp -m mport --dports
${CLIENT1_PORTS},${CLIENT2_PORTS} -j ACCEPT

iptables -t nat -A PREROUTING --source ${NET_AC}/24 -p udp -m mport
--dports ${CLIENT1_PORTS} -j DNAT --to ${CLIENT1_IP}

iptables -t nat -A PREROUTING --source ${NET_AC}/24 -p udp -m mport
--dports ${CLIENT2_PORTS} -j DNAT --to ${CLIENT2_IP}

Re: Doing MASQ for Asheron's Call

[Ryan Anderson]

On Fri, Oct 10, 2003 at 05:19:40PM -0700, Daniel Chemko wrote:
> Warning Hack alert!!!
> 
> Ok, here is one way to bend the rules in the most inflexible hard coded
> hack that I could think of without recompiling.
> 
> Conntrack cannot fix this problem because the AC protocol is broken.
> There, I said it. Two machines behind cannot connect to the same server
> with the same source and destination ports. That is one reason why
> turbine made it worse and allowed you to change the port ranges used to
> connect. At that point it became nearly impossible to write a proper
> iptables module. 

Err, no, that's not really right.

Linux 2.2.x worked fine with multiple machines behind the same "public"
IP - because they were able to masq the UDP port (making it appear as if
it were changed on the client.) *AND* accepted the responses from "new"
servers, with the loose_udp option turned on.

Using port 9000 on all the internal machines will work, so long as the
*external* port is MASQed.  I note that this doesn't appear to happen,
currently, with Linux 2.4; if that would be in the realm of an ip_nat_*
helper, that would make the reverse forwarding that needs to happen,
easier, as well.

> If you want to write it properly, you need to statefully inspect every
> packet that uses UDP. One better would be to have command line arguments
> into the kernel module which filters the IP addresses searched for the
> one coming from the Microsoft servers. You cannot use port filtering
> since the originating port from the client can and must be a
> self-defined port number.

A command line option to specify the IP range of the servers would be
nice (similar, in theory, to how the ip_conntrack_irc module notices IRC
connections.)

> 1. In order to get multiple AC's to work behind a firewall, you must set
> the port ranges on each client machine differently. Machine 1 == 9000
> Machine2= 9100, etc.. This can be done in the AC configuration screen if
> you run the ac binary directly. The following script doesn't use the
> conntrack, so it must be hard coded for every user. It is probably
> simpler to do it this way unless you have a lot of dynamically people
> playing AC.

My real goal is to make DHCP + Ac work, so that I have a system that
"just works" instead of needing to tweak the configuration everytime I
change something minor in my network and forget the myriad of
implications.

> I am writing this from memory so there are probably simple errors
> within. This is also assuming a basic restrictive firewall is already
> configured.

[snipped]

Yes, a manually built port-forwarding solution will work, but it
requires manual configuration of both the firewall and each client -
this seems excessively clumsy to me.  I would like to avoid at least one
of those configurations, if possible.

Judging from a new capture (looking at the traffic on the outbound side
of my firewall), the port is not MASQed at all - so setting a source
port might still be necessary - however, avoiding the manual port
forwarding configuration would still be a great help.

In summary, there *was* a point in time where 8-10 machines would work
perfectly from behind a Linux firewall, without any custom configuration
for clients 2-10 that was not needed for client 1.  (i.e, "echo 1 >
/proc/net/ip_masq_loose_udp") - I'd like to get back to a situation
where "modprobe ip_nat_game_ms_ac ip_conntrack_game_ms_ac" worked
equally well.

-- 

Ryan Anderson
  sometimes Pug Majere

Doing MASQ for Asheron's Call

[Ryan Anderson]

In the 2.2 days, this game (Asheron's Call) would work with
ip_masq_loose_udp turned on. (I think that's the right name.)

In 2.4, this functionality appears to be gone, at least with that name.
From my reading of Netfilter/Conntrack howtos, it would seem that a
NAT/CONNTRACK helper pair would do the job, but a confirmation would be
appreciated.

The game works, for a single machine, with a simple port-forwarding
mechanism - the trick is that making it work for multiple machines
becomes a significant amount of maintenace.

The protocol is fairly simple - the client begins sending from UDP:9000
to UDP:9000 on the server, then to UDP:9001 on the server.

The server replies using the same ports - and eventually hands the
client off to another server, which then uses the same port and replies
back to the client.

i.e (some duplicate lines remove for succinctness.):
08:15:35.019186 c.c.c.c.9000 > s.s.s.47.9000: udp 20
08:15:35.019354 c.c.c.c.9000 > s.s.s.47.9001: udp 20
08:15:35.022703 c.c.c.c.9000 > s.s.s.47.9000: udp 292
08:15:35.150427 s.s.s.47.9000 > c.c.c.c.9000: udp 36
08:15:35.019186 c.c.c.c.9000 > s.s.s.47.9000: udp 20
08:15:35.019354 c.c.c.c.9000 > s.s.s.47.9001: udp 20
08:15:35.022703 c.c.c.c.9000 > s.s.s.47.9000: udp 292

08:15:35.280787 s.s.s.48.9000 > c.c.c.c.9000: udp 122

Note the new server IP.  There has not been a packet from the client to
this IP.

Later on, another wrinkle appears:

08:15:36.309581 s.s.s.48.9001 > c.c.c.c.9000: udp 28

Same (new) server, a new port.

Eventually, more wrinkles:
8:15:46.830392 s.s.s.48.9000 > c.c.c.c.9000: udp 36
08:15:46.884290 s.s.s.56.9004 > c.c.c.c.9000: udp 90
08:15:46.884655 s.s.s.56.9004 > c.c.c.c.9000: udp 28
08:15:47.104630 s.s.s.56.9005 > c.c.c.c.9000: udp 484
08:15:47.104752 s.s.s.56.9005 > c.c.c.c.9000: udp 484

Another new server, 2 new ports.

The only sane thing is that the following rules appear to be true:
	The servers are fairly close to each other, IP-address wise -
	i.e, a blatant assumption of "within the same /24 block" should
	be safe.

	The *client* only ever uses a single port to communicate to the
	servers.

Is this supportable with conntrack?  I took a stab at writing a module 9
months ago, and got lost trying to figure out if I could support the /24
idea sanely.

I can provide a full tcpdump log of the game starting up until fully
functional, if that would help, but I believe I have an accurate summary
of the protocol above.

Thanks in advance to anyone willing to help with this,

-- 

Ryan Anderson
  sometimes Pug Majere