CA2531678A1 - Method and system for facilitating client computer communications - Google Patents

Abstract

A method and apparatus for facilitating communication between client computers is provided.
The method provides for the use of ping probing by a server to determine the types of NAT
devices and/or firewalls protecting the client computers. Once these are determined, the server can predict the response to communications from the client computers and instruct the client computers to contact each other. Once a session or tunnel is established it can be maintained through the use of a ghost flag, even if contact with the server is lost..

Description

METHOD AND SYSTEM FOR FACILITATING CLIENT COMPUTER
COMMUNICATIONS
Field of the Invention The invention applies to the field of computer networking, and more particularly to virtual private networking; network traffic tunnelling; and network traffic relaying.

Background of the Invention NAT and Firewalls The Internet and the core Internet Protocol ("IP") have become the ubiquitous format used by modern computer communication systems. The IP provides for network node addressing, IP
datagram routing and delivery services. IP also forms a foundation for more elaborate communication services, such as those implemented by Transmission Control Protocol ("TCP") and User Datagram Protocol ("UDP"). There are two major versions of IP, version 4 and version 6. The IP version referred to in this document is IP version 4, although the invention described herein may be adapted to other versions.

Internet nodes are identified by their IP network addresses. An IP network address is assigned to every node that participates in a network communication. This address has 32 bits and is commonly represented in a form of 4 octets separated by dots, for example 134.10.210.97.
Every network packet sent over IP network includes the IP address of both the source and the destination. In addition, the packet may include both source and destination port numbers.
Therefore, if the IP address identifies the computer on the network, the port identifies the particular program on the computer, for example, if the computer is running both a Web server and Email server, another computer may use port number 80 to direct a Web packet to the Web server and port number 25 to direct Email data to the Email server.

DM VAN/260461-00001/6279099.1 The Internet, currently comprised of billions of computers, has grown substantially in the last few years and the number of available IP addresses is diminishing, to the point where there is a shortage of available IP addresses. Faced with this shortage, organizations and individuals frequently opt to share a single Internet IP address between two or more computers. The technology to use this sharing is called Network Address Translation ("NAT").

NAT allows multiple computers to share a single IP address. NAT operates by placing multiple computers on an internal network, assigning each computer a "private" IP
address that is unique only within the internal network and configures them to access the Internet via a NAT device.
The term NAT device, as used in this document, refers to devices, including firewalls, that dynamically modify the IP addresses found in IP packets sent by the computers in an internal network to make it appear that the internal computers are accessing the Internet from their shared address (and not the private IP address used in internal network). The NAT
device may also modify port numbers if at some point more than one computer on the internal network uses the same local port number when sending packets to the Internet. The NAT device stores or "remembers" how it modifies outgoing packets, so it is capable of uniquely identifying an internal computer when it receives a packet in response from the Internet. The NAT device then reverses the changes and forwards the packet to the appropriate computer on the internal network.

A default NAT configuration may cause a number of problems. For example, a computer using a NAT device (referred to as an "internal computer") may be difficult to access from the outside (i.e. the rest of the Internet). This is because a computer on the Internet cannot address an internal computer unless it first receives some traffic from latter, meaning that internal computers cannot act as servers. Furthermore two computers, each using a different NAT
device, cannot communicate with each other because neither will receive new connections from computers outside of their respective internal networks.

Firewalls DM VAN/260461-00001/6279099.1 As computers with Internet connections are vulnerable to virus infections and other attacks, it is considered good practice to implement network access control for such computers. This practice is driven by the rise of computer viruses, privacy issues and general need for network security.
The access control is enforced by firewalls, which can be a standalone hardware device or implemented as software.

Firewalls protect a computer against dangers on the Internet. Firewalls monitor all packets that are sent from or to the protected computer(s) and filter out those portions of packets that violate the applicable firewalling policy. Most commonly such policy is set to allow all packets (also referred to as "traffic") to be sent from the computers to the Internet, but only permit return traffic to the computer that is related to packets previously sent out. This process is known as stateful firewalling as the firewall is required to remember the state of the computer(s) activities to determine if traffic is permitted to reach the computer.

Firewalls may present obstacles in Internet communications. Computers protected by a firewall may be difficult to communicate with from outside the firewall even when such accessibility is desired by the protected computer. In order for the computer behind a typically configured stateful firewall to accept a connection from an outside computer (for example, to act as a server), the firewall configuration needs to be adjusted for that particular computer. This can be a major inconvenience if there are several computers protected by the firewall and their need to establish communications outside the firewall change frequently.

