mote node’s public address to the LAN gateway. The rule would remain in effect until the VPN closed down or the link was closed. This model requires unique code for each OS platform; though supporting Linux and Win- dows was quite trivial. Because outgoing packets bear the source address of the physical network, incoming packets will be delivered normally. This method has two major shortcomings. Common to all VPNs that employ the standard route switch tech- nique, all communication, not just VPN, is routed di- rectly to the server insecurely. So while the VPN traffic is most likely encrypted, a website hosted by the server might not be. Another issue that arises in the P2P case is that malicious users can send spoofed initiation packets which will add extra routes to the routing table, resulting in a similar situation as the first, unencrypted commu- nication visible to eavesdroppers. This led to a second approach described below. This solution attempts to solve the problem introduced by the first solution, removing any potential for eaves- dropping. In this solution all Internet packets with no exception are directed to the VN device. The VN is then responsible for filtering P2P traffic, encapsulating them into Ethernet packets, and sending to the LAN’s gateway. In the VPN application, Incoming IP packets’ source ports are compared to VPN application’s source ports. Upon a match, the VPN application must direct it to the LAN’s gateway. The three steps involved in this process are 1) translating the source IP address to match the phys- ical Ethernet’s IP address, 2) encapsulating the IP packet in an Ethernet packet whose source is a random address as described in [41] and destination is the LAN’s gate- way, and 3) sending the packet via the physical Ethernet device. The IP swap is required or the gateway will not route the packet properly. The issue of sending the Eth- ernet packet is not trivial as Windows lacks support this operation. Our platform independent solution uses a sec- ond TAP device bridged to the physical Ethernet device, allowing Ethernet packets to be sent indirectly through the Ethernet device via the TAP device. This solution currently only works for UDP packets, because all in- coming packets will be directed towards the bridge and not the faked Ethernet address. TCP packets will send a TCP reset in this environment. All other packets enter the system same as before. This method has been verified to work on both Linux and Windows using OS dependent TAP devices and bridge utilities. While this method effectively resolves the lingering problem of ensuring that all packets in a full tunnel will be secure, it raises a couple of issues 1) could the ef- fect of having all packets traverse the VPN application be prohibitively expensive and 2) why not have the P2P application write LAN destined Ethernet packets directly avoiding the VPN client. The cost of passing all packets through the VPN application is negligible, as shown in Section 5.4, since they are destined for the wide area, where the time to traverse the network will be orders of magnitude larger than passing through the VPN’s packet processor. Adding an Ethernet writer to the P2P system creates an unclean abstraction as a VPN portion of the system now becomes library dependent and reduces VPN software portability. When NAT traversal using STUN [33] fails or there are other connectivity issues some P2P VPNs [26, 25] support relaying, similar to Traversal Using Relay NAT (TURN) [32] provided by a managed relay infrastruc- ture. Centralized and decentralized VPNs do not suffer from this problem as all traffic passes through the central server or managed links. To address the management and overhead concerns in these systems, we propose the use of distributed, autonomic relaying system based upon previous work [17, 29]. Our previous work involved the use of triangular routing that allowed peers next to each other in the node ID space to communicate despite be- ing unable to communicate directly because of firewall, NAT, or Internet fragmentation issues. The process for forming local relays or ”tunnels” [17] begins with two nodes discovering each other via ex- isting peers and determining the need to be connected. If a direct connection attempt fails, the peers exchange neighbor sets through the overlay. Upon receiving this list, the two peers use the overlap in the neighbor sets to form a two-hop connection. In this work, we further ex- tend this model to support cases when nodes do not have an overlap set. This involves having the peers connect to each other’s neighbor set proactively creating overlap, as represented in Figure 4. Additionally, we added the feature to exchange arbi- trary information along with the neighbor list. So far we have implemented systems that pass information about node stability (measured by the age of a connection) and proximity (based upon ping latency to neighbors). Ad- ditionally, when overlap changes, we make it optional to select to use only a subset of the overlap, thus only the fastest or most stable overlap is used with many more in reserve. To verify the usefulness of two-hop over overlay rout- ing, we performed experiments and share the results in Section 5.1. In a live system, we verify the accuracy and usefulness of our latency-based relay selection algorithm in Section 5.2. In this section, we evaluate our proposed P2P VPN as described in Section 4 implementing the features into 5 Evaluation of VPN Models 4.3.4 The Client – Approach 2 – Ethernet Frames 4.4 Autonomic Relays 8