Trate is a software that allows applications on computers behind different NAT routers to communicate. It works by having the Trate applications on each computer register their public IP addresses with a central Trate address server. When one application tries to connect to another, its Trate software checks with the address server to get the other's public IP. It then sets up a direct connection by encapsulating packets and forwarding them through each router. This bypasses the routers' firewalls and allows communication between the applications without complex port forwarding setup.

1. Trate:
Connecting PCs Behind Different NAT Routers.
1. Introduction:
Today, TCP/IP Version 4 dominates the internet. At home,
users have numerous devices that are able to access the
internet via NAT (network address translator) routers, such
as PCs, set-top boxes, PDAs, and FMC dual mode cell
phones. There is a growing demand for convenient ways to
access home servers from workplace computers,
notebooks, or cell phones when away from home. To
access home servers from an outside source, two
conditions must be fulfilled: 1) The user attempting to
access the home server must know the public IP address
of the NAT router to the home server, and 2) The user
must be able to pass through NAT(s) of the home server.
To obtain a public IP address (condition 1) of the NAT
router to the home server, the user either chooses to
register a domain name combined with a static IP address
or to use a dynamic domain name service, otherwise
known as DDNS. To be able to pass through the firewall(s)
(condition 2) of the home server, the user would need to
configure the home server firewall(s). To be able to
configure the home server firewall(s), the user would need
to understand basic TCP/IP concepts, such as source IP
addresses, destination IP addresses, port forwarding, and
DMZ. For some end users, this is a tedious task. My
product implements a user-friendly way to pass through
firewall(s) without having to struggle with such tedious
tasks.

2. 2. Prior Attempts:
2.1. Scenario: Two applications attempt to contact each
other via internet. Both applications are behind NATs. One
is from an outside source, one is a home server.
In the following figure (Figure 1), an application on PC1
is sending out packets in an attempt to communicate with
an application on PC 2. The packet goes through steps 1,
2, 3, and 4, but is unable to complete steps 5 and 6. This
is due to the interference of the firewall in the NAT router
connected to PC2. The packet sent by the application on
PC1 cannot pass through the firewall to reach the
application on PC2.
Figure 1:
Packet Traversal without Trate
*DIP: Packet IP address at that point.
PC1 Router1
Routing Table: Routing Table
(1) Local IP: LAN IP:
(2)
192.168.1.61 192.168.1.1
Default Gateway: WAN IP:
192.168.1.1 64.193.227.2
(3)
Application A
S ender
DIP*: 64.193.227.3
Internet (4)
Application
Listener PC2 Router2
Routing Table: Routing Table:
(6) Local IP : LAN IP:
(5)
192.168.1.61 192.168.1.1
Default Gateway: WAN IP:
192.168.1.1 64.193.227.3
2.2. Scenario: Two applications from separate computers
behind different NAT routers attempt to connect to each
other using STUN technology.

3. To aid VoIP (Voice Over IP) in passing through both
NAT routers, the IETF developed STUN (Simple Traversal of
User Datagram Protocol) technology. STUN has its own
limitations:
1. STUN only supports VoIP applications.
2. STUN requires that the VoIP application be
modified.
2.3. Scenario: Two applications from separate computers
behind different NAT routers are able to pass through
each other’s firewalls using UPnP (Universal Plug and
Play).
This method requires that the NAT router support
UPnP. Due to UPnP’s interoperability issues, it is not
always reliable. If it were, IETF would not have developed
STUN to support VoIP applications.
3. How Trate Works:
Scenario: (Figure 2). Two applications from separate
computers behind different NAT routers are able to pass
through each other’s firewalls using Trate.
1. Application A will attempt to contact the
Application Listener’s public IP (64.193.227.3)
directly. This is the case with programs such as
BitTorrent and Limewire, as well as online
games.
2. Both PC1 and PC2 have Trate applications
installed and running. Trate (PC1 and PC2) will
automatically register their NAT router’s public
IP with the Trate address server. These
registrations will be renewed periodically. If
Application A receives no reply after sending out
many packets to the Application Lister, Trate
will be triggered into action.

4. 3. Trate (PC1) will send a request to the Trate
address server, asking if 64.193.227.3 is
online or not.
4. If 64.193.227.3 is online, Trate (PC1) will
attempt to send a sync UDP packet with the
source IP/port and destination IP
(64.193.227.3)/port to it. Meanwhile, Trate
(PC1) will also inform the Trate address server
that it is attempting to connect with 64.
193.227.3.
5. The Trate address server will record Application
A’s public NAT router IP address
(64.193.227.2).
6. On the Application Listener’s PC, Trate (PC2)
remains connected to the Trate address server.
When Trate (PC2) receives a notification from
the Trate address server that Trate (PC1) is
attempting to connect to it, Trate (PC2) will
send a sync UDP packet with source IP/port
and destination IP (64.193.227.2)/port to PC1.
7. Through Steps 4 and 6, the NAT routers of PC1
and PC2 will create a pass-tunnel between PC1
and PC2. Trate (PC1 and PC2) will continue to
send out packets to keep this pass-tunnel open
until one or both users manually disconnects
Trate (PC1 or PC2).
8. After a tunnel is established, a temp-route entry
is added.
9. The destination IP (64.193.227.3) will go
through the Trate (PC1) virtual interface
(10.8.0.2). This entry will force all such packets
whose destination IPs is 64.193.227.3 to go to
Trate (PC1) before going anywhere else.

5. 10. Trate (PC1) will encapsulate such packets, or
put tunnel heads on them, before sending them
through the default gateway.
11. Through the default gateway, the packets will
go to the internet.
12. When such encapsulated packets reach the
other NAT router (WAN IP 64.193.227.3), the
router will immediately dispatch them to PC2’s
physic NIC (192.168.1.2).
13. PC2’s operating system will forward these
encapsulated packets to Trate (PC2).
14. Trate (PC2) will de-encapsulate the packets and
then send them to the Application Listener.
15. Packets sent from the Application Listener
(PC2) to Application A (PC1) will follow the same
mechanism.
Figure 2:
Trate: Packet Traversal
PC1
(A1)
Application A Temp-Route Entry:
Sender *DIP: Packet IP address at that point.
DIP*: 64.193.227.3 64.193.227.3 **A-DIP: Application destination IP address.
to Router1 Routing
***T-DIP: Trate destination IP addres s.
Table:
10.8.0.2
physic NIC LAN IP:
IP of virtual Trate: 192.168.1.1
Encapsulated Packet.
A-DIP**: 64.193.227.3 10.8.0.2 WAN IP:
T-DIP***: 10.8.0.3 M ask: 64.193.227.2
DIP*: 64.193.227.3 255.255.0.0 (A2) (A3)
Remove Tem p-Route
Entry:
64.193.227.3
to
Default Gateway
PC2 NAT-m apped Packet. Address Server
A -DIP**: 64.193.227.3
T-DIP ***: 10.8.0.3 Encapsulated Packet.
Internet
Encapsulated Packet.
DIP*: 192.168.1.2 A-DIP**: 64.193.227.3
A-DIP**: IP of physic NIC:
T-DIP***: 10.8.0.3
64.193.227.3 192.168.1.2 DIP*: 64.193.227.3
T-DIP***: 10.8.0.3 M ask: (A5)
255.255.255.0 physic NIC Router2 Routing
(A6) Table:
IP of virtual Trate: LAN IP: (A4)
Application 192.168.1.1
10.8.0.3 De-encapsulate
Listener WA N IP:
M ask: Packet.
255.255.0.0 DIP*: 64.193.227.3 64.193.227.3
(A7)
IP of virtual Trate:
(A8)
64.193.227.3