ENHANCED PRIVACY PRESERVING ACCESS TO A VPN SERVICE

Abstract

A request is received from a user device to establish a VPN tunnel. The VPN tunnel is established with a first private IP address of the VPN concentrator and a second private IP address of the user device as endpoints. An outbound packet for transmission to a target is received from the user device. A third private IP address associated with the tunnel is looked up based on a VPN session. A substitution of the first private IP address with the third private IP address in a header of the outbound packet is performed. NAT is performed on the outbound packet to replace the third private IP address with a third public IP address of the VPN concentrator. The outbound packet is then transmitted to the target.

Claims

1-28. (canceled)

29. A method, comprising: receiving a request from a user device to establish a virtual private network (VPN) tunnel, the request being received from a first public internet protocol (IP) address of the user device at a second public IP address of a VPN concentrator; establishing the VPN tunnel, wherein a first private IP address of the VPN concentrator and a second private IP address of the user device constitute endpoints of the VPN tunnel; receiving, at the first private IP address, an outbound packet for transmission to a target from the user device via the second private IP address; looking up a third private IP address associated with the VPN tunnel in a peer hashtable based on a VPN session associated with the VPN tunnel; performing a substitution of the first private IP address with the third private IP address in a header of the outbound packet, wherein the substitution is performed based on the look up in the peer hashtable; performing network address translation (NAT) on the outbound packet to replace the third private IP address with a third public IP address of the VPN concentrator in the header of the outbound packet prior to transmitting the outbound packet to the target; and transmitting the outbound packet to the target.

30. The method of claim 29, wherein the first private IP address and the second private IP address are associated with at least one other VPN tunnel between the VPN concentrator and another user device.

31. The method of claim 29, wherein the user device is pre-configured to use the second private IP address.

32. The method of claim 29, wherein the VPN concentrator is pre-configured to use the first private IP address.

33. The method of claim 29, further comprising: associating, in the peer hashtable, the third private IP address with an identifier of the VPN session.

34. The method of claim 33, wherein the identifier of the VPN session comprises a public encryption key used by the user device to encrypt data for transmission over the VPN tunnel.

35. The method of claim 33, wherein the identifier of the VPN session comprises a user property associated with a user of the user device who is authorized to have the VPN tunnel established.

36. The method of claim 35, further comprising: transmitting, by the VPN concentrator, a request to an authentication service that includes a public encryption key received in the request to establish the VPN tunnel; and receiving, at the VPN concentrator, the user property from the authentication service.

37. The method of claim 29, further comprising: performing NAT on an inbound packet received from the target to replace the third public IP address with the third private IP address; identifying the first private IP address based on the look up using the third public IP address in the peer hashtable; and substituting, based on the look up, the third private IP address with the first private IP address in a header of the inbound packet; and transmitting the inbound packet to the first private IP address.

38. A system, comprising: a memory; and a processor, the processor configured to execute instructions stored in the memory to: receive a request from a user device to establish a virtual private network (VPN) tunnel, the request received at a VPN concentrator; establish the VPN tunnel, wherein a first private IP address of the VPN concentrator and a second private IP address of the VPN concentrator constitute endpoints of the VPN tunnel; receive, at the first private IP address, an outbound packet for transmission to a target from the user device via the second private IP address; look up a third private IP address associated with the tunnel in a peer hashtable based on a VPN session associated with the VPN tunnel; perform a substitution of the first private IP address with the third private IP address in a header of the outbound packet, wherein the substitution is performed based on the look up in the peer hashtable; replace the third private IP address in the outbound packet with a third public IP address of the VPN concentrator in the header of the outbound packet prior to transmitting the outbound packet to the target; and transmit the outbound packet to the target.

39. The system of claim 38, wherein the first private IP address and the second private IP address are associated with at least one other VPN tunnel between the VPN concentrator and another user device.

40. The system of claim 38, wherein the user device is pre-configured to use the second private IP address.

