On Saturday 07 December 2002 09:38 am, eugenio wrote: > I need to set packetfiltering on a debian linux firewall to enable a > network game. > Necessary firewall settings are descibed here: > http://support.microsoft.com/default.aspx?scid=KB;en-us;q240429 > > The system has client computers with 192.168.1.1x fix local IP > addresses (no DHCP), and a gateway with both internal (192.168.1.1) > and external (both fixed) IP adresses, w/ two network card of course > (eth0 - external, eth1 - internal). > > Can anyone give me a hint what settings are necessary? I assume that the network is functional as it stands, and that the client machines are SNATted to allow internet access already. If your client computers are only functioning as clients in the game, this should work: iptables -A FORWARD -i eth1 -p tcp \ -m multiport --dport 6073,47624 -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED \ -j ACCEPT If you are allowing it only for specific machines, since you have static local IPs, you can tighten this up as follows: iptables -A FORWARD -s a.b.c.d -p tcp \ -m multiport --dport 6073,47624 -j ACCEPT iptables -A FORWARD -s a.b.c.d -m state \ --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -d a.b.c.d -m state \ --state ESTABLISHED,RELATED -j ACCEPT This will allow the clients to communicate to the gameserver/host initially, then allow established and related connections each way. Just use this trio of rules for each IP that you want to allow. Note that this will allow est/rel for ALL allowed connections, (but only from the specified machines in the second version) so if this is undesireable then you will need to specify each port range explicitly, like: iptables -A FORWARD -i eth1 -p tcp -m multiport --dport 6073,47624 -j ACCEPT iptables -A FORWARD -p tcp --dport 2300:2400 -j ACCEPT iptables -A FORWARD -p udp --dport 2300:2400 -j ACCEPT You can tighten up any of these rules by specifying IP's of allowed local machines, and in some cases you can specify IP's of remote machines, since some of these games only ever connect to one or a small number of IP's that handle all gaming communications. However, the state rules will need to be duplicated for input AND output traffic in this case, since both are required for the port 2300-2400 (or EST/REL) connections. Note also that while EST/REL may seem insecure, it is in fact quite a bit more secure than simply opening up 204 ports permanently. If at all possible, the second approach, or the initial connections as specified there with the single EST/REL from the first, is the best answer. If you get things running this way first, you can log some game traffic and see if there is a consistent remote IP used, and rewrite rules with that if desired, which will be about as tight as you can get it, without manually enabling/disabling all of this on demand when gaming is desired. Also, depending upon how the particular game communicates, you may find it necessary to explicitly open the ports as in the third example, since some games allow or even rely on communication directly between client machines, and this would represent a new connection, not related (state-wise) to the gameserver connection. Finally if a local machine will function as a host (if even possible, depends on the game) then you need to allow the reverse of the initial connection as well, but will also need DNAT to allow internet clients to connect, and only one server will probably be possible. j
