Reload this page using its associated frames

Clarifying the basics

When internet protocol (IP) addresses became a valuable resource over the past years of the Internet boom different approaches have been taken to stretch the available address range. For instance most Internet Service Providers (ISP) assign IP addresses from a pool rather than giving each of their customers a static IP that would never change.
While dynamic IP address assignment is no problem at all when playing TA the other approach to overcome the limited range of IP addresses causes some trouble. The idea was to create private networks that may reuse the same IP address range other private networks use too but to separate those private networks from the Internet so the overlapping address ranges wouldn't interfere.
In order to allow computers from within the private networks to access the public Internet additional measures had to be taken: it's clear the computers couldn't use their private IP addresses because those are only guaranteeed to be unique within the private networks. That's where Network Address Translation (NAT) comes in. The NAT solution which may exist as hardware implementation (router, cable modem, DSL modem etc.) or as software implementation (f. ex. Microsoft's Internet Connection Sharing ICS) is the point each network packet going from the private network to the Internet or vice versa has to pass. For this purpose the NAT solution is integrated in both networks by using (at least) two different IP addresses. The first address is a Internet wide unique outer IP address assigned by the ISP. The second IP address is taken from the address range used in the private network. Although this inner IP address is unique within the private network (often denoted as Local Area Network LAN) it's non unique within the Internet since other private networks world wide use them as well. As you can see the NAT device has two 'sides': one communicating with the Internet and one with the private network.

For the sake of simplicity the following explanations assume that the terms router and NAT are exchangable.

NAT and connections initiated from the private network

This is the usual scenario for contacting a so called server application on the Internet. On the local computer a client application performs an active open to the server which plain means the connection process is initiated by this program. A typical example for client applications are web browsers, the according counterpart on the server side was for example the Apache web server or Microsoft's Internet Information Server. It's important to understand the difference between clients and servers because this will have an impact on NAT too (as you will see later).
Without going too much into details lets take a look what happens when a connection to an Internet computer is actively opened from within the private network. Suppose the private network is using addresses in the range 192.168.1.0 - 192.168.1.255. The outer NAT IP assigned by the ISP was 217.180.180.5, the inner IP of the NAT by which it's integrated into the private network was 192.168.1.1 and the sending computer in the private network had the IP 192.168.1.45 assigned.
As soon the network interface of the sending computer concludes that the destination IP in the packet containing the connection request is not within the range of the IPs associated with the local network it will forward the packet to a so called gateway which is supposed to have information about how to reach IPs outside of the LAN IP address range. In simple LANs (and I talk only about home networks here) the gateway is identical with the NAT entity. So, in our example the local computer just forwards the connection request packet to the NAT entity's LAN interface at IP 192.168.1.1. Once it has arrived there the NAT solution will modify the packet's IP header (which carries the destination and source address information) by replacing its (at Internet scale) non unique source IP 192.168.1.45 with the NAT solution's outer (Internet) IP address, in our example 217.80.180.5. Usually the source port data in the header is also changed and then the original source IP and original and new source port information are put on internal lists maintained within the NAT entity. These book keeping is required in order to allow the NAT entity to associate the initiatior of a particular (outgoing) connection request with response packets from the targeted Internet computer later on. But principle the exchange of the LAN source IP by the NAT's ISP assigned Internet IP address is the actual translation process.
Once the translation is done the NAT solution puts the connection request packet on the Internet where it finds its way to the destination computer by travelling from router to router until it reaches the destination computer. The receiving computer replies to the incomming connection request by sending a response packet to the source IP address it reads from the IP header of the connection request packet which it has just received. Since the NAT entity has replaced the original (LAN) source IP 192.168.1.45 with its own Internet IP 217.80.180.5 before the conncetion request packet was put on the Internet this is exactly the address the response packet gets directed to. As soon as the response packet arrives at the NAT entity's Internet interface it'll look up its internal list in order to figure out which computer in the LAN is associated with the packet that triggered the response. It then replaces the destination IP address which still points to the NAT entity's Internet interface IP 217.80.180.5 with the LAN IP of the computer which initiated the outgoing connection, which was IP 192.168.1.45 in our example. Then it injects the modified packet via its LAN interface into the LAN. From there the response packet will finally find its way to the computer which had originally initated the connection to the Internet computer, the circle is closed.
Now, what could go wrong if NAT entities wouldn't translate possibly ambiguous LAN IP addresses to unique Internet IP addresses? To answer this question imagine the following situation: Two computers located in two different private networks are using the same non unique IP 192.168.1.45 and are sending connection request packets to computers on the Internet at the same time. Once the destination computers are replying with their response packets directed to the source IP they found in the connection request packet the Internet is spoiled with packets directed to an IP address which does actually represent two different receivers. Or imagine the two LAN computers are trying to open a connection to the same Internet computer at the same time: One of the senders would lose and never receive a response packet since as soon it hits a router which knows a route to the destination IP address it will go there. There is no way to tell this router something like 'the first packet with this destination IP address has to go this way, the second you do just forward elsewhere' (so it had a second chance to be delivered to the other computer by hitting a router that would know the other computer under the same ambiguous IP address).
At this point I should mention that there are mechanims in place to avoid such ambiguouties from start by defining special IP address ranges that are supposed to be used for private networks that are actually connected to the Internet by NAT entities: network packets with destination addresses in the range 192.168.x.x respectively 10.x.x.x are generally dropped by Internet routers which is exactly the reason why they are supposed to be picked for running NATted LANs. Even if something goes terrible wrong and a LAN IP spoiled packet makes it into the Internet it won't be able to cause much confusion since any reply packet directed to its sender's source IP address is immmediatly filtered out by the first router encountering such a packet.