41. The system of claim 38, wherein the VPN concentrator is pre-configured to use the first private IP address.

42. The system of claim 38, wherein the processor is further configured to execute instructions stored in the memory to: associate, in the peer hashtable, the third private IP address with an identifier of the VPN session.

43. The system of claim 42, wherein the identifier of the VPN session comprises a public encryption key used by the user device to encrypt data for transmission over the tunnel.

44. The system of claim 42, wherein the identifier of the VPN session comprises a user property associated with a user of the user device who is authorized to have the VPN tunnel established.

45. The system of claim 44, wherein the processor is further configured to execute instructions stored in the memory to: transmit, by the VPN concentrator, a request to an authentication service that includes a public encryption key received in the request to establish the VPN tunnel; and receive, at the VPN concentrator, the user property from the authentication service.

46. The system of claim 38, wherein the processor is further configured to execute instructions stored in the memory to: replace, in an inbound packet received from the target, the third public IP address with the third private IP address; identify the first private IP address based on a look-up using the third public IP address in the peer hashtable; and substitute, based on the look up, the third private IP address with the first private IP address in a header of the inbound packet; and transmit the inbound packet to the first private IP address.

47. A non-transitory computer readable medium storing instructions operable to cause one or more processors to perform operations for privacy-preserving access to a Virtual Private Network (VPN) service, the operations comprising: establishing a VPN session over a VPN tunnel between a user device and a VPN concentrator over a first network, wherein network endpoints of the VPN tunnel are assigned identical private internet protocol (IP) addresses across respective VPN tunnels of respective user devices; replacing, utilizing session-based address translation, at least one of the private IP addresses in packets received from the user device and directed to a target with an outbound private IP address associated with the VPN session; replacing, utilizing IP-based address translation, the outbound private IP address with a public IP address associated with the VPN concentrator; and transmitting the packets that include the public IP address to the target over a second network.

48. The non-transitory computer readable medium of claim 47, wherein the session-based address translation uses a peer hashtable that maps data associated with the VPN session to outbound private IP address.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0057] FIG. 1 is a block diagram of an exemplary architectural depiction of components and protocols.

[0058] FIG. 2 is a block diagram of an exemplary network layout.

[0059] FIG. 3 is a block diagram of an exemplary Authentication Platform setup and protocols.

[0060] FIG. 4 is an exemplary process/flow diagram.

[0061] FIG. 5 illustrates a computing system in which a computer readable medium may provide instructions for performing any of the methods disclosed herein.

DETAILED DESCRIPTION

[0062] Some general terminology descriptions may be helpful and are included herein for convenience and are intended to be interpreted in the broadest possible interpretation. Elements that are not imperatively defined in the description should have the meaning as would be understood by the person skilled in the art.

[0063] VPN user—a person or a business entity that is using VPN services. As a standard placed within a client-grade network, working over such transport links as Wi-Fi, mobile data networks, residential networks. VPN user initiates and establishes the encrypted VPN connection to a VPN Concentrator.

[0064] User device—a computing device where a person installs and executes the application that delivers VPN connectivity.

[0065] VPN Concentrator—a computing device attached to a computer network that accepts VPN users' requests for establishing encrypted connection, or tunnel, and is the endpoint of such encrypted connections from multiple VPN users. As a standard with VPN tunneling protocol endpoints, on establishing a VPN connection, or tunnel, with a VPN user VPN concentrator becomes the default gateway for the VPN user.

[0066] Target or Target server—a server serving any kind of content accessible over multiple protocols over the Internet. Most often a device placed within a datacenter network of high reliability and capability.

[0067] Network—a digital telecommunications network that allows nodes to share resources. Examples of a network: local-area networks (LANs), wide-area networks (WANs), campus-area networks (CANs), metropolitan-area networks (MANs), home-area networks (HANs), Intranet. Extranet, Internetwork, Internet.

