RE: [PATCH] Quake III Arena conntracker

[Sneppe Filip]

Title: RE: [PATCH] Quake III Arena conntracker

Harald Welte wrote:
>
>I see. So now you can open only *.*.*.*:* -> master_server:27950
>and all other stuff will be RELATED.
>

Exactly.

>> One more thing: since all traffic is originated by the client,
>> I did not write a NAT module, since imho the normal NAT
>> framework is able to cope with this protocol.
>
>mh. well, I'm not so convinced about this.  What happens when you use
>NAT to an address range and your individual udp streams get NAT'ed to
>different IP addresses?
>
>btw: what about other cases like a netfilter firewall in front of a
>server (maybe even DNAT to a server in DMZ with private IP address ?)
>

On second thoughts, I think you're right on the NAT issue, and the
protocol helper requires a nat helper :-)
Just some comments...

I can imagine the following scenario: a firewall is doing some
type of SNAT on the UDP stream to the Internet/the master server.
I now understand that the same type of SNAT should be applied to
related connections going to the individual game servers (I didn't
think of this because I have a generic MASQUERADE rule in my
home setup which hides this problem anyway by doing SNAT on *all*
packets going to the internet).

However, I can't think of a scenario where the nat tracker would need
support for DNAT. Let's say you DNAT the UDP stream to the master
server to some internal/DMZ machine: the responses (ip addresses and
udp ports of game servers) will have no relation with the master
server: they will be random IP addresses from all over the Internet
that the Quake client must connect to, so one cannot make any
educated guesses on how to NAT those. Isn't this entirely different
from, say, ftp where the expected connection involves the original
server's IP address.

Maybe I am still missing something. Anyway, I will start coding the
nat helper this weekend and resubmit when it's ready.

Regards,
Filip