Outgun / Documentation / Firewall setup

Firewall setup

This document describes the ways in which Outgun uses the network. This information is mainly intended to help you set up your firewall to work with Outgun. Since Outgun 1.0, most home firewalls and NATs work with no adjustments, provided you aren’t running a server. Stricter firewalls that restrict outgoing traffic will need more care.

This document applies to Outgun 1.0. Previous versions behaved differently, and had no options to control anything else but the server primary port.

Contents

Overview

This is an overview about how to set up your firewall or NAT, if it doesn’t limit outbound traffic. If it does, please read the more detailed sections below.

Client

Running a client usually works without any special firewall settings when outbound traffic isn’t limited. If you are having problems, and your firewall allows this, you could try allowing all incoming traffic (it is enough to allow only traffic from the Outgun servers you are going to play on, but don’t put a limit on the remote port) to one or a few UDP ports, which you then specify Outgun to use with the -cport argument. If you have a NAT, you will probably also need to set up these ports so that they always point to the same ports on the computer you use to play Outgun. If this doesn’t help, you’ll have to find another way to relax your firewall or NAT.

Server

Running a server is more complicated. You will need to open the primary server port for all incoming UDP traffic, and if you have a NAT, configure it to forward all traffic to that port to the same port on the Outgun server machine. On an application level software firewall, it is usually enough to give Outgun server rights, but at least some versions of Zone Alarm don’t like the way Outgun opens connections and won’t work unless you set the internet zone security level to medium.

If the server is behind a NAT, and you don’t want to shut out all clients who also have a NAT or a firewall, you should set up a range of secondary ports for use with the -sport argument, and make your NAT forward each of those ports to the corresponding port on your Outgun server machine.

Preparing for problematic client firewalls

An additional problem affects clients with certain types of NAT or firewall, regardless of whether the server is behind a NAT. When the client sends a probe to the server secondary port to open its own firewall, a server firewall may send a reply about the port not being in use, which results in the client firewall dropping packets sent by the server from the same port shortly afterwards. This is especially likely if the server is running Linux, where openly rejecting connection attempts instead of just dropping them is more common than with Windows firewalls. You can combat this case by adding a firewall rule to drop new connections to the server’s sport range (or indeed all ports with no open services running on them, but some software may suffer slightly).

With Linux and iptables with a typical configuration, you can silently drop the necessary packets by running as root (in one line):

iptables -I <input-handling-chain> <rulenumber-of-REJECT> -p udp -m udp --dport <first-sport>:<last-sport> -j DROP

with the angle-bracketed parts replaced with relevant values. For example in many (if not all) versions of Fedora Core, you can look at the output of “iptables -L” and the chain RH-1-Firewall-INPUT to which all input is redirected. Say there are 12 rules in it, and the last one is “REJECT all -- anywhere anywhere”. Using the sport range 40000:40100, the relevant command would be:

iptables -I RH-1-Firewall-INPUT 12 -p udp -m udp --dport 40000:40100 -j DROP

If this works, the settings can then be saved with the command “service iptables save”. Of course if you are serious about security, you must understand all that’s said and all of your iptables configuration before you attempt the change, although if you end up dropping packets that you shouldn’t, it should only result in denial of service.

Game traffic (UDP between client and server)

When connecting to a server, the client knows the server primary port (set by -port on the server). It chooses a local port from its -cport range, and starts sending UDP packets to the server’s address and port.

When the server gets the connection attempt, it chooses a port from its -sport range for sending data to this client. The server however first replies from its primary port telling the client which other port it chose. The client opens its own firewall or NAT by sending a packet to that port first, so there are no problems if the server is not also behind a NAT.

Once the connection is established, the client continues to send data to the server’s primary port from its chosen cport, and the server sends data from its chosen sport to the same client cport.

A variation to this is that if just after connecting the server receives client packets, but sees that its own packets aren’t going through, it increases the client side port that it sends to by one every three seconds, five times. This helps if a client NAT assigns a nearby external port (instead of the same) to the cport -> sport probe. In this case, connecting to a server can take considerable time with the connection half-way established and the game showing, but after that delay everything works normally. This server behavior was added to Outgun 1.0.1, and therefore doesn’t happen with servers running 1.0.0.

  1. client:cport -> server:port – must get through on both ends
  2. client:cport <- server:port (telling sport) – this gets through any normal firewall or NAT, as a reply
  3. client:cport -> server:sport – this doesn’t need to get through anything, but it is normally required on the client side in order to allow the reverse packets through
  4. client:cport <- server:sport ... – provided the previous reverse packet managed to clear the way, these get through as replies on the client end, but server side needs to explicitly let them through
  5. client:cport -> server:port ... – just like the first packet

This protocol doesn’t cleanly match anything generally used in UDP applications, because the server sends and receives data through different ports with the same client. This might cause some problems, if the one way traffic doesn’t keep a firewall’s or NAT’s “channel” open. This has always been the way Outgun works, but it will be changed to normal in a future version, removing the need for the -sport switch and forwarding more than one port through a server side NAT.

Master server traffic

The master server traffic takes three forms: communications with the server list master server, the tournament master server, and the bug reporting master server. These are all different servers. The first two use TCP, while bug reporting uses UDP. If your outbound traffic is not controlled by your firewall, all this traffic gets through without problems.

Server list master server

The server list master server is koti.mbnet.fi, TCP port 80 (HTTP). Outgun makes actual HTTP requests, but doesn’t use any proxy regardless of how your system is configured. At the time of writing (Jan 2005), the server’s IP address has long been 194.100.161.5. Outgun servers need access to it in order to be on the server list, and clients to get the list of servers online.

Tournament master server

The tournament master server is www.mycgiserver.com, TCP port 80 (HTTP). Outgun makes actual HTTP requests, but doesn’t use any proxy regardless of how your system is configured. At the time of writing (Jan 2005), the server’s IP address is 64.69.35.205, but it uses to change. Outgun servers need access to it in order to allow players log in to the tournament, and clients to log in themselves.

Bug reporting master server

The bug reporting master server is currently Nix’s home computer, 130.233.18.23, UDP port 24900. The client and server only use this server to send reports about assertions, in case the automatic bug reporting is enabled. Lacking access to the server doesn’t do any direct harm to you.


Updated 2007-02-27 – Niko Ritari