[0068] Tunneling or Tunnel—a protocol that allows for the secure movement of data from one network to another. Tunneling involves allowing private network communications to be sent across a public network, such as the Internet, through a process called encapsulation. The encapsulation process allows for data packets to appear as though they are of a public nature to a public network when they are actually private data packets, allowing them to pass through unnoticed. Encapsulation allows the packets to arrive at their proper destination. At the final destination, decapsulation and decryption occur.

[0069] Authentication platform—the component of the VPN service core infrastructure serving the authentication, authorization and accounting requests from the VPN service front-end components facing the user.

[0070] Peer Hashtable—a dynamically maintained storage for registering all VPN user sessions undergoing Network Address modification while traversing the VC. In some embodiments the format of the hash table may define the unique Peer, or the unique Tunnel/PN, as follows:

[0071] PubKey_1: PrivIP_2: LocalIP=PrivIP_3

[0072] In some embodiments the unique identifier for a user may be a pair of credentials, or just a username, with the unique Peer defined as follows:

[0073] Username: PrivIP_2: LocalIP=PrivIP_3

[0074] The primary purpose of Peer Hashtable is to register the initial and resultant private IP addresses of the VC endpoint for a particular VPN user's session, e.g. Second Private IP address and Third Private IP address, as well as the user's unique identifier that can be a Public Key, or a username, which serves as the key field of the record. The records are dynamically added and removed to the table due to the VPN sessions being opened and closed at the VC. In some embodiments the lifecycle of the Peer Hashtable may be aligned to the status of the VC—the table created when the VC is started and is scrapped when the VC is switched off or the VPN service related processes are stopped.

[0075] FIG. 1 illustrates the basic components of the example embodiment of the system comprising user 100, VPN concentrator 110, Target server 120 and Authentication Platform 130. The communication instances between the components may include VPN connectivity between user 100 and VC 110, Authentication, Authorization and Accounting (AAA) data exchange between VC 110 and AP 130, and requesting and obtaining the content by User 100 from a Target 120.

[0076] FIG. 2 displays the basic network setup and main network endpoints, as well as their connectivity details, comprising an exemplary embodiment of the system. While connecting to VC 110 via a VPN tunnel, user 100 and VC 110 employ the public IP addresses (PubIP_1 for the user, PubIP_2 for the VC) that both possess and that is pre-configured, for connecting their physical interfaces, as well as two private IP addresses (PrivIP_2 for the user 100 and PrivIP_1 for the VC 110) for connecting the virtual VPN tunnel interfaces. In some embodiments, the private IP addresses used during this stage are pre-configured and explicitly specified in the local configuration files of both endpoints—user 100 and VC 110. Both private addresses PrivIP_1 and PrivIP_2 belong to the same private network 108. Moreover, multiple VPN users have the same PrivIP_2 configured as their private address for establishing VPN connectivity. Technical measures described below allow for such multiple identical user endpoint IP configuration to coexist.

[0077] After the VPN tunnel is established and the packets are sent therethrough to a destination on the networks behind the VC 110. Then, the packets are operated upon by the VC 110 so that a new private IP address is assigned to the packets as their source address—PrivIP_3. Thus, the first NAT happens. The private IP PrivIP_3 belongs to the private network 118.

[0078] The corresponding record of this session, including the source address substitution, is entered and kept within the Hashtable 112 in a format specified below. The purpose of this record is to keep the original private IP-based connection of the VPN tunnel and the NATed connection over the network 112 as related, allowing for packets to be switched seamlessly between them.

[0079] If User 100 reaches for the target on the Internet network, the packets within the Network 118 must further be operated upon in order to traverse public networks. Traversing the gateway of the Network 118, the outbound packets are once again subjected to NAT, this time going through the public interface of VC 110, with the public IP PubIP_3 assigned as the source address of the packets. Thus, if User 100 reaches for the target on the Internet, the packets within the Network 118 must further be operated upon in order to traverse public networks. Traversing the gateway of the network 118, the outbound packets are once again subjected to NAT, this time going through the public interface of VC 110, with the public IP PubIP_3 assigned as the source address of the packets. Thus, the second NAT happens, allowing the packets to reach a destination on the Internet.

