Traversing Firewalls and NATs

Notes

As almost everybody is aware, the Internet is partially partitioned by the presence of firewalls and Network Address Translation devices.  Many hosts do not have a globally visible IP address on any network interface and instead have private network address that are  translated to and from a global address via an intermediate host usually referred to as a firewall or NAT router. This usually isn't a problem for an outgoing connection as the intermediates are designed to handle this situation transparently.  However, an incoming connection is a problem. The intermediate gets the connection...and it has no idea that the connection should be forwarded to an interface on its other side.

There are a number of solutions to this problem. You can manually configure the intermediate to recognize that an incoming connection on a certain port should be forwarded to a service on another host. There are also several systems for having service software configure the intermediates automatically. They unfortunately aren't inter-compatible nor standardized. (http://en.wikipedia.org/wiki/NAT_traversal)

In simplified TeaTime the only service that gets incoming TCP connections is the message router. All of the island replicates only generate outgoing TCP connections to the router. In the variation used by Wisconsin there are two islands, one for the scene graph and another for content distribution.  On a LAN there is a contact point system (CRQT) that broadcasts over UDP the appropriate connection information, the router IP, port number, and the UUIDs of the capabilities that identify the specific island, and the scene graph object to use as a teleport destination. Note that the router does not have to run on the same host as any of the island replicates.

We must have a manual configuration option as some intermediates don't have any automatic means of configuring NAT (or this my be prohibited by the security policy) and  some of the more complex configurations won't work with the automatic systems. Many of the pieces of the manual configuration system can serve as a building blocks for more automatic schemes.

Just for clarity and generality, we'll assume that the router is being run on another host. This implies that the router will have to either handle the NAT traversal and and communicate the appropriate address information back to the initial connecting island so it can generate the contact point or it will do all the contact point handling itself when a new island connects and registers. Either scenario can work, more research is required into finding the optimal approach.

Thus, we need some way to tell Open Cobalt that there are potentially two kinds of contact points (or perhaps extend the contact points to have both addresses and ports). If the request for a contact comes from a host NOT on the local private network (or the intermediate?), the postcards/contact points it hands out for itself should have the address information for the intermediate rather that the local host. This will also require a way of fixing the port number of the cobalt message router at start-up.  This should be pretty easy to do and should be the first thing do do in this area. Manual configuration alone will be adequate for an early release which will be looked at by competent developers.  There should be some preferences that the NAT traversal configuration can be stored in.

The automatic configuration options require some more thought as it is not obvious which approach should be first. We might want to survey our user base or write detection software and gather some statistics about which automatic system is more common to get the most effective use of our time. But once a manual system is working it should be straightforward (if time-consuming) to have an automatic configuration mode.

• Configuration and Firewall transition software
• IETF Protocols
• Zeroconf - service location protocol (SLP, srvloc) - http://www.zeroconf.org/
• Bonjour (was Rendezvous) - http://www.dns-sd.org/
• a service announcement/discovery protocol that is layered on the DNS 
• Designed for local use, but nothing stops it from working over the Internet at large. 
• Would be cool to have a croquet router or island announce itself using Bonjour 
• NAT Port Mapping Protocol (NAT-PMP) - http://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol 
• Fairly simple protocol, not a lot of implementation effort would be required.
  
• Simple Traversal Underneath Network Address Translators (STUN)
• For UDP only
• Might be useful if we want to extend the "here I am" protocol outside the firewall. 
• Universal Plug & Play (UPnP) - http://en.wikipedia.org/wiki/UPnP
  
• Microsoft protocols, with all that implies 
• Simple Service Discovery Protocol (SSDP)
• Like Bonjour, a service announcement/discovery protocol
• Uses multicast for announcements, could theoretically work of the WAN, but multicast router support is currently kinda scarce. 
• Would be cool to have a croquet router or island announce itself using SSDP
  
• Internet Gateway Device Protocol (IGD)
• Many current NAT router support this.
• Unfortunately is insecure so it usually turned off by default. 
• Unfortunately uses SOAP for device control.
• SOCKS
• http://en.wikipedia.org/wiki/SOCKS
• It's major drawback it that it can require a rewrite of your networking support as it's essentially an outboard TCP/IP system.
• And it is gradually losing popularity. 
• SSH Tunnels?
• SSH is for technical users.
• Has some security advantages
• Usage scenarios are unclear, but would seem to require an SSHd running on a host with public IPs. 
• VPNs
• L2TP and PPTP
  
• Probably too complex to do.= as an internal protocol
• And it's too complex to set up externally for home users. 

 

• Router preferences?
• router interface and port
• firewall interface and port
• Island preferences
• Preferred registries?

Implementation

Finding the router

After digging around for a bit, it appears that the most widely used automatic NAT traversal option for TCP is the Internet Gateway Device service set (IGD) of Universal Plug and Play (UPnP). NAT-PMP is in use, but on a much more limited scale, and many NAT-PMP routers also support UPnP-IGD. SOCKS is also still around, but gradually going away. I would prefer the IETF protocols (http://www.zeroconf.org/ZeroconfAndUPnP.html), and perhaps I'll implement them later.

So I (jdougan) have implemented a UPnP stack that has enough support to work with the IGD.  As UPnP uses SOAP for controlling the devices and writing a SOAP stack is a PITA, I've just used the SOAPCore client implementation for that aspect. It's a bit large just for this, but we can find or build something lighter weight later.  For that matter, now we have a SOAP client, we may find more useful things for it to do. The UPnP package, which is still under development, is at the Cobalt mc (Monticello) server in the contributions project.  Besides SOAPCore, it also uses the RBT package to manage the UDP sockets. Both of these are available on SqueakMap and by now the updated versions with underscore assignments removed should be available.

To use the UPnP stack, first you must start the announcement protocol (SSDP):

SsdpListener startListener.

or

SsdpListener restart. 

Then we can get a reference to a WANIPConnection IGD service, which is the service that lets us manipulate port forwarding mappings.  Here we just just grab one at random which will work in most cases because there is only one. If you have more than one NAT router visible you'll have to make a more reasoned decision or manipulate all of them in parallel.

wanIpConnServ := SsdpListener wanIpConnectionServices anyOne.

And now we can manipulate the router: