Re: Converting ipf & ipnat.rules to pf.conf & nat.conf

["David Hodnett" <dwar@earthlink.net>]

> The rule set seems to let most things work correctly.  But not the one game
> I am playing :)  Asheron's Call.  The ports it uses are:
> 
> Initial UDP Outbound  9000
> Subsequent UDP Outbound  9004, 9008, 9012
> Subsequent UDP Inbound  9000, 9001, 9004, 9005, 9008, 9009, 9012, 9013
> 
I have this problem too, and it also appears in the mail archives as 
an unsolved problem.

Assume for the sake of argument that you have just one Windows 
box connected to an OpenBSD box, which in turn is connected to 
the Internet, applying the usual PF and NAT rules.

The Windows box sends from it's port 9000 to Microsoft's server 
port 9000.  Nat changes the headers on the packet so that 
Microsoft thinks it's coming from OpenBSD port 45378 (for 
example).

What Microsoft then does is send a packet from port 9004 to the 
NAT's port 45378, i.e., what Microsoft thinks is the Windows' port 
9000.

What is supposed to happen is the Windows box gets a reply on 
port 9000, finishes initializing the game, and lets you play.

What's really happening is that NAT considers the 9004 to 9000 
nee 45378 packet to be a new state and doesn't know what to do 
with it, so it drops it - and the game never finishes initalizing.

You can observe what's going on using tcpdump and pfctl -ss.

The only solution I've seen so far (and this is Microsoft's official 
solution) is to use portmapping, i.e., assign permanent one to one 
relationships between certain ports on the OpenBSD box and a 
specific combination of LAN address and port.  In other words, any 
packet sent to port 45378 should be forwarded to Windows-
machine port 9000 - regardless of what kind of packet it is.  This 
was possible under OpenBSD 2.9 and prior versions but not under 
3.0 and newer versions.

As far as I can determine, based on the man pages, the new NAT 
program introduced with 3.0 doesn't allow portmapping.  My 
assumption is that the designers intended for people do something 
like the current RDR and ftp-proxy setup, and there just aint no 
AsheronsCall-proxy yet.

However, I would LOVE to be wrong.  If someone else has a 
solution, please let us both know.  Does 3.1 have an upgraded NAT 
that would solve this problem?

David
dwar@earthlink.net

P.S. As much as I love the game, I don't use OpenBSD often 
enough to justify the time spent coding, testing, and security-
auditing an AsheronsCall proxy.  I simply switch the DSL cable 
when I want to play.  If there is enough demand for it, I'm willing to 
take a try at it, but we're talking like 20+ people must want it first.