Given the above, NAT devices, including firewalls, may restrict network connectivity in circumstances where such connectivity is desired. Working around these restrictions requires reconfiguration of the NAT devices and firewalls on an "as needed" basis, which is frequently not a viable option.

Virtual Private Networks DM VAN/260461-00001/6279099.1 A virtual private network ("VPN") is a secure virtual (as opposed to physical) network. The IP
addresses used in a VPN may be independent from those used for Internet communications.
Virtual private networks are used to create a private communication environment for computers that may not be in the same physical location. A VPN setup typically uses existing public network infrastructure, such as the Internet, for carrying data between VPN
members. For example, VPNs can be used for building a large intra-company network that spans multiple offices. Computers within a VPN are referred to as "members". The configuration of a VPN
can be very complex and time consuming and may require superior knowledge of networking and security.

A VPN used in association with NAT can present particular difficulties. The protocols used to implement VPNs include IPsec protocols, various tunnelling protocols (L2TP, PPP, etc) and application level protocols like SSL and SSH. Early versions of IPsec protocols did not work with NAT at all, but recent extensions, while usable with NAT, lack flexibility and are difficult to setup.

VPN connections (also known as tunnels) cannot be established towards a computer using a NAT device, they can only be initiated by such computers. Such tunnels also cannot be established between two computers, each using a NAT device unless at least one of the NAT
devices is configured explicitly for this purpose.

UDP "Hole Punching"

There are several techniques available to overcome the above-described problems. For example, external access to a computer residing behind a NAT device may be provided by using port forwarding. This requires the NAT device be configured to associate a particular Internet II' address and/or port number with a specific internal computer. All traffic that the NAT device receives from the Internet for this IP address/port is then forwarded to the specific internal computer. There are two drawbacks to this approach, namely that it is technically complex; and not all types of traffic can traverse a NAT device in this manner.

DM VAN/260461-00001/6279099.1 An alternative solution in the art, is known as "UDP hole punching". UDP hole punching works as follows:

1. an internal computer sends out an initial UDP packet to an Internet computer;
2. the NAT device sends the packet out to the Internet computer and associates the source UDP port in the packet with the internal computer; and 3. the NAT device then instructs an Internet computer to send a packet to the internal computer by directing the UDP packet to the source UDP port.

This process provides inbound UDP connectivity with all Internet computers by sending a "hole punching" packets to an Internet computer. This process is based on a number of assumptions about NAT behaviour, which often do not hold true for NAT devices. For example, NAT
devices implement different strategies for selecting an external (also known as "mapped") port when sending traffic out. Some NAT devices use different port values depending on the destination IP/port (also referred to as "non identity preserving NAT").
Therefore, the system, as described above, can be made to statistically work in approximately 80% of all cases where it can be applied, which results in an unacceptably high failure rate.

An alternate solution in the art is to cause the internal computer to establish communications with an Internet computer, which then can relay traffic between internal computers are in communication with it. This approach has two major drawbacks: it introduces latency in the communications; and it results in substantial bandwidth expense at the relay Internet computer.
Other ways of solving the VPN and NAT problem include:

= using ad-hoc VPN systems that are limited to setting up tunnels towards computers not using a NAT device. This solution means that a computer cannot establish the DM VAN/260461-00001/6279099.1 tunnel towards a computer using a NAT device, but must wait for that computer to initiate the tunnel;

= some NAT devices support a VPN passthrough option, typically limited to allowing one internal computer using the NAT device to receive VPN connections from outside;

= centrally-managed VPN systems may include VPN management software, which establishes and maintains connections to all VPN members and can command such members to perform certain actions. In particular the management software can instruct a VPN member using a NAT device to initiate a tunnel towards another member when the latter requires it. This resolves the problem of ad-hoc VPNs, but does not address tunnelling between two computers, both using NAT devices; and = centrally-managed relayed VPN systems may include a software component known as a concentrator, which maintains tunnels to VPN members and may forward traffic to computers using the tunnels. This solution solves the problem of connecting two computers, both using NAT devices, however two drawbacks include extra latency and substantial bandwidth expense for the concentrator.

It should be noted that there is no prior art VPN solution using "UDP hole punching" to establish direct low-latency tunnels between VPN members protected by NAT devices.

Summary of the Invention The invention described herein is a zero-configuration virtual private networking system. It resolves typical VPN setup problems as follows:

