content_image/427639.jpg
nication with the VPN server and full tunnel gateway. In a P2P VPN, “control” messages consists of communi- cation between Using full tunneling ensures that a mali- cious user cannot easily eavesdrop into what would oth- erwise be public communication by forwarding all non- VPN related traffic securely to a third party who resides in a more trusted environment. There are two key com- ponents to this scheme, a gateway / server or traffic re- layer and a client or a traffic forwarder. In the following sections, we present methods for implementing gateways and clients. 

## 4.3.1 The Gateway 

Configuring a machine as a gateway can be done with NAT software or using IPOP’s built-in NAT stack. For example, in Linux this is possible through masquerad- ing in iptables, which automatically handles forwarding packets received on one interface to the next hop as well as receiving packets from the Internet and forwarding them back to the appropriate client, transparently taking care of NAT. 

With a gateway intact, the VPN software can now an- nounce that it provides full tunneling. For that purpose, we added an enable flag into the VPN configuration to specify that a machine is a full tunnel gateway. When the VPN software starts, it will automatically append it- self to the list of known gateways for the VPN group in the DHT. 

The only remaining difference in VPN gateway is the state machine used in processing packets coming from the VPN. Rather than rejecting packets if the destination is not in the VPN subnet, they are only rejected if gate- way mode is disabled. If it is enabled, all Internet packets are written to the TAP device with the destination Ether- net address being that of the TAP device. The remaining configuration is identical to other members of the system as packets from the Internet to the client will automati- cally have the clients IP as the destination as a product of the NAT. 

## 4.3.2 The Client 

VPN Clients wishing to use full tunnel must redirect their default traffic to their VN device. In our VPN model, we use a virtual address for the purpose of provid- ing distributed VN services DHCP and DNS. This same address can be used as the VPN gateway, which works fine because as shown in Figure 3, only the Ethernet header contains information about the gateway. Packets retrieved in the VPN software can then forward the In- ternet packet to any machine in the VPN, providing gate- way services without changing IP or higher OSI layer changes. 

The VPN’s state machine has to be slightly modified to handle outgoing packets not destined for a remote VPN end point. Incoming packets destined for a subnet out- 

side of the VPN address space are rejected, unless full tunnel client mode is enabled. If it is enabled, the VPN software finds a remote peer to act as a full tunnel gate- way and then sends the packet to the remote peer. 

<img src='content_image/427639.jpg'>

The pathway for packets coming from the overlay needs to support full tunneling. The source IP address will not match the VPN gateways IP but will be an Inter- net address. Thus the VPN client must confirm that the source is a VPN gateway, otherwise the packet is thrown away. Upon writing a packet to the VN device, the user application will receive a packet from the Internet. 

This leads to two issues: how to select the machine to use as a gateway and how to configure a network stack to properly route packets and not direct all packets to the VPN gateway. Our model uses a simple mechanism for determining which gateway to choose: query the DHT for a list of potential gateways, select a random one from the list, and verify liveness via periodic ping messages. For handling faults, we take a pessimistic approach, that is, if a server is lost, we take note of it and only query the DHT again upon the next outgoing Internet packet. 

In this paper, we focus on the second issue: handling P2P-routed packets. In the centralized VPN case, a client communicates directly with a single point in the VPN, which is known ahead of time and can be implemented by a simple routing rule swap prior to starting the VPN. The same cannot be done for a P2P system. Due to the dynamic, self-configuring nature of P2P systems, en- suring that all P2P overlay messages are routed directly becomes a non-trivial issue as there will be many such routes, most of which will not be known ahead of time. If we applied the same model used by centralized VPNs, the client would end up routing both Internet and P2P traffic through the gateway machine, creating a central point of failure. We have considered two approaches, as outlined below. 

## 4.3.3 The Client – Approach 1 – Adding Routes 

The first approach is similar to the centralized version: for each P2P link, we add an explicit rule in the rout- ing table so that packets destined for those endpoints are routed directly to them via the LAN’s default gateway. In order to ensure this, we added a feature to the socket han- dling code that would, prior to the first outgoing packet, indirectly add a routing rule to direct packets for the re- 