NAT and connections initiated from the Internet

As we learned above the NAT solution can gather all required information to associate the computer's private IP with the respones packets for active opens on the fly. Now, things get a bit ugly when the role of client and server is exchanged. Imagine you run a web server like Apache in the private network. Since this is a server program it won't perform active opens but just wait for connection requests from clients. It does this by listening on a well known network port, for web servers usually port number 80 (think of network port numbers as house numbers while IP addresses are the street names - the combination of both identifies a location in the IP world). The problem is, how can a web browser on the Internet reach this web server? As we already know by now you cant just tell the web browser to contact IP 192.168.1.45 at port 80 where the server is listening since the whole private network is hidden behind the NAT's outer IP 217.80.180.5.
The first idea you probably have is to tell the web browser to connect the NAT's outer unique IP address. Now, with the attempt to contact 217.80.180.5 at port 80 you would get the packet containing the active open request of the web browser to the NAT's outer interface. But what then? The NAT solution is not able to handle web browser requests the only option it has is to discard the packet. Now, to get the packet over the gap from the NAT's outer IP interface to the waiting web server application running on IP 192.168.1.45 the NAT solution needs additional information which can't be gathered on the fly. You have to explicitly tell it which computer in the private network is running a server application that can take care of active open requests comming from the Internet which are directed to a certain network port.
All NAT solutions offer configuration options for explicit assignement of active open requests arriving at the outer NAT IP and directed to a particular network port to a single private network IP where the server application supposed to handle those connection requests runs. The process is also denoted as inverse masquerading, port forwarding or setting up a Virtual Server. While rules are usually defined based on a destination port --> private network IP mapping there exist less accurate configuration options also which allow to redirect all incomming active open requests regardless of the destination network port to a single private network IP. The computer on that IP is then supposed to run all the server applications handling the incomming requests. This single computer is often labled as Demilitarized Zone (DMZ) in the setup menues of the NAT solutions.
Newer routers may offer a Virtual Server configuration which basically takes care of all incomming traffic from the Internet: from port forwarding to automatically open the firewall for the forwarded ports everything is possible.

Now back to our example. In order to tie the web browser up with the web server we define a inverse masquerading rule that tells the NAT solution to forward all active open requests for network port 80 arriving from the Internet to the private network IP 192.168.1.45 where the web server application is listening on port 80 for connection requests. Now our web browser is able to reach the web server hidden behind the NAT solution by using the NAT's outer IP address: the packet starts at the Internet computer with destination IP 217.80.180.5 and destination network port 80 in the IP header of the packet carrying the active open connection request. Once it arrives at the NAT's outer interface the NAT solution will lookup the destination network port in the packet which is 80. Since a rule was configured to forward all connection requests for port 80 to the private IP 192.168.1.45 the NAT now knows how to handle this packet: it'll replace the destination IP in the header still pointing to the outer NAT IP 217.80.180.5 with the private network IP of the computer associated with network port 80, which is 192.168.1.45 in our example. Then the packet is injected into the private network where it finally reaches the computer running the web server.

NAT and TA

The only reason why you have problems to get TA running from behind a NAT solution is the approach Microsoft took when implementing the - nowadays legacy - DirectPlay interface comming with the DirectX software package: TA is an old game that had been developed before 1997 and is thus utilising that back then brand new but nowadays outdated legacy DirectPlay interface so in a TA multiplayer game every TA instance acts as a server and client application at the same time. This implies that each TA instance will actively open connections to each other TA computer in the game and will listen for connection requests from the other TA computers in the game at the same time. To stick to our examples above: TA acts like a web browser/web server hybrid.
The client role (initiating connections to the other TA computers from inside the LAN) is no problem at all since the NAT entity can handle those on the fly. It's the TA instances server role that causes the trouble: In a multiplayer game each TA instance will listen on two ports taken somewhere from the range between 2300 and 2400. That's a bit like a web server which decides to pick a random listen port from range 2300 to 2400 rather than using the single, well known port 80 when starting up. If TA had a configuration entry in the totala.ini file that would allow to set two well known ports for the TA network communication then things would be way easier, but that is not the case.