[0080] Since the source addresses of the packets within the network 118 are unique, the second NAT is an industry standard type of network address translation, with the sessions traced through a regular NAT table that is part of a standardized network stack functionalities for modern operating systems. The packets returning from the Internet are converted back to network 118 addresses in accordance with the records within the NAT table.

[0081] However, the user endpoints in network 108 do not possess unique IP addresses. Therefore, it is necessary to trace the packets arriving from network 118 to a session happening across network 108. The records in the Peer Hashtable 112 provide for that, allowing the packets to have their source IP address to be again converted to the original PrivIP_2 from the network 108 and attached to a particular user's 100 VPN session, i.e. directed to the corresponding VPN tunnel 106 and ultimately reach user's 100 computing device.

[0082] In the authentication platform setup and protocol embodiment illustrated by FIG. 3, the user 100 initiates a handshake with VC 110 at step 300. At step 302, the VC 110 decrypts the handshake and at step 304, forwards the access request 304 to the AP 130. At step 306, the AP finds user 306, and at step 308, the AP provides requested coned consent to the VC 110, which in turn provides the handshake response to the user 100 at step 310. Further, at step 312 the VC 110 sends an accounting request to the AP 130. At step 312, the user sends encrypted packets to the target 120, and at step 316, the VC 110 sends an accounting stop request to the AP 130.

[0083] FIG. 3 portrays an example of the AAA data exchange between the VC 110 and AP 130, where User 100 initiates (step 300) the connection to VC 110, providing the user's Public Key PubKey_1 (decrypted at step 302) for establishing the VPN tunnel (step 310) foremost, and also to find the user (step 306) in the VPN service customer records at AP 130.

[0084] In an embodiment, the AP 130 receives the user's access credential (FIG. 3, step 304), an evaluates if the user is a legitimate VPN service user by comparing the credentials provided with a user database record (FIG. 3, step 306). Upon successful proof of a legitimate VPN user identity to the AP 130, a first access authorization for the user to access VPN service is received via the VC 110 (FIG. 3, step 308).

[0085] FIG. 4 demonstrates the operation of an example system implementing the protocols for client privacy-oriented VPN access at a VPN Concentrator (VC) 110, mediated by an Authentication Platform (AP) 130. The entities in the system include at least a user 100 and/or a VPN application 102 (e.g., software component implementing the VPN access system and protocols) operated by the user 100, an AP 130, and an VC 110. In some implementations, there is an existing account relationship between the AP 110 and the VC 110, such that the VC 110 will allow a user 100 to access its services if the user 100 provides proof that it is registered with the AP 130. The user may also have account relationships with the other parties.

[0086] In an initial stage, a user first registers with the AP to establish an account with the AP. The account can be based on a pair of user credentials (e.g., a strong credential that is a data string used in a cryptographic function, or a username-password pair) for use at the AP. By using the method described in this specification, after performing the initial authentication with the VPN service provider through whatever means the provider made available, the user can establish a VPN tunnel through a VC using a single cryptographic key, e.g. a Public Key, and the corresponding cryptographic functions (FIG. 3, step 302). In an implementation of the invention the VC may not contain any information about the user throughout the entire time the user is connected to VC through a VPN tunnel, except the Public Key generated for the user during the initial registration.

[0087] An AP verifies user access authorization on behalf of VCs (FIG. 3 steps 306-308) and may provide a selective disclosure of user properties to the VC, e.g. username of the connecting client. The AP can itself be a service or content provider that holds certain user information. The AP can obtain the user information through user registration (sometimes with verification documents from other authorities). An example AP can be an authentication service provider based on RADIUS protocol, that already possesses some information of a user through the registration process. The systems and protocols disclosed herein apply to processes that allow an AP to manage users and to further allow users to access a VC under privacy constraints.