= it provides for the presence of NAT devices and stateful firewalls, without requiring NAT/firewall reconfiguration;

DM VAN/260461-00001/6279099.1 = it establishes direct tunnels between members of a VPN (using extensions of UDP
hole punching technique), thereby providing fast communication between such members;

= it transparently switches to passing traffic via relays when direct tunnelling is not possible, thereby providing connectivity between any computers with Internet access;

= it uses virtual network adaptors to avoid complications caused by NAT
breaking up network traffic;

= it uses single private IP address space between all VPN members to avoid address collisions and routing ambiguities, thereby not requiring computer reconfiguration; and = it handles network broadcasts between VPN members to fully emulate a LAN
environment, thereby allowing standard LAN applications work over the VPN.
The system and method according to the invention simplifies virtual private network setup and enables people with no or minimum experience in computer networking to perform this operation. Furthermore, the system and method according to the invention improves and extends UDP hole punching technology such that the chances of successfully connecting two computers, each using a NAT device, increases from about 80% to approximately 95%.

A method for a server to provide connectivity between a first client computer and a second client computer is provided, the method comprising: (a) the server issuing a first relay number ID to said first client computer and a relay and a second relay number ID to said second client computer and said relay; (b) said first and second computer setting up a UDP
based relay connection; (c) said first and second computers setting up a SSL based relay connection; (d) said first and second computers setting up a HTTP based relay connection; (e) said first and second computers measuring the round trip time for each of said UDP based connection, said SSL based connection and said HTTP based connection; and (f) said server selecting a connection of said UDP based relay connection, said SSL based relay connection and said HTTP
based connection DM VAN/260461-00001/6279099.1 based on predetermined criteria, and terminating the other connections. The predetermined criteria may include the lowest round trip time of said UDP based relay connection, said SSL
based relay connection and said HTTP based relay connection.

A method of maintaining sessions between a first client computer and a second client computer when a server fails to receive a notification packet from the first computer is provided, comprising the steps of: a) the server sending a notification to said second computer that said first computer is offline and notifying said second computer if the first computer's termination was expected; b) if the first computer's termination was not expected, said second client computer maintaining said session and periodically transmitting a probe to said first client computer; and c) if said first client computer responds to said probe, said first client computer and said second client computer maintaining said session.

A method of establishing a virtual private network between a first client computer and a second client computer, comprising the steps of: a) providing a public and private key for a server, said server providing said server public key to the first client computer and the second client computer; b) said first client computer transmitting a packet to a virtual IP address associated with said second client computer, said packet sent by a tunnelling program to a physical IP address associated with said second client computer; and c) a virtual adaptor receiving said packet and sending said packet to said second client computer.

A method for a server to determine the presence and type of a first NAT device protecting a first client computer having a first IP address, and a second NAT
device protecting a second client computer having a second IP address, said first and second client computers having respective first and second IP addresses is provided, comprising the steps of:
a) the server transmitting a first packet to the first client computer; said first packet including a first source IP
address and port; the second IP address and a datum; b) the first client computer transmitting a second packet to said second IP address, said second packet including said datum; c) the second client computer transmitting a third packet to the server, said third packet including a source address from said third packet and said datum; and d) said server comparing said first IP address and said source address from said third packet and determining the type of said first NAT device.
DM VAN/260461-00001/6279099.1 A method for a server to hole punch through a NAT device protecting a client computer, the NAT device not an identity-preserving NAT device is provided, comprising the steps of: (a) said server instructing said client computer to send first, second and third packets using a set of IP
address and port values; (b) said server analyzing fourth, fifth and sixth packets received as reflections of said first second and third packets; (c) said server predicting the which external port to be used by said client computer when initiating communications with a second client computer; (d) said server instructing said first client computer to communicate with said second computer; and (e) said server confirming that a tunnel is in place within said first client computer and said second client computer. The tunnel may be a VPN between said first client computer and said second client computer.

Description of the Figures Figure 1 is a block diagram showing a computer protected by a NAT device;
Figure 2 is a block diagram showing a hole punching process;

Figure 3 is a further view thereof; and Figure 4 is a block diagram showing the ping probing process.
Description of the Invention The system and method according to the invention is a virtual private networking system that uses traditional VPNs, assisted NAT traversal (also known as 'UDP hole punching'), proxy traversal (also known as 'HTTP and SSL tunnelling') and/or relays.