The two sections below introduce two possible ways to configure the NAT entity so it allows you to play TA on the Internet from behind it. Note that more complex scenarios (like participating in the same TA Internet game from behind the NAT solution with more than one computer) require the NAT entity to provide support for a special kind of network traffic handling. So not all scenarios described in either of the two sections may work for you, simply because the NAT solution may lack this kind of functionality.

Configuring a router without using Universal Plug and Play (UPnP)

Older hardware routers or software routers may not support UPnP or the router supports it but you have decided to turn it off (probably due to security concerns, see explanations in the UPnP conclusions section below).
In any case, without UPnP you have to create the port forwarding rules for TA in the router setup interactively and you may also have to configure a firewall possibly residing in the router device itself for the TA network traffic.
When it comes to special TA/router scenarios (like entering the same TA game with two TA instances from behind the same router) it might also be needed to configure and run additional tools on the LAN computers involved.

Playing TA Internt games from behind the router with a single computer

It's basically like setting up inverse masquerading, port forwarding or a Virtual Server for a Web Server as described in the general NAT section. The only difference is that you have to configure more than one network port.
Since you go for manual port fowarding make sure that you setup the forwarding rules in the correct section of the router setup. Avoid any port forwarding menu sporting the terms UPnP or trigger. The menues you are looking for do usually feature terms like Virtual Server, inverse masquerading or simply port forwarding.

Below follows the description of three different ways to configure a router/firewall manually for TA Internet games, each having its own advantages and disadvantages.

The compromise between security and effort

This is a compromise between security and simplicity. It's a bit more complicate to set up compared to DMZ but at least it doesn't require detailed knowledge about the ports TA actually picks out of the possible DirectX 7 range when running on a particular LAN computer:

No matter whether you want to host and/or join a TA game from behind the router you need to configure port forwarding rules for incomming connection requests on the ports 2300-2400 (inclusively) for the protocols UDP and TCP. If there is no protocol option in the forwarding configuration of your router setup just go with the port number and it should be ok. Some routers offer an additional port mapping option between a so called public to a private port. Since you don't want to re-map the ports just use the same numbers for the public and private port for any rule you create. Use the inner (LAN) IP address of the computer you want to play TA on for the target IP entry in each forwarding rule.
If your router configuration doesn't support port ranges for a single forwarding rule this will become a quite annoying exercise because then you had to create 101 respectively 202 port forwarding rules depending on whether or not each rule also requires an UDP and TCP protocol distinction.
In order to be able to host TA games from behind the router you also need to configure a port forwarding rule for incomming connection requests on port number 47624 using the TCP protocol. Again, if the router configuration doesn't allow a distinction between protocols for forwarding rules it should work ok by just naming the port number. For the target IP entry of the rule use the the same inner (LAN) IP address as in the forwarding rules for the ports 2300-2400.

Most routers designed for home use seem to default to a 'let all traffic pass thru' firewall mode so you are usally done after configuring port forwarding. If you still can't get into a Internet game or other people time out when joining a game you host yourself then it's probably a firewall that blocks the traffic.
Keep in mind that a blocking firewall needs not necessarily to be located in the router device, you have also to consider the scenario where a software firewall is running on the TA computer itself. In any case if a firewall is active and blocking traffic on default then you need to open it for the following traffic directions/ports:

No matter whether you want to join and/or host TA games you need to open the firewall for the protocols UDP and TCP for incomming traffic on the ports 2300-2400 (inclusively).
If the firewall is part of the router then it's possible that creating forwarding rules (see above) automatically opens the firewall for incomming traffic on the forwarded ports too. In that case it's not required to manually add firewall rules for the incomming TA traffic on the ports 2300-2400.
Because UPnP enabled routers are widely used nowadays you can't restrict the outgoing TA traffic to the port range 2300-2400 anymore. If a remote TA instance is sitting behind a UPnP entity and is joining an Internet game its LAN listen port number out of the range 2300-2400 will be mapped to an unpredictable listen port number used at the router's WAN interface. Thus, you have no other choice than opening the firewall for all ports for the outgoing traffic.
If you want to host TA games from behind the firewall then open the firewall for the protocol TCP for incomming traffic on port 47624. Again, with router firewalls creating a forwarding rule for port 47624 may already have lead to automatic creation of a firewall rule that opens it for the incomming traffic on that port.

A quick overview fo the configuration tasks mentioned above follows:

Operation Port Protocol Direction Possibly automatically created Comment

forward ports 2300-2400 UDP - - -

forward ports 2300-2400 TCP - - -

forward port 47624 TCP - - Only required if you want to host games

The following rules are only required if the firewall blocks all traffic on default

open in firewall 2300-2400 UDP incomming yes -

open in firewall 2300-2400 TCP incomming yes -

open in firewall 47624 TCP incomming yes Only required if you want to host games

