Re: Doing MASQ for Asheron's Call

[Ryan Anderson <ryan@michonline.com>]

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