[0088] In some implementations, the AP may be based on a multi-tier architectural principle, whereas the user's authentication is first submitted to a front-end AP system and at the front-end AP is subsequently submitted for further processing by a back-end AP component.

[0089] User authentication at the AP can be accomplished through a client identification system utilizing public-key cryptography, where VC forwards to AP the Public Key the user provided for establishing the VPN tunnel, and AP evaluates the Public Key comparing it to the user records kept within the AP, and replies with “Access granted” or “Access denied” depending on the successful identification of the corresponding user within the AP records. The AP can also exchange verifiable signatures with a user or VC using techniques of public-key cryptography. In some implementations, the AP can provide privately verifiable signatures that can only be verified by the AP itself. As an example, in some embodiments the encryption can be a standard AES method, among others, in some mode of encryption.

[0090] Once the AP receives and is satisfied with the user's proof of identity previously registered with the AP and submitted through VC, the AP can provide a confirmation of the user's access authorization (FIG. 4 step 510) and/or selective disclosure of certain user properties to the VC. In some implementations, the AP can sign the reply with an AP signature.

[0091] In an embodiment, for example, as depicted by FIG. 4, the process begins at step 500, at which the user 100 initiates a handshake with the VC 100, which, at step 502, retrieves a peer from the peer hashtable 112. At step 504, the VC 110 creates a peer, and at step 506, requests a user from the AP 130, which, at step 508, extracts a user and at step 510 confirms the user to the VC 110. At step 512, the VC 110 indicates to the user 100 that the handshake is finished. At step 513, the user 100 establishes a VPN tunnel with the VC 110, in which the encapsulation layer has a PubIP_1 at the user 100 and a PubIP_2 at the VC 110, and the user 100 has a PrivIP_2, while the VC 110 has a PrivIP_1. At step 510, the VC 110 assigns a PrivIP_3, and at step 516, the VC 110 updates the peer hashtable 112. At step 518, the user 100, with IP address PrivIP_2, sends a packet to the VC 110, with IP address PrivIP_1. At step 520, the VC 110 alters outbound packet, and at step 522 sends the packet to the target 120. At step 524, the VC 110 receives a packet from the target 120, and at step 526, the VC 110 alters the inbound packet. At step 528, the VC 110, from PrivIP_1, sends the packet to the user 100 at the PrivIP_2.

[0092] In an embodiment, a computer-implemented method of allowing user access to a Virtual Private Network (BPN) service comprises receiving, at the VPN Concentrator (VC 110), a VPN tunnel establishment request from a user 100 (FIG. 4, step 500) and receiving, from the user, an Identifier at the VC 110. The identifier is verified at an Authentication Platform (AP) 130 (FIG. 4, steps 506-508), which provides access authorization consent to the user through the VC 110 (FIG. 4, step 510). A VPN tunnel is established between the user 100 and the VC 110 (FIG. 4, steps 512-513), wherein an encapsulating layer of the tunnel is between a First Public Internet Protocol (IP) of the user and as Second Public IP of the VC, with both the First Private IP address and the Second Private IP address being associated with a First Private network. A Third Private IP address is assigned to the established VPN tunnel (FIG. 4, step 514) associated with a Second Private network. Packet descriptors, including at leas the identifier and the Third Private IP address within a Peer Hashtable (FIG. 4, step 516), are registered at the VC 110. A connection request to a target 120 on the Internet is received from the user 100 through the VC 110 (FIG. 4, step 518). At the VC, a source IP address of packets arriving from the user and leaving the First Private network, is altered (FIG. 4, step 520) to the Third Private IP address. The source IP address of the packets leaving the Second Private Network to a destination on the Internet, is altered to the Third Public IP address. The packets returning from the target 120 (FIG. 4, step 524) are received at the VC's 110 third Public IP address, and the destination address of the packets is converted to the Third Private IP address (FIG. 4, step 526). The tunnel from the Peer Hashtable is resolved using the Third Private IP address. The destination address is altered back to the First Private Address (FIG. 4, step 527), and the packet is sent back to the user via the VPN tunnel (FIG. 4, step 528).

