NetTunnel

Chris Nord Project Report COSC 4853 Network Security Project April 29, 2011

1. Introduction 1.1 Background

Network address translation (NAT) is often used anytime two networks need to be bridged, such as between a network of computers in a single residence and the Internet, or between a campus or work network and the Internet. NAT is a useful technology that fills a definite need in networking today, but it also raises some new problems.

1.2 Overview
The rest of the paper is organized as follows. Section Two gives the problem as it stands today. Section Three proposes a solution. Section Four describes our implementation of the proposed solution. Section Five analyzes the results from our implementation. Section Six concludes our project.

2. Problem
Chief among the new problems that a NAT device raises is that a computer behind a NAT device is unable to accept unsolicited traffic (incoming traffic that was not requested by the computer behind the NAT) without configuring the NAT device. This problem arises because the NAT device is bridging two networks, when it receives data from one of the networks it doesn't know how to "map" that data to the other network it's servicing. This isn't a problem when a computer behind the NAT makes an outgoing request, since the NAT device can make a note of the request and route the response appropriately back to the computer. As leaders of a community of game server enthusiasts, we often get asked how to properly configure a server so that clients online will be able to access the game server. For game server hosts who do not run a NAT or firewall on their connection, it's often as easy as just running the server software, and clients will immediately be able to connect to the game server; for other server hosts, it's a discussion on ports, routers, and what NAT means for their game servers. Still other server hosts are unable to properly configure a server online due to restrictions beyond their control at the network level. The difficulty in exposing services to other clients across the Internet can usually be broken down to one or more of the following: 1. One or more firewalls between the application and the Internet need to be configured to allow incoming, unsolicited traffic to the ports the service uses. 2. One or more NAT devices between the computer hosting the service and the Internet need to configured to route incoming traffic to the appropriate next hop on the local segment. 3. Somewhere between the application and the Internet the service is being intentionally blocked.

3. Proposed Solution
In order to help people get their services up and running quickly without having the hassle of changing settings, learning about networking, or having exemptions made by their local IT staff, NetTunnel was born. NetTunnel is intended to provide a means for users with a lack of knowledge on networking or on a restrictive network an easy and simple means to share network services (such as Apache or Ventrilo) with other clients in a secure manner. We propose solving all three of the problems by using a combination of existing technologies. Problems 1 and 2 can be overcome by NAT punch-through, which basically makes the router think that incoming traffic is actually outgoing traffic. Firewalls and NATs are generally less restrictive with outgoing traffic. Problem 3 can be solved by taking charge of the protocol being used between computers and encrypting the communication.

4. Implementation
Each client has its own unique public/private key pair which is used to send encrypted data across the network. The server has it's own public/private key pair as well. To send serialized data between clients and to and from the server we used protobuf-net by Marc Gravell. [1]

4.1 Hardware Configuration

For all tests, the configuration was the same and the computers had the following specifications: Component Client A Client B Server CPU Memory Operating System Compiler Connection Type Intel Core 2 Duo E8500 (3.16 GHz) 4.00 GB Windows 7 Pro x64 Visual Studios 2010 RC1 AMD Athlon XP 1700+ (1.4 GHz) 0.45 GB Ubuntu Server 9.10 Mono 2.4.2.3 Intel Core 2 Quad Q9650 (3.00 GHz) 1.00 GB Ubuntu Server 9.10 Mono 2.4.2.3

Wired University (5 Wired Residential Wired Data Center Mbps down, 3.55 (1.28 Mbps down, 710 (8.81 Mbps down, Mbps up) Kbps up) 6.41 Mbps up) Table 1 Hardware Configurations

4.2 Network Configuration

The server has a direct connection to the Internet. Both clients are connected to the Internet through separate port restricted cone NATs. A port restricted cone NAT is defined as, "Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent through eAddr:ePort. An external host (hAddr:hPort) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort had previously sent a packet to hAddr:hPort." [2]

Figure 1 Network Configuration

4.3 NAT Punching

