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 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.
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.
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.
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.
client:cport -> server:port
– must get through on both ends
client:cport <- server:port
(telling sport
) – this gets through any normal firewall or NAT, as a reply
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
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
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.
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.
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.
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.
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.