[0093] Any of the above embodiments herein may be rearranged and/or combined with other embodiments. Accordingly, the concepts herein are not to be limited to any particular embodiment disclosure herein. Additionally, the embodiments can take the form of hardware entirely or comprising both hardware and software elements. Portions the embodiments may be implemented in software, which includes, but is not limited to, firmware, resident software, microcode, etc. FIG. 5 illustrates a computing system 300 and which a computer readable medium 606 may provide instructions for performing any of the methods disclosed herein.

[0094] Furthermore, the embodiments can take the form of a computer program product accessible from the computer readable medium 606 providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, the computer readable medium 606 can be any apparatus that can tangibly store the program for use by or in connection with the instruction execution system, apparatus, or device, including the computer system 600.

[0095] The medium 606 can be any tangible electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of a computer readable medium 606 include a semiconductor or solid-state memory, magnetic tape, a removable computer diskette, a random-access memory (RAM), NAND flash memory, a read-only member (ROM), a rigid magnetic disk, and an optical disk. Some examples of optical disks including compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W), and digital versatile disc (DVD).

[0096] The computing system 600, suitable for storing and/or executing program code, can include one or more processors 602 coupled directly or indirectly to memory 608 through a system bus 610. The memory 608 can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code is retrieved from bulk storage during execution. Input/output or I/O devices 604 (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adaptors may also be coupled to the system to enable the computing system 600 to become coupled to other data processing systems, such as through host systems interfaces 612, or remote printers or storage devices through intervening private or public networks. Modems, cable modem, and Ethernet cards are just a few of the currently available types of network adapters.

[0097] The present system(s) and method(s) can be understood more readily by reference to the instant detailed description, examples, and claims. It is to be understood that the system(s) and method(s) detailed herein are not limited to the specific systems, devices, and/or methods disclosed unless otherwise specified, as such can, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting.

[0098] The instant description of the system(s) and method(s) detailed herein is provided as an enabling teaching of the system(s) and method(s) detailed herein in their best, currently known aspect. Those skilled in the relevant art will recognize that many changes can be made to the aspects described, while still obtaining the beneficial results of the present system(s) and method(s) detailed herein. It will also be apparent that some of the desired benefits of the system(s) and method(s) detailed herein can be obtained by selecting some of the features of the system(s) and method(s) detailed herein without utilizing other features. Accordingly, those who work in the art will recognize that many modifications and adaptations to the system(s) and method(s) detailed herein are possible and can even be desirable in certain circumstances and are a part of the system(s) and method(s) detailed herein. Thus, the instant description is provided as illustrative of the principles of the system(s) and method(s) detailed herein and not in limitation thereof.

[0099] As used herein, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to a “body” includes aspects having two or more bodies unless the context clearly indicates otherwise.

[0100] Ranges can be expressed herein as from “about” one particular value, and/or to “about” another particular value. When such a range is expressed, another aspect includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the particular value forms another aspect. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint.

[0101] As used herein, the terms “optional” or “optionally” mean that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.

[0102] Although several aspects of the system(s) and method(s) detailed herein have been disclosed in the foregoing specification, it is understood by those skilled in the art that many modifications and other aspects of the system(s) and method(s) detailed herein will come to mind to which the invention pertains, having the benefit of the teaching presented in the foregoing description and associated drawings. It is thus understood that the system(s) and method(s) detailed herein is not limited to the specific aspects disclosed hereinabove, and that many modifications and other aspects are intended to be included within the scope of the appended claims. Moreover, although specific terms are employed herein, as well as in the claims that follow, they are used only in a generic and descriptive sense, and not for the purposes of limiting the described system(s) and method(s) detailed herein.