open in firewall all ports UDP outgoing no -

open in firewall all ports TCP outgoing no -

The De-Militarized Zone (DMZ) option
Alternatively, most routers offer a DMZ option which implements a sort of 'mass port mapping' because once enabled all incomming connection requests on all possibly port numbers will be forwarded to a single inner (LAN) IP address. DMZ should also open all ports in a firewall that resides in the DMZ entity itself for incomming and outgoing traffic between the Internet and that single LAN IP address. The DMZ menues shouldn't be all to hard to understand: All you have to enter is the LAN IP of the computer you plan to play TA on.
While DMZ is certainly the easiest way to configure a router for TA it's also the one introducing the greatest security risk: By forwarding more than the actual required ports you take into account that unwanted connection requests initated from Internet (like trojan clients probing IPs for infected computers at those ports) are not stopped at the router's Internet interface already. Instead such connection attempts would be forwarded to the DMZ's target LAN computer like any other 'legal' connection request you actually expect (f. ex. from another TA computer on the Internet).
In case this computer was previously infected with a virus that installed the fitting server part of the probing trojan client then it'll respond to that connection request by hooking up with the trojan client at the other end, thus allowing the attacker to gain control over the LAN computer. If there is no such trojan server part running because the computer is not infected then threre is certainly nothing to worry about: The probing trojan client would just get no response after the request was forwarded to the LAN computer and would give up on it sooner or later.
To understand why restricting port forwarding to the required ports can improve the level of security imagine the following example: The LAN computer designated to receive all the DMZ traffic got infected by a virus that installs the server part of a trojan. That server part will automatically start up with the computer every time you boot it. Let's assume the trojan server is listening (waiting for) connection requests on port number 6666. Now, when you use DMZ to forward all connection requests to the infected computer than your TA might work because the incomming requests on a DirectX 7 port between 2300-2400 respectively port 47624 will be forwarded correctly. Sadly, a connection request of the trojan client probing the router's WAN IP at port 6666 will also become forwarded to the infected computer, thus the waiting trojan server part will be able to hook up with the remote client part.
Now, what had happened if the computer was still infected with the server part of the trojan but instead using DMZ you had only forwarded the port range of 2300-2400 and port 47624 to the infected computer. In this scenario the client part of the trojan would probe the router's outer IP at port 6666 but would get no response at all: The router would simply reject the connection attempt since no forwarding rule exists for that particular port number. In other words, the trojan server part running on the infected computer would never be able to hook up with the remote client part, it would just starve behind the router, completely isolated from the Internet.
Althoug reducing the port forwarding range doesn't protect you against all kinds of trojans (some may become active themselves even without being sparked by a remote client) it's still another level of security you can add to your LAN.

Maximal security requires some additional effort

You can also take the inverse approach to DMZ and forward less ports than the whole 2300-2400 range for the incomming traffic. Bear in mind though that it's not possible to restrict the port range for the outgoing traffic in a firewall because a TA peer instance could possibly be sitting behind an UPnP entity which in turn makes it impossible to predict the port numbers under which such a peer instance can be reached.

However, in order to minimize the number of opened and forwarded ports for incomming TA network traffic you still need to know what UDP and TCP port out of the 2300-2400 range the TA instance running on your local computer grabs for its listening ports (in the table below those two ports are denoted as TA listen port 1 and TA listen port 2). An easy method to figure them out is to use the tool gettalistenports
Remember that some routers may create according opening rules in the firewall for each forwarded port. So you may not need to add some of the firewall rules listed above with such a device. Also, the router may or may not offer a protocol option for port forwarding. If it accepts a protocol distinction make sure you pick the correct one. gettalistenports tells you which of the two dynamic ports is bound to the UDP respectively to the TCP protocol. If there is no protocol distinction just enter the port numbers. If there is a port re-mapping option in the forwarding setup then use the same port number for the often so called private and public port since re-mapping has no use for TA.

In case your router doesn't allow to define forwarding rules for port ranges but only single ports this approach is also a workaround for the 101/202 forwarding rule problem.

In this scenario I assume that the firewall blocks any traffic on default so you had to add opening rules for TA:

Operation Port Protocol Direction Possibly automatically created Comment

forward port TA listen port 1 UDP - - -

forward port TA listen port 2 TCP - - -

forward port 47624 TCP - - Only required if you want to host games

open in firewall TA listen port 1 UDP incomming yes -

open in firewall TA listen port 2 TCP incomming yes -

open in firewall 47624 TCP incomming yes Only required if you want to host games

open in firewall all ports UDP outgoing no -

open in firewall all ports TCP outgoing no -

Single computer conclusions