The method and system includes a modification of the existing 'UDP hole punching' technique that significantly improves it effectiveness; the combination of the above technique with UDP
and TCP relaying techniques to provide connectivity between most computers with Internet access; the client presence tracking framework for a server, client computers and relays; and the DMV A N/260461-00001 /6279099.1 combination of above with virtual private networking providing for zero-configuration virtual private networking.

Standard UDP hole punching As seen in Figure 1, client computer A is using NAT device N to access the Internet. Client computers are conventional computers having a processor, read only and random access memory, input means and output means. In this application, the term "client computer" will encompass any computer with access to a wide area network, and also a program operating on such a computer. Such a computer may, but need not, operate on a local area network, and may perform the functions of a server on the wide area network. The computers communicate with each other and the Internet and NAT devices and firewalls via modems, T 1 lines, ADSL and the like. In the example shown client computer A has an IP address of 10Ø0.17, although other IP
addresses may be used.

NAT device N allows client computer A access to the Internet. NAT device N is shown as having an external IP address of 129Ø0.33, although other IP addresses may be used.

As seen in Figure 2, a program on client computer A allocates a local UDP port and uses it to send a UDP packet to server S. This local UDP port is known as client computer A's internal port. In Figure 2, the internal port is designated as 6712.

When the packet arrives at server S, its source IP address is set to NAT
Device N's external IP
address and the source port of the packet may or may not be client's computer A's port. This port is referred to herein as A's external port.

Standard UDP hole punching technique requires that the value of an external port depends solely on the source address and the source port designated in the packet. Therefore if client computer A uses the same internal port to send the packet to an Internet computer other than server S, NAT Device N will designate the same external port it used when sending packets to server S.
NAT devices of this type are sometimes referred to as identity-preserving.

DM VAN/260461-00001/6279099.1 Using this method, as seen in Figure 3, any Internet computer (for example, client computer B) should be able to address a packet to a program on client computer A by sending a UDP packet to the external port designated by NAT device N.