NAT punching is accomplished by having an open server on the Internet that can act as an introducer between clients. The introducer keeps all clients updated on what services (I.E. Apache or Ventrilo) all other clients are offering. If a client A wants to connect to a service on client B, client A sends a request to the introducer asking to connect to the service on client B. If the introducer accepts the request, it informs client A and client B to try to connect to each other and provides each of them with the other's IP and port information. Client A and client B both attempt simultaneous connections to each other until they have connected or until a timeout period has passed and they give up. The connection between clients is made possible because both sides of the connection are considered an outgoing connection by any NATs or firewalls. If client A is the first one to send a packet, it might bounce off of client B's NAT since it doesn't recognize client B as having an outgoing connection to client A, but as soon as client B sends out a packet, a connection there becomes possible (the NAT registers the outgoing connection).

Figure 2 NAT Punch-Through

4.4 Forwarding System

Taking control of the protocol between computers is made possible by a local forwarding system. Once a connection is established between clients, both clients will open a local service port for the service on their computer. For example, if client A wants to connect to Apache on client B and a connection between the clients has been established, client A will have a local port on their computer that they can connect to in order to access Apache on client B. This works by forwarding any traffic client A receives on this 'service port' and forwarding it across the established tunnel to client B, which client B then forwards onto Apache. Since we control the forwarding process on both computers, we can do whatever we'd like to the data between the computers, including encrypting it so that the traffic is much more difficult to identify.

Figure 3 Forwarding System

4.5 The Overall Connection Process

The server accepts new connections, informs clients what services are being offered by what clients, accepts requests from clients to connect to a service, and coordinates NAT punching.

Figure 4 Connection Process

4.6 Graphical User Interface (GUI)

The GUI for NetTunnel needed to be something that users would be immediately familiar with, but allow them to access NetTunnel specific features easily and quickly. In order to serve both these goals we based our design on that of an internet relay chat (IRC) client. Like a traditional IRC client, a large amount of the screen is devoted to chat history, while a list of users appears on the right side of the history window. When you click on a user name, a list of services that user is sharing appears below the user list. A services drop down menu lets you get to the full services menu or quickly enable/disable sharing of specific services. The services window again shows a list of all services and lets you enable and disable them, but also provides access for adding, editing, or removing individual services.

Figure 5 Main Window

Figure 6 Services Window

5. Analysis of Results
The proposed solution works as intended. We were able to make a prototype implementation in which one client was able to successfully connect to an Apache server hosted by another client. Unfortunately, due to time constraints, only our prototype implementation was working when this paper was written. The prototype used in our tests was programmed to work for Apache between two clients and therefore tells us little about a 'real world' usage of NetTunnel. However, based on inspection of the protocol, the following problems are apparent: Clients have to open a new port for each service's port for each client that wishes to connect to it. For example, if some service needed both port 80 and port 81, and three clients wished to connect to it, the client hosting the service needs to open six separate ports to accomplish the share with all clients connecting. So, the current protocol doesn't scale well for services with lots of ports or when lots of clients want access to the same service. In the current implementation, only one socket can be associated with each tunnel. This prevents, for example, a web browser from opening multiple connections to Apache (which most browsers do on every website to retrieve images concurrently, etc). Because of the forwarding system, services will always see incoming connections as from the localhost. The effects this has will vary according to how the service is programmed. Apache shouldn't have any trouble with this, but a game server might not allow more than one connection per host, meaning only one client can have a working tunnel. Because of the forwarding system, users connecting to a service will have to connect to their localhost, which might be confusing to some users or hard to setup in certain applications. Browsers can handle this fine, except for the annoyance of having to add a port to the URL, but other applications might not allow connections to a localhost or on a custom port.

6. Conclusion 6.1 Summary

In this paper, we presented one of the major problems when using a NAT device and proposed a solution. We implemented our proposed solution in a prototype using a combination of existing technologies. Last, we analyzed the result from the prototype and hypothesized about some potential problems in our implementation.

6.2 Future Plans

We plan to continue work on NetTunnel and will hopefully see it through to a full release. There are many different possibilities to explore in order to try to get around the problems listed in Section Five, which should make NetTunnel more appealing to end users. We would also like to add Universal Plug and Play (UPnP) functionality into NetTunnel, so that service hosts on less restrictive networks will be able to get clients to join their server without requiring the clients to be running NetTunnel as well.

7. References
[1] Protobuf-net by Marc Gravell, used for data serialization over network - http://code.google.com/p/protobuf-net/ [2] Network Address Translation, Wikipedia -- http://en.wikipedia.org/wiki/NAT