Remember, port forwarding on a particular port is always asscoicated with a fixed inner IP. For example, if you set up a router so it forwards the connection requests to IP 192.168.1.45 because that's the computer TA is installed on and you install TA later on a second computer that has the IP 192.168.1.70 assigned then you can't play TA Internet games on the 2nd computer unless you change the IP in the forwarding rules from 192.168.1.45 to 192.168.1.70. On the other hand, once you changed the forwarding rules so they now suite the IP of the 2nd computer you can't play Internet TA games on the 1st computer anymore.
If the router assigns each LAN computer a IP from an IP pool every time it boots then the IP of the TA computer might change after rebooting it, effectively invalidating the IPs in the the port forwarding rules for TA. This kind of dynamic IP assignment is implemented by a functionality called Dynamic Host Configuration Protocol (DHCP). A good DHCP implementation should try to assign a computer the same IP it had the last time it got tied into the LAN so chances are slim that the assigned IP address would ever change, even with DHCP enabled. Still, if you notice that Internet TA stops working out of a sudden and you are using DHCP in your LAN then an IP address change might be the reason. In such an event you have two options:

You edit the port forwarding rules so they point to the newly assigned LAN IP address of the TA computer.
You configure the TA computer so it utilises a so called static LAN IP address. Make sure though that you pick an address that is outside of the DHCP IP address pool configured in the router.

I also made the experience that some routers have problems to work correctly when you create contradicting or redundant rules:

If you go for DMZ then don't create any other rules in the forwarding or firewall configuration for the designated DMZ IP address.
Don't enable the UPnP option possibly existing in the router when you setup rules for DirectX applications (usually games) manually. You go either for UPnP or manual configuration, never for both at the same time.
If your router created implicit firewall opening rules for forwarded ports then make sure that you don't create the same rules manually again.

Playing TA Internt games from behind the router with multiple computers

The basic problem to solve here is to make each TA instance running on a LAN computer to use a unique pair of TCP/UDP listen ports so an incomming connection request network packet arriving at the NAT entity's WAN interface being directed to a LAN computer represented by the destination information WAN IP:ta instance listen port can be forwarded to the final LAN destination by applying the port forwarding rule for ta instance listen port.Basically the goal is to overcome the ambiguity of the WAN IP shared between all LAN computers by associating each LAN computer with a unique TA listen port. This way the port forwarding rules allow to split the incomming connection request based on their destination port number: The combination of WAN IP:ta instance listen port must be unique for each TA instance. Also note that when it comes to splitting the incomming connection requests by port forwarding rules it doesn't matter whether you would like to join the same Internet TA game or different Internet TA games with the TA instances in the LAN, you'll need the splitting setup in any case.
Keep in mind too that because the initial TA client-->TA host join traffic is always directed to the static TCP port number 47624 and since a single port can only be configured to point to a single LAN IP in the NAT solution's port forwarding setup it's not possible to host more than one TA game from behind a NAT solution. This also implies that you can't switch the hosting role between the LAN computers without changing the LAN IP for the port 47624 rule in the port forwarding configuration of the NAT entity to the new host's LAN IP.

Unfortunately neither TA nor the legacy DirectX 7 network interface allow to configure the TA listen port numbers to use explicitly, thus DirectPlay will pick the two listen ports for each TA instance somewhere out of the range from 2300-2400. Because of this default behavior you will most likely end up with two identical pairs of TA listen ports on each TA computer, at least so long as the DirectX versions and/or Windows operating system versions don't differ.
In either case the first task is to figure out whether you end up with different listen port pairs on each TA computer and if not so to force some of the TA instances to use differnt ports. For the time being, I know of two possibilties to gurantee the uniqueness of ta instance listen ports described below:

Port forwarding - the 'you are lucky approach'
It seems TA listens always on the same ports within a specific environment (at least as long you haven't played other DirectPlay based games on that computer before launching TA). If you recognise that the TA instances running on the different computers pick different pairs of network ports after starting them up then you are pretty much done: all you have to do is to setup different forwarding rules to associate each port pair to the according private network IP (see example scenario below for details).
Now all you need to know is how to figure out the TCP and UDP protocol port numbers TA utilises on a particular computer. One option is to run the Windows operating system's netstat command after you launched TA and entered the battle room screen. People being inexperienced with computer related stuff may run into problems when it comes to isolate the correct port numbers in the command's output though. So a second option is to use the tool gettalistenports instead which produces an output that is much easier to interpret.
Port forwarding - DXport, the 'brute force' approach
TEA_Crash was so kind to give me the information about this DirectPlay tool. It's a program named DXport which performs dummy binds for network ports to hinder DirectPlay to use them itself. The idea is to dummy bind different port ranges within the boundaries of 2300 up to 2400 on the different computers supposed to run TA. That leaves each TA computer with a different range of unused ports within the range from 2300 up to 2400 and since DirectPlay seems to detect the already bound ports and sticks to the first free gap one can make a (hopefully) valid assumption about the port range DirectPlay will utilise on a particular computer that runs DXport. Unique listen port pairs in turn allow to define unique port forwarding rules for a particular LAN IP address in the NAT entity's configuration which was the goal we want to achieve in first place.
You can download DXport for free. The tool is pretty easy to use and the site does also provide a documentation and examples on how to use it so I don't bother with going into details here.

Now, after all this abstract discussion of the topic a concrete example should help to make things a bit more clear. Suppose you want to join Internet games with two LAN computers from behind a NAT entity. The LAN IPs of the two TA computers are 192.168.1.4 and 192.168.1.8. You decide to make the computer with LAN IP 192.168.1.4 a possible TA game host and by using the tool gettalistenports you already figured out that on both computers TA utilises the same ports: 2300 for the TCP protocol and 2350 for the UDP protocol so the listen port pairs of the two TA instances are ambiguous. This leaves you with the following configuration tasks:

Make sure that the TA instances running on the two computers are binding different DirectPlay ports. With two computers using the same TA TCP/UDP ports you only need to force one of them to use a different TCP/UDP port pair So you decide to leave the default TA ports 2300 (TCP protocol) and 2350 (UDP protocol) untouched for the computer having the LAN IP 192.168.1.4. On the computer with LAN IP 192.168.1.8 you then use DXport to force TA to bind port 2310 for the TCP protocol and port 2311 for the UDP protocol communication.
Configure four port forwarding rules in the NAT configuration. The first rule has to cause incomming TCP connection requests arriving at the the NAT's outer interface and directed to port 2300 to be routed to LAN IP 192.168.1.4 while a second rule has to forward UDP traffic directed to port number 2350 to LAN IP 192.168.1.4 as well. That covers all traffic routing required for the first LAN computer
Then you need a third rule that routes incomming TCP connection requests directed to port 2310 to the LAN IP 192.168.1.8 and a fourth rule which forwards UDP network packets directed to port 2311 to LAN IP 192.168.1.8 as well. The latter two rules cover the routing required for the second LAN computer.
Since the computer with LAN IP 192.168.1.4 shall be able to act as TA host you also need a fifth port forwarding rule that routes TCP connection requests directed to TCP port 47624 to the LAN IP 192.168.1.4.
Configure any firewall located in between the TA computers and the Internet to let pass the network traffic on the required ports.

Below follows an overview for the configuration tasks related to the particular example described above. Before Unviversal Plug And Play (UPnP) was introduced it had been sufficient to open the firewall for the outgoing traffic only for the DirectX 7 port range 2300-2400. But in the event a peer ta instance sits behind a UPnP entity the LAN listen port numbers it picks out of the range from 2300-2400 will be mapped to unpredictable port numbers at the UPnP entity's WAN interface. So, in order to be able to join up with ta instances residing behind UPnP entities too you have no choice but to open the firewall on all ports for the outgoing traffic.
If the firewall is residing in the router then creating a port forwading rule may automatically create an according firewall opening rule for the incomming traffic on the forwarded port so you may not have to create such a rule explictly in the router's firewall configuration settings:

Operation Port Protocol Target IP Direction Possibly automatically created

forward port 2350 UDP 192.168.1.4 - -

forward port 2300 TCP 192.168.1.4 - -

forward port 47624 TCP 192.168.1.4 - -

forward port 2311 UDP 192.168.1.8 - -

forward port 2310 TCP 192.168.1.8 - -

The following rules are only required if a firewall blocks all traffic on default

open in firewall 2350 UDP 192.168.1.4 incomming yes

open in firewall 2300 TCP 192.168.1.4 incomming yes

open in firewall 47624 TCP 192.168.1.4 incomming yes

open in firewall 2311 UDP 192.168.1.8 incomming yes

open in firewall 2310 TCP 192.168.1.8 incomming yes

open in firewall any port UDP Any IP outgoing no

open in firewall any port TCP Any IP outgoing no

After incomming TA traffic splitting has been configured in the router and on the involved TA LAN computers as described above you are ready to play TA on the Internet with more than one TA computer from behind the router so long as you don't try to join the same TA Internet game instance.
Whether you can join the same TA Internet game instance with more than one of the TA LAN computers depends on how the router you use implements a very special kind of network traffic routing I liek to call U-bend forwarding. So if you don't plan to join the same game with more than one of the LAN computers you are pretty much done here and can stop reading on.

Router prerequisites for joining the same Internet game with multiple computers

When you want to join the same game instance hosted on a Internet game service with more than one LAN TA computer then your router needs to support what I call U bend forwarding. Depending on the way U bend forwarding is implemented by the router certain scenarios may or may not work. This issue is completely detached from the topic on how to pin TA running on different LAN computers on different ports. If your router doesn't implement proper U bend forwarding then having successfully pinned all LAN TA instances on different port numbers won't help to fix anything. Keep in mind that if you want to join different Internet games with each of the TA LAN instances then the U bend forwarding capabilities of the router don't play a role at all.

Below follows a description of the possible scenarios and the prerequisites the router has to fulfill U-bend forwarding wise to get them working:

The most sophisticated U bend forwarding implementation is required when you want to run the TA host and at least one TA client in the same LAN behind the router.
In this case the router needs to re-inject network packets originating from a LAN computer and directed to the router's WAN (Internet) IP back into the LAN again by applying the normal port forwarding rules to it. Re-injection support over the router's outer IP is required because the game service software will reconize all TA computers behind the router by its WAN IP rather than by the LAN computer IPs'. So the game service software will reconize the TA host by the router's WAN IP too and will consequently tell any joining TA client that this is the IP to connect to join the game. While this all fine with TA clients trying to join from the Internet it creates a special situation for a TA client trying to join the game from within the same LAN as the TA host: Basically the game service tells such a LAN TA client to contact the TA host not by using the host's LAN IP but the router's WAN IP. It's easy to understand that without re-injection support by the router a LAN TA client will never be able to establish a connection to the LAN TA host residing in the same LAN.
But re-injection support is not the only thing the router needs to provide if the TA host and a TA client sit in the same LAN. Before re-injecting such a packet back into the LAN it also has to replace the LAN packet's source IP field content still refering to the the LAN IP of the sending computer with its WAN IP. Otherwise the TA host would put the TA client's LAN IP on its internal list tracking the IPs of the TA clients that have joined the game so far rather than associating this LAN TA client with the router's WAN IP. The trouble with such a LAN IP spoiled TA client list starts as soon as a TA client located on the Internet tries to join the game: After the TA host transfered a copy of this list to the joining Internet TA client this client tries to establish a direct connection to each IP to be found on this list. Now, while TA clients sitting in the same LAN as the TA host would certainly have no problem with connecting other LAN TA clients by using their LAN IP, our Internet TA client would just fail to do so.
On the other hand if the router actually supports that advanced degree of U-bend forwarding then the TA client list maintained by the TA host would look different: After the router has replaced the LAN source IP in packets originating from the LAN TA client by its own WAN IP and has re-injected them into the LAN the TA host does recognize the joining LAN TA client by the the router's WAN IP rather the LAN TA client's LAN IP. Consequently the LAN TA client would appear as associated with the router's WAN IP on the TA hosts client tracking list, allowing other LAN and Internet TA clients to contact this TA client because the router's WAN IP can be addressed from both locations.
For joining the same TA game hosted outside of the LAN with more than one LAN TA client from behind the same router it's not required anymore that the router replaces the LAN IP in the source field of network packets originating from the LAN and directed to its WAN IP by its own WAN IP because in this scenario the TA host resides on the Internet and thus does recognize all LAN TA clients by their router's WAN IP anyways. Therefore the TA host's client list will never end up as being spoiled with a TA client's LAN IP.
But the router still needs to re-inject this kind of network packets back into the LAN according the forwarding rules because any LAN TA client joining the game after at least another LAN TA client is already in the game needs an open detouring route to other LAN TA clients via the router's WAN interface simply because the TA host has associated all LAN TA clients sitting in the same LAN with a unique IP, namely the router's WAN IP, and that is exactly the IP the joining LAN TA client will receive from the TA host and use in order to establish a connection to the other LAN TA client(s) already in the game. If the detouring route wasn't open LAN TA clients would fail to connect to each other.

If you run into problems when trying to get either of the two scenarios above working and are not sure whether it's a configuration problem or a real issue with the router's U bend forwarding implementation then I recommend to test the router with the tool ubendcheck.

Multiple computer conclusions

The same considerations as in the Single computer conclusions section do apply here as well. Besides that joining different games with multiple LAN TA clients should always work when you were able to get it working for a single LAN comouter beforehand. It only results in more port forwarding rules and possibly additional configuration efforts for DXport on some of the LAN TA computers. Whether you get multiple LAN TA clients into a single TA Internet game depends only on the U-bend forwarding capabilities of your routing solution and nothing else.

Compared to using UPnP (see next section) setting up the multi TA client enviornment manually can become a quite annoying exercise but I still recommend to use the manual approach instead of the UPnP option so long as you get things technically working. The UPnP conclusions section states in detail why I think so.

Configuring a router by utilising UPnP

UPnP is a relative new method to negoiate a LAN/WAN port mapping for incomming connection requests between an application running in the LAN and a WAN router. When TA had been coded UPnP didn't even exist so the game itself lacks the ability to negoiate said mapping. The reason why it works nevertheless is the DirectPlay interface which is part of Microsoft's DirectX software package. It's the DirectPlay program code which handles the port negoiations with the router on behalf of the legacy applications utilising DirectPlay. Because the UPnP protocol allows any LAN computer to gather the current mapping table from the central hub (the router) port mappings can even be negoiated across LAN computers (which is a great advantage for certain kinds of scenarios). In order to get UPnP working properly you should check the following issues:

Update DirectX on each TA computer to the latest version available for your Windows operating system.
Make sure that you have installed the latest router firmware available for your particular device.
Don't configure port forwarding rules manually (at least not for DirectPlay related programs) after you have activated the UPnP functionalities in the router. I know of at least one device that can't cope with such a setup. Either go for manually setup rules or UPnP but never take both approaches at the same time.

Joining TA games on the Internet from behind a router

Once you have UPnP enabled in the router any join scenario should work, no matter how many LAN TA clients are involved. Neither does it play a role whether you try to join the same or different games.
It's worth to note that the question whether or not the UPnP enabled router supports U-bend forwarding is of no relevance since it seems that the DirectPlay layer on all involved LAN computers is aware of the fact that the other LAN computers can be reached directly by using their respective LAN IP. So the inter LAN traffic is not detouring over the router's WAN IP interface but is rather exchanged directly between the LAN TA clients.

Although the router firewall and any Microsoft software firewall possibly running on the TA computer(s) involved in the game(s) should automatically become opened for the ports utilised by UPnP managed connections it's theoretically possible that another 3rd party firewall residing anywhere between the UPnP enabled router and a LAN TA computer might block the traffic. If such a firewall exists make sure that it's open for traffic directed to any of the LAN TA computers on the ports 2300-2400. Since TA clients on the Internet can be located behind a UPnP entity as well you can't just restrict the allowed outgoing traffic to the range 2300-2400 too since it's absolutely unpredictable what port number a UPnP entity uses at its WAN interface to expose and map one of the ports used by a TA client in its LAN. So you have no choice but to allow outgoing traffic on all ports directed to all IPs.

Hosting TA games on the Internet from behind the router

At least with the UPnP router model I used for the tests it wasn't possible to setup a TA host in the LAN. First of all no port mapping had been created in the router for port 47624 once the TA host instance was up and running in the LAN so joining the TA server instance from the Internet was impossible. After I added a port forwarding rule for port 47624 manually in the router configuration that pointed to the LAN IP the TA host was running on an Internet TA client saw the game but was still unable to join it.
So for now I assume that hosting with UpnP is not always possible. It may depend on the router too, though. If hosting in UPnP mode doesn't work for you then disabling UPnP and setting stuff up manually is an option, at least so long as you are not planning to run some of the more complex scenarios (like joining the same Internet game with more than one LAN TA client).

UPnP conclusions

While UPnP saves you from configuring port forwarding rules in the router setup manually and also makes certain scenarios that would otherwise require a great deal of additional configuration efforts work without much hassle it also poses a security threat to your LAN: Creating a new port mapping rule via the UPnP protocol is done without any authentication of the port mapping requester entity for whatsoever which means that any program running on one of the LAN computers can open additional ports in the router without any user interaction or user notification. Think about that: Enabling UPnP is pretty much like disabling the user/password login for the interactive router configuration at least when it comes to the port forwarding menu setup access. For example, with UPnP functionalities enabled a trojan or virus that could successfully infect one of the LAN computers beforehand can open additional ports in the router on the fly, allowing maleware software to run in an anonymous broadcast listen modus (by waiting on commands on the opened ports) rather than making it necessary for it to contact a well known server for further instructions (whoms IP had to be put somwhere into the program code then which is much of a give away that makes it much easier for anti virus manufactors and Internet Provioders to stop the virus right in its tracks).

If you haven't noticed it by now: Due to the security risks comming bundled with UPnP I'm not a great fan of it. To make things worse some router manufactors like Netgear did start to ship router firmware upgrades for their devices which turn on the optional UPnP interface on default.
Security and UPnP are two basic principles that can't be fused together into a working concept: UPnP stands for the 'easy to use' approach (as in don't annoy the user with a learning curve that my frustrate him to the point where he drops the product) while the term security always requires at least some basic understanding of what one is doing (as in setting up firewall and/or port forwarding rules explicitly and not leaving that task to some piece of software). It doesn't come as a suprise that Microsoft is one of the driving forces behind UPnP - the 'easy to use' approach has helped to make their products such a success but one has always to realize that this simplicity comes for a price.
My advice is: Disable the UPnP support in the router if it's available at all and take the time to configure port forwarding and firewalls manually. Even for complex scenarios (like getting two TA instances into the same TA game hosted on the Internet) exist alternatives which make use of UPnP unnecessary.
I'm well aware that many people lack the knowledge required to configure a router for a particular game in something like two minutes but it's my strong opinion that in the times of the Internet you should have some basic knowledge about what you are dealing with. The concept of Internet connection addressing is not more complex than the concept of streets (IP addresses) and house numbers (ports). If you understand how the postman is able to deliver your real world mail then you should also be able to grasp the concept of how Internet computers contact each other. Just take the time to understand this stuff - it may cost you one week of research and fiddling around with the router for your first type of Internet game but it won't take that long again for the next type of game afterwards.

Page last updated 2006/06/18 by tcbw@tcbw.net