In standard UDP hole punching NAT device N may or may not allow this 'unsolicited' access.
Typically, NAT device N inspects where such inbound packet comes from and compares its source IP address (e.g. client computer B's IP address) to the list of those IP addresses to which client computer A has actually sent packets.

In such situations, server S can act as a mediator connecting client computer A to client computer B. In such a case, first, client computer A and client computer B
each send a UDP
packet to server S, so that server S obtains their external ports. Next, server S sends client computer B's external IP address and port to client computer A and client computer A's external IP address and port to client computer B. Then, client computer A sends a packet to client computer B and thus creates a proper entry in NAT Device N's connection list.
Client computer A is thereby said to punch a hole in NAT Device N. After these steps, client computer B is able to transmit packets to client computer A using client computer A's external port.

The above described technique can be used when both client computer A and client computer B
are behind different NAT devices. In such a case, the sequence of steps includes client computer B sending a packet to client computer A. Depending on the timing of client computer A's and client computer B's transmissions, either packet or both packets may be rejected by a NAT
device or may be delivered to its intended recipient. These are disposable packets used for punching a hole and their loss is expected.

According to some statistics, the above approach is successful in about 80% of all cases where both peers (client computer A and client computer B) can send UDP packets to Internet hosts.
Furthermore, this technique can be used to connect computers behind stateful firewalls that are configured for unrestricted outbound UDP and permit related inbound traffic.

DM VAN/260461-00001/6279099.1 Improved UDP hole punching The method and system according to the invention extends traditional UDP hole punching to support NAT types that are not identity-preserving. An initial discovery process is used to determine the presence and type of NAT or firewalling device being used by the client computers.

This method according to the invention is further referred to herein as assisted NAT and firewall traversal ("ANFT"). An ANFT server is a Internet accessible computer that clients using ANFT
use to assist in transmitting packets to each other.

ANFT uses a packet exchange method referred to herein as ping probing, described below.

Ping probing includes three transmissions, as seen in Figure 4. In the first transmission, server S
transmits a packet, referred to herein as a ping request packet to client computer A. The ping request packet contains the address of client computer B and some data. The ping request packet is sent via TCP or UDP. The next transmission is client computer A sending a packet, referred to as a ping packet, to the address (client computer B's address) and with the payload (data) specified in the ping request packet. The ping packet is sent via UDP. The third transmission is client computer B sending a packet, referred to as a ping reflection packet, to server S. The ping reflection packet contains the source address of client computer A as determined by client computer B using the ping packet and the data from the ping packet. The ping reflection packet is sent via TCP or UDP.

Server S uses this exchange to learn the state of the port mappings on the NAT
devices in front of client computer A and/or to verify that client computer B is reachable from client computer A
at a certain IP address and port.

ANFT uses two parameters to categorize a client computer's type of Internet access, referred to herein as the mapping algorithm and the firewall type. The mapping algorithm of the client DM VAN/260461-00001/6279099.1 computer (or its NAT device) is categorized as static, port_n, port_burst, port_random and addr random. Two boolean flags, referred to as per_ip and delayed, are also used, as is a variable known as step value.

Static type means that external port number used by a client computer depends only on internal address and port number. An identity-preserving type of NAT device would be in this category (or the case where no NAT is used at all).

Port n means that external port used changes in fixed increments (n) of one or more for each new destination IP address and port.

Port burst means that the external port used changes in random increments that are bound by a fairly small value (for example, an upper bound of twenty).

Port random means that the external port used is selected randomly for each new session.

Addr random means that both the external port and IP address are changed for each new session.
The manner in which the change is made is irrelevant. This usually indicates a presence of a load-balancing NAT device.

Per ip flag applies to port_n and port_burst types and indicates if the external port depends on only the destination address (indicated as one or true) or both an address and the port value (indicated as zero or false).

Delayed flag applies to port_n and port burst types and indicates if the external port overloading process applies to all sessions originating from a given source port (indicated as zero or false) or only to the second and following source ports (indicated as one or true).

Step value defines the port change value for port_n type and the range of the burst for port_burst type. This value may be negative meaning that port value is decreasing with usage.

DM VAN/260461-00001/6279099.1 Firewall types are categorized as either open or stateful and these categories are applicable in the case of static mapping algorithms (and occasionally port n algorithms).
The firewall type is categorized as open if a computer can send a UDP packet to the external port and it will be delivered to the appropriate computer. The firewall type is categorized as stateful if only computers previously contacted by the computer using the firewall may communicate with the protected computer via the external port.

ANFT may be used for communications between computers with the combinations of client mapping/firewall types as shown in Table 1.

I ort_random addr_random - --- j stauc.open static.stateful ~ - port_n port_burst p -static.open yes yes yes yes yes yes static.stateful yes yes yes yes -_ - -__ j --_ -_ _- _ . _-- - -- ~
port_n yes yes yes port_burst yes yes _--port_random yes 4 addr-random II yes - -I ---- - -- -Shaded items indicate combinations that are not supported by standard UDP hole punching.
Server S uses 'ping probing' as previously described to determine the categories of the NAT
device andlor firewall of the client computers. In a typical discovery phase (in which the categories of a client computer are determined), the following process occurs:

The discovery is performed by server S sending a batch of three ping requests to the client computer. The address field in these requests is set as follows:

1 s' ping request - IP address-1, Port 1 2n'l ping request - IP address-2, Port 2 3rd ping request - IP-address-1, Port_3 DM VAN/260461-00001/6279099.1 where I:P_address_* are the addresses of the ping targets that communicate the ping reflections to server S. By comparing the information contained in the ping reflections received by server S, the client computer's NAT device and/or firewall can be categorized.

Preparing a connection setup between two client computers using ANFT includes three steps:
discovery, prediction and confirmation.

Discovery is the first step in preparing the connection setup using the ANFT
method. As described previously, the server instructs the client computer to execute ping probing using a set of IP address/port values. The server then analyzes the source addresses from the ping reflections received and determines the appropriate mapping type category as described previously.

If the client computer's mapping type is categorized as static, the server then checks the type of the firewall by sending a ping packet to the client computer from an IP
address and port not previously used for communicating with the client computer. If the client computer sends a ping reflection packet back, the NAT/firewall is categorized as an open type, otherwise it is categorized as stateful.

The discovery process may include multiple rounds of ping probing to compensate for the presence of lossy connections. The server also determines the client computer's internal address and port during the discovery process; these are used to differentiate between a client computer using a static NAT device and a client computer without a NAT device. Internal address/ports are also used to detect and handle the case of two client computers behind the same NAT device.
The prediction process works by the server predicting which external port a client computer will use when it initiates communications with another client computer. If the external port can be predicted with a high degree of accuracy, then the client computers may be instructed to contact each other and be able to communicate directly.

The server predicts ports by looking at the category of the client computer's mapping type. The port can be predicted for static and port_n types, and the range of ports can be guessed for DM VAN/260461-00001/6279099.1 port_burst type. Port prediction involves executing ping probing to learn the current port mapping state of NAT device.

Depending on the combination of client computer types, it may be sufficient to predict a port for just one client computer or alternatively, predicting ports on both client computers may be required.

The confirmation step is used to activate the tunnel between the client computers using the predicted ports and to verify that the tunnel operates in both directions.

The server uses ping probing packets to instruct one or both client computers to communicate with the other, either sequentially or simultaneously. It then observes the source information in the ping reflection packets to validate the prediction and confirm the tunnel between the clients.
The server may also use short time-to-live (TTL) ping packets to create the required mappings in a NAT device, and also to ensure that the packets used for this purpose do not reach another client's NAT device.

Once this step is complete, the server either determines the tunnel is operational or that the tunnel is not setup. In the first case the client computers are provided with the other's predicted external IP/port addresses and they may immediately start exchanging data through the tunnel.
When client-to-client tunnelling unavailable The method and system according to the invention also allows the use of ANFT
with HTTP, SSL
and UDP based network relaying to provide connectivity when direct client-to-client tunnelling is unavailable. Such cases include: client computers having no UDP access;
client computers in lossy UDP environments; and, client computers in combinations not provided for by ANFT (as seen in Table 1).

UDP-based relaying is a process whereby a server instructs a pair of client computers to communicate with each other using UDP protocol via a relay. A relay is a networked computer controlled by the server. with the purpose of handling client-to-client traffic, i.e. they receive packets from one client computer, and immediately forward them to another. The server issues DM VAN/2 6046 1-0000 1 /6 279099.1 each client computers a unique relaying ID number, which the client computer must include in every packet sent out. The server also sends these relaying ID numbers to the relay, and the relay will start forwarding the traffic tagged with one of the relaying ID
numbers to the client computer that is identified with the other relaying ID number. In other words the relay will relay traffic between the clients.

SSL-based relaying is similar in principle and involves the client computers setting up SSL/TLS
connections to the relay and using these for exchanging the data between each other.
HTTP-based relaying is again similar and it involves client computers setting up a pair of HTTP
connections each to the relay, and using one of the connections for sending data, and another for receiving data.

When ANFT fails, the server then tries to setup UDP relaying first, SSL
relaying next and HTTP
relaying last. When there is more than one of the UDP, SSL and HTTP based relaying is successful, the server will instruct the client computers to measure RTT
(round-trip-time) for each type of relaying. The server then selects one relay based on various criteria or their combination, including lowest cumulative RTT, and lightest load. The server may periodically re-select the relay for the client computers in response to changes in the relay availability, responsiveness and load.

Server Sessions A presence tracking framework is an arrangement between the server and the client computers that involves the client computers establishing sessions with the server to use the server's services. A client computer that has an established server session is categorized as online, otherwise it is categorized as offline.

The sessions are managed via session control protocol, which runs over the reliable datagram in-order delivery protocol. It may be a message framing protocol run over TCP
or a reliability protocol added on top of UDP.

The server expects to periodically receive small "keep alive" packets from client computers if the session is left idle for some time. Client computers that fail to keep their session alive are DM VAN/260461-00001/6279099.1 categorized by the server as in an offline state and their sessions terminated. Also, if the server fails to communicate a message to the client computer, the client computer will be set to offline.
The server also keeps track of all client computer pairs that have established tunnels with each other.

A client computer is expected to explicitly notify the server by using a logout message when the client computer is about to terminate the session. The server then can terminate the control connection and the client computer is moved into offline mode.

When the client is moved into the offline mode, the server sends a notification to all other client computers that presently have tunnels with now offline client. This notification includes information as to whether the client sent the usual logout message or if the session was terminated unexpectedly (e.g. because the server did not receive the "keep alive" packets). If the session was terminated unexpectedly, a ghost flag is set.

When a client computer receives a notification from the server that the other client computer with whom the tunnel had been established is offline and the ghost flag is not set, that client computer removes the tunnel towards the now offline client.

If the ghost flag is set, the client computer receiving the notification keeps the tunnel open and periodically checks it by sending probes to the offline client computer. If the offline client computer does not reply in timely manner, the tunnel is declared dead and removed. However if the offline client computer replies, it indicates the presence of a transient connectivity problem on the route between the offline client computer and the server, which led to the connectivity loss.

When a client computer unexpectedly loses a connection to the server, it starts sending "keep alive" packets through all of its tunnels. This activity compliments the behaviour of the client computers that receive a notification with a ghost flag set, and therefore they are preferably able to maintain their connectivity with the other client computer. The server need no longer play a role until both client computers are again online.

DM_VAN/260461-00001/6279099.1 The mechanism of ghost clients allows client computers to retain the client-to-client connectivity in the event of a server connection loss. The loss may be limited to a single connection to the server, or for all connections to the server, for example, if the server is being restarted.

Virtual Private Networking The method and system according to the invention can be used with a virtual private networking mechanism to implement a zero-configuration virtual private networking system.
The system includes a server, client computers and relays.

The server is responsible for the ANFT process, client presence tracking, client authentication, client grouping and client configuration. The client computers are responsible for emulating a LAN like environment on an end-user machine, communicating with the server and tunnelling VPN traffic to/from other client computers through the virtual networks. The relay is responsible for assisting the client computers communicate in scenarios where the ANFT process fails to establish direct tunnels.

When the server is initially configured, a cryptographic identity is generated for it and the public portion (public key) is distributed to each client. A virtual IP range is also selected so the virtual IP numbers do not overlap with any existing IP addresses any client computer may already have.
When the client computer is initially configured, it also generates a cryptographic identity. It then establishes a control session with the server, secures it using cryptography, authenticates the server and submits its public identity (public key) for registration. In return the server allocates a virtual IP address for the client computer and sends it to the client computer. The virtual IP
address/cryptographic identity pair becomes part of the client computer's login information.

Once the client has obtained the virtual IP address, it uses it to configure a virtual network adapter. The virtual network adapter is an operating system component that appears as a physical network card to the system, but does not correspond to any actual hardware. Instead all traffic sent by the system to this adapter is forwarded to an application process. This process then inspects the traffic and either drops it (discards it) or forwards it to the other VPN
member(s) via the tunnel(s). The process may also send replies to system requests such as those carried by DHCP and ARP protocols.

DM VAN/260461-00001/6279099.1 When a client computer receives VPN traffic through a tunnel, the client again validates it (a client expects to receive raw network packets, although other types of packets may be sent, through the tunnel and since a peer client computer may send anything, whatever is received through the tunnel must be verified to determine it is a valid properly addressed network packet) and then 'injects' the packet into the virtual network adapter, making it appear to the system as if this traffic was received by the client computer from a real physical wire.
The traffic then undergoes regular processing.

Therefore, the 'life' of a packet follows these steps:
= a program on a client computer sends data using its target's virtual IP
address;
= the operating system adds a header to the packet and passes the packet to a virtual adapter for dispatch. The header and the data comprise a packet;
= a virtual adapter passes the packet to a tunnelling program;
= the process encrypts (optionally) the packet and sends it to the target computer using its physical IP address;
= the tunnelling program on the target computer receives the packet, decrypts it and checks that whatever was received is a packet;
= the tunnelling program then passes the packet to a virtual adapter . This is referred to as packet injection;
= the virtual adapter then passes it to the operating system (as if it received it from a physical wire); and = the operating system strips the header from the packet and delivers the data to the program running on the target computer.

The tunnelling program has a 'back channel' for communicating with the virtual adapter. This channel is used by the virtual adapter for delivering virtually-outbound traffic to the tunnelling program and what the tunnelling program uses to inject virtual-inbound packets into the adapter.
The VPN traffic tunnelled between VPN members is IP and IPX datagrams. Unicast datagrams are sent directly to the recipient VPN member, broadcasts and multicasts are sent to all VPN
members. Support for other types of network traffic and application protocols can be added on as needed basis.

DM VAN/260461-00001/6279099.1 The virtual adapter is configured with a Virtual IP address and a non-trivial subnet that covers the entire Virtual IP address range as configured on the server.

The server decides which client computers require tunnels between themselves based on client computer grouping information. Client computers are grouped together using virtual network configuration objects. A client computer may belong to more than one network.
The clients also have per-network online status, meaning that they can toggle their online presence for each network individually.

The network may be either fully-meshed or hub-n-spoke. In a fully-meshed network the tunnels are setup between all online network members. In a hub-n-spoke network, there is one hub member and zero or more spoke members. The tunnels are setup between the hub and each of the spoke members. The spoke members do not have tunnels between each other.

When the server completes a tunnel setup between two clients, it also generates a temporary cryptographic key for use by the clients to secure this tunnel. Shortly after the tunnel setup, the clients run through a cryptographic key exchange, generate their own private secret key and use the private key instead of the server-provided key to secure the tunnel.

In order to authenticate the key exchange, the client computers look up the other's public key in their trusted key cache. If the key is not found, it is requested from the server and put into an untrusted key cache. The key exchange is then completed, and the tunnel marked respectively (trusted or untrusted).

The trusted/untrusted key caches provide for client computers not trusting the server in its public key distribution capacity. Therefore every new key the client computer receives from the server must be inspected by comparing the 'key fingerprint' of the client computer's and the sending computer's copies of the public key. The key fingerprint is a human-readable string of hexadecimal numbers, usually 16 or 20 numbers in size. The key is then verified using an out-of-band channel. Once verified the key is moved to the trusted cache.

Traffic that is exchanged by the client computer and the server is therefore encrypted, authenticated and protected against replays. Traffic that is exchanged by a pair of client computers is thereby authenticated and protected against replays. Such traffic between a pair of DM V AN/260461-0000 I /6279099.1 client computers may also be encrypted. Specifics of the cryptographic algorithms used, key sizes, padding types, chaining modes, etc depend on the prior agreement between the server and the client computer.

The above described system and method can be implemented as a series of instructions stored on computer readable memory, such as a disc or hard drive, or RAM. The server and/or client computers may be configured to carry out the methods described above. The instructions according to the method may be present in a carrier wave embodying a computer data signal to communicate the instructions to a computer, which when executed by a processor within a computer carry out the method.

Although the particular preferred embodiments of the invention have been disclosed in detail for illustrative purposes, it will be recognized that variations or modifications of the disclosed apparatus lie within the scope of the present invention.

DM VAN/260461-00001/6279099.1

Claims (7)

What is claimed is:

1. A method for a server to hole punch through a NAT device protecting a client computer, the NAT device not an identity-preserving NAT device, comprising the steps of:

(a) said server instructing said client computer to send first, second and third packets using a set of IP address and port values;

(b) said server analyzing fourth, fifth and sixth packets received as reflections of said first second and third packets;

(c) said server predicting the which external port to be used by said client computer when initiating communications with a second client computer;

(d) said server instructing said first client computer to communicate with said second computer; and (e) said server confirming that a tunnel is in place within said first client computer and said second client computer.

2. The method of claim 1 wherein said tunnel is a VPN between said first client computer and said second client computer.

3. A method for a server to provide connectivity between a first client computer and a second client computer, the method comprising:

(a) the server issuing a first relay number ID to said first client computer and a relay and a second relay number ID to said second client computer and said relay;

(b) said first and second computer setting up a UDP based relay connection;
(c) said first and second computers setting up a SSL based relay connection;
(d) said first and second computers setting up a HTTP based relay connection;

(e) said first and second computers measuring the round trip time for each of said UDP based connection, said SSL based connection and said HTTP based connection; and (f) said server selecting a connection of said UDP based relay connection, said SSL based relay connection and said HTTP based connection based on predetermined criteria, and terminating the other connections.

4. The method of claim 3, wherein in step (f) said predetermined criteria includes the lowest round trip time of said UDP based relay connection, said SSL based relay connection and said HTTP based relay connection.

5. A method of maintaining sessions between a first client computer and a second client computer when a server fails to receive a notification packet from the first computer, comprising the steps of:

a) the server sending a notification to said second computer that said first computer is offline and notifying said second computer if the first computer's termination was expected;

b) if the first computer's termination was not expected, said second client computer maintaining said session and periodically transmitting a probe to said first client computer; and c) if said first client computer responds to said probe, said first client computer and said second client computer maintaining said session.

6. A method of establishing a virtual private network between a first client computer and a second client computer, comprising the steps of:

a) providing a public and private key for a server, said server providing said server public key to the first client computer and the second client computer;

b) said first client computer transmitting a packet to a virtual IP address associated with said second client computer, said packet sent by a tunnelling program to a physical IP address associated with said second client computer; and c) a virtual adaptor receiving said packet and sending said packet to said second client computer.

7. A method for a server to determine the presence and type of a first NAT
device protecting a first client computer having a first IP address, and a second NAT
device protecting a second client computer having a second IP address, said first and second client computers having respective first and second IP addresses, comprising the steps of:

a) the server transmitting a first packet to the first client computer; said first packet including a first source IP address and port; the second IP address and a datum;

b) the first client computer transmitting a second packet to said second IP
address, said second packet including said datum;

c) the second client computer transmitting a third packet to the server, said third packet including a source address from said third packet and said datum; and d) said server comparing said first IP address and said source address from said third packet and determining the type of said first NAT device.