TECHNICAL FIELD

The present disclosure, in some embodiments thereof, relates to serving a plurality of VPN clients and, more specifically, but not exclusively, to creating for each of a plurality of VPN clients a respective one of a plurality of private sub-networks all isolated from each other.

BACKGROUND

Networked services are constantly evolving for a plurality of applications, services and platforms ranging over practically every aspect of modem life. These networked services hence present multiple and ever increasing challenges for the underlying networks which become ever more complex.

However, since data may be transferred over open networks which are susceptible to interception, monitoring and/or eavesdropping, many of the networked services may suffer major privacy, security and/or integrity issues.

Various methods, technologies and protocols were devolved to address these vulnerabilities in the networked services. One of the most prominent solutions is the Virtual Private Network (VPN) in which data transmitted between the VPN client and the VPN server is encrypted thus creating a virtual tunnel over the open network. The virtual tunnel utilized using one or more encryption protocols is immune to potential malicious attacks since even if intercepted it may not be decoded and/or deciphered.

However, there are major challenges involved in deploying VPN links, specifically for concurrently serving large numbers of VPN clients at the same time. SUMMARY

An objective of the embodiments of the disclosure is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

The above and further objectives are solved by the subject matter of the independent claims. Further advantageous embodiments can be found in the dependent claims.

The disclosure aims at providing a solution for creating, maintaining and managing a plurality of private sub-networks each created for a respective one of a plurality of VPN clients (client devices) concurrently served by a service network where each of the private sub-networks is completely isolated and inaccessible from the other private sub-networks.

According to a first aspect of the present disclosure there is provided a VPN gateway comprising a circuitry configured to create a plurality of sub-networks isolated from each other for a plurality of client devices requesting to establish a respective one of a plurality of VPN links with a service network comprising a plurality of network nodes, and establish the requested plurality of VPN links with the plurality of client devices each connecting the respective client device to its respective isolated sub-network. The VPN gateway creates each of the plurality of isolated sub-networks for a respective one of the plurality of client devices by: identifying a subgroup comprising one or more of the plurality of network nodes according to access credentials of the respective client device, and assigning a server virtual address to each member of the subgroup and a client virtual address to the respective client device.

According to a second aspect of the present disclosure there is provided a computer implemented method of creating a private sub-network for a plurality of VPN clients, comprising creating a plurality of sub-networks isolated from each other for a plurality of client devices requesting to establish a respective one of a plurality of VPN links with a service network comprising a plurality of network nodes and establishing the requested plurality of VPN links with the plurality of client devices each connecting the respective client device to its respective isolated sub-network. Each of the plurality of isolated sub-networks is created for a respective one of the plurality of client devices by identifying a subgroup comprising one or more of the plurality of network nodes according to access credentials of the respective client devices, and assigning a server virtual address to each member of the subgroup and a client virtual address to the respective client device. Creating the private isolated sub-networks may ensure that each client device (VPN client) is able to access only the network nodes and services which are members of its respective subnetwork which are selected according to the access credentials of the respective client device. Moreover, none of the client devices may access any of the other client devices. Furthermore, using the virtual addresses may prevent address conflicts (overlap) with addresses assigned in the origin networks through which the client devices connect to the service network. In addition, a large number of client devices may be served concurrently using common virtual and/or local addresses since the VPN connection and private sub-network of each client device is managed by the VPN gateway in isolation and independently of the VPN links and private sub-networks of the other client devices.

In a further implementation form of the first and/or second aspects, the circuitry is configured to control incoming network traffic transmitted by the respective client device via the respective VPN link to the member network node by performing the following for each incoming message:

- Adjust a source address of the incoming message comprising the client virtual address to a client local address in a local address range of the service network.

- Adjust a destination address of the incoming message comprising the server virtual address to include a server local address in the local address range.

Forward the incoming message to one or more of the network nodes.

Managing the incoming network traffic by adjusting the incoming messages according to the assigned virtual addresses may be essential for properly routing and forwarding the incoming messages to the target (destination) network nodes.

In a further implementation form of the first and/or second aspects, the circuitry is configured to control outgoing network traffic transmitted by the member network node to the respective client device by performing the following for each outgoing message:

- Adjust a source address of the outgoing message comprising a server local address to include the server virtual address.

- Adjust a destination address of the outgoing message comprising a client local address to include the client virtual address.

Transmit the outgoing message to the respective client device via the respective VPN link. Managing the outgoing network traffic by adjusting the outgoing messages according to the assigned virtual addresses may be essential for properly routing and forwarding the outgoing messages to the target (destination) client devices.

In a further implementation form of the first and/or second aspects, the client virtual address and the server virtual address are not in a range of local addresses assigned to the service network and not in a range of local addresses assigned to an origin network to which the respective client device is connected to establish the respective VPN link. As the client virtual addresses and the server virtual addresses are not in the range of the local addresses of the service network and/or the origin network addressing conflicts, overlapping and/or the like are prevented thus avoiding network reachability and/or degradation problems due to address ambiguity.

In a further implementation form of the first and/or second aspects, the client virtual address and the server virtual address are selected from a predefined address range uniquely assigned for use by the service network. This may serve to prevent address conflicts between the virtual addresses and the local addresses assigned in the service network and/or the origin network.

In a further implementation form of the first and/or second aspects, the client virtual address and the server virtual address are selected from an arbitrary selected address range. This may serve to prevent address conflicts between the virtual addresses and the local addresses assigned in the service network and/or the origin network.

In a further implementation form of the first and/or second aspects, the client virtual address and the server virtual address are selected according to an address range negotiated with the client device. This may serve to prevent address conflicts between the virtual addresses and the local addresses assigned in the service network and/or the origin network.

In a further implementation form of the first and/or second aspects, the client virtual address, the server virtual address, the client local address and the server local address are Internet Protocol (IP) addresses. Since communication based on the IP protocol is most dominant and common, the virtual addresses configured according to the IP protocol addressing may be highly complaint for practically any networking system, service and/or platform with no need to adaptation, customization, integration and/or migration efforts and/or costs.

In a further implementation form of the first and/or second aspects, the circuitry is further configured to convert between IPv6 address ranges and an IPv4 address ranges by assigning the client virtual address and the server virtual address in an IPv6 address range and translate the client virtual IPv6 address and the server virtual IPv6 to respective client local IPv4 address and server local IPv4 address in case the local address range is an IPv4 address and vice versa in case the local address range is an IPv6 address range. Converting network traffic from one communication protocol to network traffic complaint with another communication protocol, for example, IPv6 packets and IP4 packets and/or vice versa may be highly desirable for efficient deployment and/or adoption by multiple applications, platforms, systems and/or in which there is a mixture of such communication protocols.

In a further implementation form of the first and/or second aspects, the circuitry is configured to associate one or more outgoing messages transmitted by the member network node in response to a respective incoming message transmitted by the respective client device according to the client local address. In case there are sufficient local addresses to assign a unique client local address to each client device, it may be highly efficient to follow such a unique addressing scheme since each of the client devices may be easily and uniquely identified by its unique local address. Such implementation may typically apply for service networks which serve a relatively small number of VPN clients at any given time.

In a further implementation form of the first and/or second aspects, the circuitry is configured to associate one or more outgoing messages transmitted by the member network node in response to a respective incoming message transmitted by the respective client device by tracking the connection of the respective client device to the service network. When serving a large number of VPN clients, the local address range which is naturally limited may be insufficient for assigning a unique client local address to each of the client devices (VPN clients). In such case multiple client devices may be assigned with a common client local address. One or more session and/or connection tracking protocols, techniques and/or methods may be therefore applied to associate each message, specifically each outgoing message with its target client device, without solely relying on the client local address included as the destination address in the outgoing messages.

In a further implementation form of the first and/or second aspects, the circuitry is further configured to extend the isolated sub-network created for one or more of the plurality of client devices to include a DNS controller of the service network by assigning a Domain Name System (DNS) virtual address to the DNS controller. Wherein the circuitry is configured to control incoming and outgoing network traffic by adjusting and forwarding one or more DNS requests transmitted by the client device via the respective VPN link to the DNS controller and adjusting and transmitting via the respective VPN link one or more response messages transmitted by the D S controller to the respective client device. Supporting the DNS scheme may be essential for easy, efficient and straight forward, deployment, integration and/or adoption by multiple applications, platforms, systems and/or in which the DNS is a basic component.

In a further implementation form of the first and/or second aspects, the service network is constructed of one or more physical networks and/or one or more virtual networks and each of the plurality of network nodes is a physical network node or a virtual network node. As modem service networks may include physical networks, virtual networks and/or a combination thereof, supporting any such deployment may be essential to make the isolated private sub-networks VPN solution an attractive option for adoption and integration in such service networks.

Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the disclosure pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the disclosure, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

Implementation of the method and/or system of embodiments of the disclosure can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the disclosure, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the disclosure could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the disclosure could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the disclosure, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, a magnetic hard-disk and/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Some embodiments of the disclosure are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the disclosure. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the disclosure may be practiced.

In the drawings:

FIG. 1 is a flow chart of an exemplary process of creating a private sub-network for each of a plurality of VPN clients requesting to access a service network, according to some embodiments of the present disclosure;

FIG. 2 is a schematic illustration of an exemplary networked system for creating a private sub-network for each of a plurality of VPN clients requesting to access a service network, according to some embodiments of the present disclosure; FIG. 3 is a schematic illustration of an exemplary sequence for initializing a private sub network for a VPN client and managing traffic exchanged between the VPN client and a network node, according to some embodiments of the present disclosure; and

FIG. 4 is a schematic illustration of an exemplary sequence for initializing a private sub network for a VPN client using a DNS controller and managing traffic exchanged between the VPN client and the DNS controller and a network node, according to some embodiments of the present disclosure. DETAILED DESCRIPTION

The present disclosure, in some embodiments thereof, relates to serving a plurality of VPN clients and, more specifically, but not exclusively, to creating for each of a plurality of VPN clients a respective one of a plurality of private sub-networks all isolated from each other.

The present disclosure presents devices, systems and methods for creating a plurality of private sub-networks for a plurality of VPN clients initiated by a plurality of client devices for accessing a service network via a plurality of VPN links at the same time. In particular, the client devices access one or more network nodes of the service network, for example, a server, a computing node, a cluster of computing nodes, a virtual machine, a cloud service and/or the like providing one or more services to the client devices.

Each of the plurality of private sub-networks is created for a respective one of the plurality of client devices to include one or more members (network nodes) of the plurality of network nodes of the service network which are authorized for access for the respective client device such that the respective client device may access only the member network nodes included in its respective private sub-network.

Moreover, the plurality of private sub-networks are isolated from each other such that each of the client devices (VPN clients) is unaware of any of the other client devices currently connected to the service network.

The VPN links and their respective private sub-networks may be each independently and separately managed and controlled by one or more gateways deployed to connect one or more local networks constituting the service network to one or more external networks, in particular, the internet from which the client devices access the service network.

Specifically, the gateway(s) may execute and/or utilize a VPN manager which may manage, i.e., control, map, route and/or the like network traffic exchanged between the plurality of client devices and the network nodes via the plurality of VPN links.

Upon receiving a request from a respective one of the plurality of client devices to establish a VPN link with one or more of the network nodes of the service network, the VPN manager may analyze access credentials of the respective client device to determine which of the network nodes are authorized for access by the respective client device. The VPN manager may then crate a private sub-network for the respective client device which includes the network nodes (members) authorized for access to the respective client device. The VPN manager create the private sub-network for each of the client devices by assigning a client virtual address to the respective client device and a server virtual address to each member (network node) of the respective private sub-network created for the respective client device. The VPN manager may then transmit the virtual addresses (client and server) to the respective client device which may use these virtual addresses for accessing the member network node(s) included in its respective private sub-network.

In particular, the VPN manager assigns the client and server virtual addresses in an address range which does conflict with local addresses assigned to network resources in the service network. The VPN manager may further assign a client local address to each of the client devices for mapping the client devices in the service network.

Moreover, the VPN manager assigns the client and server virtual addresses in an address range which does not conflict with addresses assigned in an origin network from which the respective client device connects to the service network, for example, through the internet. The VPN manager may select the virtual addresses according to one or more methods, techniques and/or implementations in order to ensure there are no network address conflicts, i.e. no overlapping between the virtual addresses and the local addresses used in the service network and in the origin networks.

For example, the virtual address range may be predefined and uniquely assigned for use by a certain VPN manager in a certain service network. Since such a virtual address range is uniquely assigned for use in the certain service network, there is no concern for conflicting addresses with the local addresses in the service network and/or at the origin networks to which the client devices are connected. In another example, the virtual address range may be arbitrary and/or randomly selected by the VPN manager thus the probability that such a virtual address range conflicts with the local addresses in the service network and/or in the origin networks is significantly reduced and is practically insignificant. In another example, the VPN manager may communicate (hand shake) with one or more of the client devices to explore the address range(s) of the origin network(s). After determining the address range(s) that are used in the origin network(s), the VPN manager may select the client and server virtual addresses from a non-conflicting address range which does not conflict with the local addresses assigned in the origin network(s).

Moreover, the VPN manager may assign the virtual addresses in an address range defined by one communication protocol while the local addresses assigned in the service network and/or the origin network(s) are defined according to another communication protocol. For example, typically the network addressing employs the Internet Protocol (IP) addressing scheme. Assuming the local address range used in service network is defined and complaint with IPv4 protocol, the VPN manager may assign the client virtual address and the respective server virtual address to one or more of the client devices in an address range defined and complaint with IPv6 protocol and vice versa.

Since each VPN link is independently and separately managed the virtual addresses and optionally the local addresses assigned to the client devices as well as the server virtual addresses assigned to network nodes in the respective private sub-networks may be unique for each client device and/or shared between multiple client devices.

After the VPN manager establishes the VPN link with each client device and provides the respective client device the client and server virtual addresses of the network node(s) included in the respective private sub-network, the respective client device may transmit, via its respective VPN link, one or more (incoming) messages to the network nodes using the virtual addresses. Each of these incoming message(s) may include the client virtual address of the respective originating (source) client device and the server virtual address of the network node which id the destination of the respective incoming message.

The gateway, specifically the VPN manager receiving the incoming network traffic, i.e. the incoming messages via the VPN links may adjust the incoming message(s) so that the incoming message(s) may be properly forwarded (routed) to their destination network node(s). In particular, the VPN manager may adjust the source address of each incoming message to replace the client virtual address with the client local address of the respective cline device. The VPN manager further adjusts the destination address of each incoming message to replace the server virtual address with the (server) local address of the respective network node. The gateway may then forward the respective incoming message to the destination network node via the service network.

On the response path, one or more of the network nodes may respond with one or more outgoing messages (outgoing network traffic) to one or more of the incoming messages received from one or more of the client devices. Each of the outgoing message(s) may include the (server) local address of the originating (source) network node and the client local address of the respective client device which is the destination of the respective outgoing message.

The gateway, specifically the VPN manager receiving the outgoing network traffic, i.e. the outgoing messages may adjust each of the outgoing message(s) so that the outgoing message(s) may be properly forwarded (routed) to their destination client device(s). In particular, the VPN manager may adjust the source address of each outgoing message to replace the server local address with the server virtual address of the originating network node. The VPN manager further adjusts the destination address of each outgoing message to replace the client local address with the client virtual address of the respective client device. The gateway may then forward the respective outgoing message to the destination client device via the respective VPN link.

The VPN manager may determine the destination client device of one or more outgoing messages according to the client local address in case each of the client devices is assigned with a unique local address. However, the VPN manager may apply one or more session and/or connection tracking protocols as known in the art to associate one or more of the outgoing messages with their destination devices, in particular in case multiple client devices are assigned with a common client local address.

The network resources, i.e. network nodes and/or services of the service network may be typically mapped using names and/or designators, for example, Uniform Resource Identifiers (URI) such as, for example, Uniform Resource Locators (URL). The service network may therefore include one or more Domain Name system (DNS) controllers configured to resolve the names, for example, the URLs and translate them to standard network addresses assigned to the network nodes mapped in the service network and reachable by the client devices via the VPN links.

In such deployments, the VPN manager may include one or more of the DNS controller(s) in the private sub-network of one or more of the client devices and may further provide a DNS virtual address assigned to each DNS controller in the private sub-network of the respective client device. When establishing the VPN link with the respective client device, the VPN manager may provide (transmit) the DNS virtual address to the respective client device. The respective client device may then use the DNS virtual address to access the DNS controller in order to resolve the name of one or more of the network nodes included it its respective private sub-network.

The private isolated sub-networks created for the plurality of VPN clients may present significant advantages and benefits compared to currently existing methods and systems providing VPN services for connecting VPN clients to service networks.

Some of the exiting VPN services may establish the VPN links with the VPN clients (client devices) by assigning the VPN devices addresses in the local address range of the service network such that the VPN clients appear to be directly connected to the service network as local network nodes residing on the local network of the service network. This may present a major limitation since due to their direct mapping in the service network, while the VPN clients may be allowed (authorized) to access one or more of the network nodes and/or services of the service network, the VPN clients may in fact be able to access other network nodes which are not authorized for them. Creating the private isolated sub-networks on the other hand ensures that each client device (VPN client) is able to access only the network nodes and services defined by their access credentials.

Moreover, when directly mapping the client devices in the service network using the address range of the service network as may be done by some of the existing methods, one or more of the client devices (VPN clients) may access local resources of one or more of the other client devices which of course compromises privacy, security and/or integrity of the local resources. Such scenarios are completely prevented using the private isolated sub-networks since none of the client devices is mapped by the VPN manager to any of the other client devices thus none of the client devices may access other client devices.

Furthermore, the local addresses assigned to one or more of the client devices in the service network may conflict (overlap) with addresses assigned in the origin network(s) through which the client device(s) connect to the service network (typically through the internet). These conflicts may cause network mapping and/or routing problems since the addresses may not be explicitly and unambiguously resolved leading to network reachability and/or connectivity problems which may significantly degrade the network operation. Such issues are significantly reduced and practically eliminated altogether since the client and server virtual addresses assigned for the client devices are selected such that the virtual addresses do not conflict with the local addresses used in the service network as well as those used in the origin network(s).

In addition, some service networks may be serve an extremely large number of VPN clients which may present a major limitation in the availability of sufficient local network addresses for mapping such a large number of client devices in the address range of the service network. This limitation is easily resolved by creating and separately managing the isolated private sub-networks since a plurality of client devices (VPN clients) may be assigned common virtual addresses thus reducing the number of required addresses for mapping the client devices. Since each sub-network and hence each VPN link is managed completely separately from the other sub-networks there is no concern of conflicts and collisions between client devices using the same virtual and/or local addresses.

Also, creating and managing the virtually mapped isolated sub-networks may serve for easily converting network traffic transmitted using one communication protocol to network traffic complaint with another communication protocol, for example, convert between IPv6 packets and IP4 packets and/or vice versa. This capability which may be highly desirable for efficient and/or transparent connections of VPN clients to the service network may be very limited and potentially unfeasible in the existing VPN methods and systems in which mapping the VPN clients is done according to the mapping scheme used in the service network.

Lastly, supporting the DNS scheme may be essential for easy, efficient and straight forward, deployment, integration and/or adoption by multiple applications, platforms, systems and/or in which the DNS is a basic component.

Before explaining at least one embodiment of the disclosure in detail, it is to be understood that the disclosure is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The disclosure is capable of other embodiments or of being practiced or carried out in various ways.

The present disclosure may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.

The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer such as the user equipment (UE), as a stand-alone software package, partly on the user's computer and partly on a remote computer such as the network apparatus or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Reference is now made to FIG. 1, which presents flow chart of an exemplary process of creating a private sub-network for each of a plurality of VPN clients requesting to access a service network, according to some embodiments of the present disclosure. An exemplary process 100 may be executed by a gateway of a service network to establish VPN links with a plurality of client devices used by a plurality of users and create a plurality of private sub-networks all isolated from one another such that each client device may access only its respective private sub-network.

Each sub-network created for a respective client device may comprise one or more network nodes of the service network which are selected according to access credentials defining access rights of the respective client device to the network nodes. The access credentials may be extracted from a credentials record of the client device, for example, a credentials record associated with a respective user of the respective client device.

The gateway may create the isolated sub-networks by assigning a client virtual address to each of the client devices and a server virtual address to each of the network nodes accessible to the client devices. In particular, the (client and server) virtual addresses are assigned in an address range which does conflict with an address range of local addresses assigned in the service network. Moreover, the client virtual address assigned to each of the client devices does not conflict with a range of addresses assigned in an origin network of the respective client device.

After creating the plurality of isolated sub-networks, the gateway may establish the plurality of VPN links with the plurality of client devices and may control incoming and/or outgoing network traffic between the client devices and the service network by redirecting exchanged messages (packets) to their destination. The gateway may redirect the exchanged messages by adjusting the source and/or destination addresses of the exchanged messages according to the virtual addresses assigned to the client devices and to the network nodes.

Reference is now made to FIG. 2, which is a schematic illustration of an exemplary networked system for creating a private sub-network for each of a plurality of VPN clients requesting to access a service network, according to some embodiments of the present disclosure.

An exemplary service network 200 established over a local network 220 may include a plurality of network nodes 202, for example, a server, a computing node, a cluster of computing nodes and/or the like which may provide one or more services to a plurality of user devices 204, for example, a computer, a mobile device (e.g. Smartphone, tablet, etc.) and/or the like. The services may include, for example, mailing service, remote access service (e.g. remote desktop, etc.), database access, storage service and/or the like.

In particular, the client devices 204 may access the service network 200 via respective VPN links established to create a respective virtual point-to-point connection between each of the client devices 204 and the service network 200 by encrypting data exchanged between the network nodes 202 and the client device 204. The VPN links may be established using one more tunneling protocols as known in the art, for example, L2 tunneling, L3 tunneling and/or the like, such as for example, Layer 2 Tunneling Protocol (L2TP), Generic Routing Encapsulation (GRE), Virtual Extensible Local Area Network (VXLAN), Secure Socket Tunneling Protocol (SSTP), Internet Protocol Security (IPSec), IP in IP (IP in IPv4/IPv6), SIT/IPv6 (IPv6 in IPv4/IPv6), Open VPN and/or the like. The local network 220 may include one or more wired and/or wireless networks, for example, a Local Area Network (LAN), a Wide Area Network (WAN) and/or the like which may be utilized by one or more physical networks and/or virtual networks such as, for example, a Software Defined Network (SDN) and/or the like. The physical network(s) may include one or more physical network nodes 202 such as, for example, the server, the computing node, the cluster of computing nodes and/or the like which are managed by one or more physical switches. The virtual network(s) however may include one or more virtual network nodes 202 such as, for example, a Virtual Machine (VM) and/or the like instantiated on one or more physical network nodes 202 and optionally managed by one or more virtual switches, for example, an Open vSwitch (OVS) and/or the like.

The local network 220 providing the infrastructure for the service network 200 may be connected via one or more gateways 206 to one or more external networks 230, for example, a LAN, a WAN, a Municipal Area Network (MAN), a cellular network, the internet and/or the like. Traffic exchanged between the client devices 204 accessing the service network 200 form the external network 230 may therefore go through one or more of the gateways 206.

The gateway 206 having a plurality of network interfaces for connecting to the local network 220 and to the external network 230 may optionally comprise one or more processors (homogenous or heterogeneous) arranged for parallel processing, as clusters and/or as one or more distributed core processing units and a storage for storing code (program store) and/or data. The processor(s) may execute one or more software modules, for example, a process, a script, an application, an agent, a utility, a tool, an Operating System (OS), a service, a plug-in, an add-on and/or the like, each comprising a plurality of program instructions which may be executed from the program store.

The gateway 206 may further include one or more hardware elements, for example, a circuit, a component, an Integrated Circuit (IC), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signals Processor (DSP), a network processor and/or the like.

The gateway 206 may execute a VPN manager 210 for creating and managing a plurality of sub-networks 250 each created for a respective one of the plurality of client device 204 requesting to establish VPN links with the service network 200. The VPN manager 210 may be utilized by one or more of the software modules, one or more of the hardware elements and/or a combination thereof. Moreover, the VPN manager 210 may be implemented as a separate module or it may be integrated with one or more other modules executed and/or deployed in the gateway 206 for establishing, controlling and/or managing the VPN links.

The VPN manager 210 may create the sub-networks 250 each comprising one or more network nodes 202 (members) which may provide one or more services to the client devices 204 according to access rights defined for each of the client devices 204. The access rights of each client device 204 may define the services and/or network node(s) 202 that the respective client device 204 may access. The access rights of each client device 204 or of the respective user using the respective client device 204 may be defined and stored in one or more credential records created for the respective client device 204 and/or for its associated user using the respective client device 204.

For example, the VPN manager 210 may create, for a client device A 204 (204A), a sub- network 250A comprising three members, a network node 202A, a network node 202B and a network node 202E. In another example, the VPN manager 210 may create, for a client device B 204 (204B), a sub-network 250B comprising three members, a network node 202D, the network node 202E and a network node 202F. In another example, the VPN manager 210 may create, for a client device N 204 (204N), a sub-network 250N comprising two members, a network node 202G and a network node 202H.

Optionally, one or more DNS controllers 208 may be deployed in the service network 200 to resolve addressing and/or routing of network traffic messages transmitted over the local network 220. For example, the DNS controller(s) 208 may resolve URIs such as, for example, URLs designating one or more of the network nodes 202 in the service network 200 and translate the URLs to actual network addresses of the respective network nodes 202.

The DNS controller(s) 208 may be deployed and/or utilized in the service network 200 according to one or more techniques, implementations and/or deployments as known in the art. For example, one or more of the DNS controller(s) 208 may be implemented as a dedicated network node such as the network nodes 202. In another example, one or more of the DNS controller(s) 208 may be deployed in one or more of the network nodes 202 providing one or more services to the client devices 204. In another example, one or more of the DNS controller(s) 208 may be deployed in one or more of the gateway(s) 206 deployed in the service network 200 to connect the local network 220 to the external network 230.

As shown at 102, the VPN manager 210 may receive a plurality requests from at least some of the plurality of client devices 204 requesting to establish a VPN link with the service network 200 for accessing one or more of the network nodes 202 and/or services provided by one or more of the network nodes 202.

The plurality of VPN link requests may be received at the gateway 206 simultaneously and/or serially such that the number of VPN links established between the client devices 204 and the service network 200 accumulate over time and managed concurrently by the VPN manager 210. Therefore, while one or more VPN links established with respective client devices 204 may be disconnected and/or new VPN links may be established with the client devices 204, the VPN manager typically maintains a plurality of VPN links with a plurality of respective client devices 204.

As shown at 104, the VPN manager 210 may analyze access credentials of each of the plurality of client devices 204 which initiates a respective one of the plurality of VPN link requests. The access credentials may define access rights of the respective client device 204 for accessing one or more of the network nodes 202 and/or one or more services provided by the network node(s) 202. The VPN manager 210 may therefore analyze the access credentials of each of the plurality of client devices 204 requesting to establish a respective VPN link to identify the access rights of the respective client device 204.

For example, the access credentials of a certain client device 204A may define that the client device 204A is authorized to access the network nodes 202A, 202B and/or 202E. In another example, the access credentials of a certain client device 204B may define that the client device 204B is authorized to access the network nodes 202D, 202E and/or 202F. In another example, the access credentials of a certain client device 204C may define that the client device 204A is authorized to access the network nodes 202G and/or 202H.

The access credentials defining the access rights of the respective client device 204 or the access rights of a user using the respective client device 204 may be extracted (obtained) from one or more credentials records maintained to associate the plurality of client devices 204 and/or the users using the client devices 204 with respective access rights. For example, one or more credential records may be locally stored in the gateway 206 such that the VPN manager 210 may locally access this credential record(s) to extract the access credentials of the respective client device 204. In another example, one or more credential records may be stored in one or more of the network nodes 202 such that the VPN manager 210 may access this credential record(s) by communicating with the respective network node(s) 202 via the local network 220 to extract the access credentials of the respective client device 204. In another example, one or more credential records may be stored in one or more remote networked resources accessible to the VPN manager 210 via the external network 230 for extracting the access credentials of the respective client device 204.

As shown at 106, the VPN manager 210 may create a plurality of sub-networks 250 where each of the sub-networks 250 is created for a respective one of the plurality of client devices 204 which initiated the VPN link requests. In particular, the VPN manager 210 creates the plurality of sub-networks 250 according to the access credentials (access rights) identified for each of the client devices 204 requesting to establish the respective VPN link.

Continuing the previous examples, since the client device 204A is authorized to access the network nodes 202A, 202B and/or 202E, the VPN manager 210 may create for the client device 204A a sub-network 250A comprising a subset of member network nodes 202, in particular, the network nodes 202A, 202B and 202E. In another example, since the client device 204B is authorized to access the network nodes 202D, 202E and/or 202F, the VPN manager 210 may create for the client device 204B a sub-network 250B comprising another subset of member network nodes 202, in particular, the network nodes 202D, 202E and 202F. In another example, since the client device 204N is authorized to access the network nodes 202G and/or 202H, the VPN manager 210 may create for the client device 204N a sub-network 250N comprising another subset of member network nodes 202, in particular, the network nodes 202G and 202H.

As shown at 108, for each of the client devices 204 which initiated the VPN link requests, the VPN manager 210 may assign a client virtual (network) address to the respective client device 204 and to a server virtual address to the network node(s) 202 included in the sub-network 250 created for the respective client device 204.

In particular, the VPN manager 210 assigns the (client and server) virtual addresses in an address range which does conflict with an address range of local addresses assigned in the network nodes 202 in the service network 200. Moreover, the virtual addresses assigned by the VPN manager 210 for each of the client devices 204 are assigned in an address range which does not conflict with a local address range of addresses assigned in an origin network to which the respective client device 204 is connected for connecting to the network 230 and through the network 230 to the gateway 206.

The virtual addresses are assigned in the non-conflicting address range in order to prevent mapping and/or routing issues resulting from client and/or server virtual (network) addresses assigned to one or more of the client devices 204 and/or the network nodes 202 which overlap with local (network) address(s) assigned in the local network 220. Similarly, the virtual (network) addresses are assigned for each client device 204 in the non-conflicting address range in order to prevent overlapping of the virtual addresses with local (network) address(s) assigned in the origin network to which the respective client device 204 is connected.

The mapping, addressing and/or routing protocols, schemes and/or mechanisms of modern networks are typically based on Internet Protocol (IP) addresses according to one or more protocols, for example, IPv4, IPv6 and/or the like. The local (network) addresses assigned in the local network 220 as well as in the external network 230 comprising the origin network(s) of the client devices 204 may therefore typically be IP addresses. In order to maintain full compliance with the existing addressing schemes and allow for easy integration and/or migration, the virtual addresses may also be IP addresses, for example, IPv4, IPv6 and/or the like.

The virtual addresses assigned by the VPN manager 210 may be assigned in one or more virtual address ranges selected and/or defined according to one or more techniques and/or implementations.

For example, the virtual address range may be predefined and uniquely assigned for use by the VPN manager 210 in the service network 220. Since such a virtual address range is uniquely assigned for use in the service network 200, there is no concern for conflicting addresses with the local addresses in the local network 220 and/or the external network 230 including the origin network(s) to which the client devices 204 are connected.

In another example, the virtual address range may be selected in one or more address ranges which are arbitrary and/or randomly selected by the VPN manager 210. Since it is arbitrary and/or randomly selected, the probability that such a virtual address range conflicts with the local addresses in the local network 220 and/or the origin network(s) is significantly reduced and is practically insignificant.

In another example, the VPN manager 210 may communicate (hand-shake) with one or more of the client devices 204 and explore the address range(s) of the origin network(s) of the respective client device(s) in order to negotiate the address range in which the virtual addresses are assigned. After determining the address range used in the origin network(s), the VPN manager 210 may therefore select the virtual address range such that the virtual address range does not conflict with the address range(s) assigned in the origin network(s) thus preventing the addresses overlapping. Moreover, the VPN manager 210 may assign the virtual addresses in an address range used by one communication protocol while assigning the local addresses in a different address range used by another communication protocol. For example, assuming the local address range used in service network 200 is complaint with the IPv4 protocol such that the network nodes 202 are mapped in the local network 220 with addresses according to the IPv4 protocol. However, the VPN manager 210 may assign the client virtual address and the respective server virtual address to one or more of the client devices 204 in an address range complaint with the IPv6 protocol. In another example, assuming the local address range used in service network 200 is complaint with the IPv6 protocol such that the network nodes 202 are mapped in the local network 220 with addresses according to the IPv6 protocol. However, the VPN manager 210 may assign the client virtual address and the respective server virtual address to one or more of the client devices 204 in an address range complaint with the IPv4 protocol.

As described herein after the VPN manager 210 manages the mapping, addressing and/or routing of the network traffic (i.e. messages, packets) exchanged via each of the VPN links between each respective client device 204 and the network node(s) 202 included in the sub network 250 (members) of the respective client device 204. Specifically, the VPN manager 210 manages the network traffic exchanged over each of the plurality of VPN links independently from the network traffic exchanged over each of the other VPN links such that the plurality of sub networks 250 are isolated from each other.

The VPN manager 210 may assign unique client virtual addresses to each of the client devices 204 which initiated the VPN link as well as unique server virtual addresses to the network nodes 202 in each of the sub-networks 250. The VPN manager 210 may use a single virtual address range or multiple virtual address ranges. However, due to the independent and isolated management of the VPN links, the VPN manager 210 may assign overlapping client virtual addresses to multiple client devices 204 and/or overlapping server virtual addresses to multiple network nodes 202 included in different sub-networks 250. Using the overlapping virtual addresses may serve to maintain a relatively small virtual address range.

As shown at 110, the VPN manager 210 may establish the plurality of VPN links with the plurality of client devices 204 which initiated the VPN link requests. In particular, the VPN manager 210 establishes each of the VPN links with a respective one of the client devices 204 for accessing the network node(s) 202 included in the sub-network 250 created for the respective client device 204. To this end, the VPN manager 210 may provide (transmit) to each client device 204 the client virtual address assigned to the respective client device 204 and the server virtual address(s) assigned to the network node(s) 202 included in the sub-network 250 created for the respective client device 204. Moreover, the VPN manager 210 may assign a client local address to each of the client devices 204 in the local address range of the local address 220 for mapping the client devices 204 in the local network 220. As described herein before for the virtual addresses, while the VPN manager 210 may assign a unique client local address to each of the client devices 202, since the VPN manager 210 manages each VPN link independent desolated from the other VPN links, the VPN manager 210 may assign overlapping and/or similar client local addresses to multiple client devices 204.

For incoming network traffic transmitted by the client devices 204 via the VPN links to the network nodes 202, each client device 204 may use its assigned virtual address and the virtual address(s) assigned to the network node(s) 202 of its sub-network 250 for transmitting messages (packets) to the network node(s) 202 via the gateway 206. Specifically, each client device 204 may set its virtual address as the source address and the virtual address of a destination network node 202 as the destination address in each message the respective client device 204 transmits to the gateway 206.

Similarly, on the response path, i.e. outgoing network traffic transmitted to the client devices 204, the gateway 206, specifically the VPN manager 210 may use the virtual address assigned to each client device 204 for transmitting to the respective client device 204 messages (packets) received from a certain network node 202. Specifically, the VPN manager 210 may set the virtual address of the certain network node 202 as the source address and the virtual address of the respective client device 204 as the destination address in each message transmitted to the respective client device 204.

As shown at 112, after each VPN link is established with a respective client device 204, the VPN manager 210 manages (controls) mapping, addressing and/or routing of the network traffic exchanged between the respective client device 204 and the network node(s) 202 included in the sub-network 250 created for the respective client device 204. The VPN manager 210 may manage the network traffic by translating the virtual addresses to local addresses for the incoming network traffic messages and vice versa, translating the local addresses to virtual addresses for the outgoing network traffic messages as follows. The VPN manager 210 may control incoming network traffic of messages received from each client device 204 and destined to a member of the its respective sub-network 250 by adjusting each incoming message as follows:

- Adjust the source address (field) of the incoming message comprising the client virtual address of the respective client device 204 to the client local address of the respective client device 204.

- Adjust the destination address (field) of the incoming message comprising the server virtual address of one of the member network nodes 202 of the sub-network 250 created for the respective client device 204 to the (server) local address of the respective member network node 202.

Forward the incoming adjusted message to the respective member network node 202.

Complementary, the VPN manager 210 may control outgoing network traffic of messages received from member network nodes 202 of sub-networks 250 and destined to one of the client devices 204 by adjusting each outgoing message as follows:

- Adjust the source address (field) of the respective outgoing message comprising the server local address of the respective member network node 202 to the server virtual address of the respective member network node 202.

- Adjust the destination address (field) of the outgoing message comprising the client local address of the respective client device 204 to the client virtual address of the respective client device 204.

- Forward the outgoing adjusted message to the respective client device 204.

On the incoming network traffic path, the VPN manger 210 may easily associate each incoming message with a respective one of the client devices 204 since the VPN manger 210 managing all the VPN links established with all client devices 204 may correlate the respective incoming message with the respective client device 204 according to the VPN link via which the respective incoming message is received.

On the outgoing network traffic, however, the VPN manager 210 may need to apply one or more techniques to identify a destination client device 204 destined as the target (recipient) of each outgoing message transmitted by one of the network nodes 202.

As described herein before, in some embodiments of the present disclosure, each client device 204 is assigned a unique client local address. In such case, the VPN manager 210 may associate each outgoing messages with a respective destination client device 204 according to the unique client local address included in the outgoing message.

However, in some embodiments of the present disclosure multiple client devices 204 may be assigned a similar client local address which may present a challenge in identifying which of the multitude of client devices 204 sharing the same client local address is the destination of each outgoing message. To resolve this ambiguity, the VPN manager 210 may apply one or more session and/or connection tracking protocols as known in the art to track the session/connection of each of the client devices 204 with the network node(s) 202. Specifically, the VPN manager 210 may track the session/connection of each of the client devices 204 sharing a common client local address with one or more other client devices 204. Based on the identification of the session and/or the connection of each such client device 204, the VPN manager 210 may associate each outgoing message with a respective (specific) client device 204.

Optionally, in some embodiments of the present disclosure, there may be a combination of address assignment where one or more of the client devices 204 may be assigned a unique client local address while one or more groups of other client devices 204 may share one or more similar client local addresses. In such case, the VPN manager 210 may associate outgoing messages destined to the uniquely address assigned client device(s) 204 according to the unique local address(s) while associating outgoing messages the client devices 204 sharing a common client local addresses based on the session/connection tracking.

Moreover, as described herein before, the VPN manager 210 may assign the virtual addresses and the local addresses in different address range, which are compliant and used by different communication protocols, for example, IPv4, IPv6 and/or the like. In such case, when adjusting the source ad destination addresses in the incoming and/or outgoing network traffic messages, the VPN manager 210 may convert the virtual addresses assigned in one address range used by a first protocol to local addresses in another address range used by a second protocol and vice versa. For example, assuming the local address range used in service network 200 is complaint with the IPv4 protocol where the addresses of the network nodes 202 are assigned according to the IPv4 protocol while the client and server virtual addresses are assigned in an address range according to the IPv6 protocol. In such case, on the incoming network traffic path, the VPN manager 210 may convert the virtual addresses from the IPv6 address range to the local addresses in the IPv4 address space and vice versa, on outgoing network traffic path, the VPN manager 210 may convert the local addresses from the IPv4 address range to the virtual addresses in the IPv6 address range. In another example, assuming the local address range used in service network 200 is complaint with the IPv6 protocol where the addresses of the network nodes 202 are assigned according to the IPv6 protocol while the client and server virtual addresses are assigned in an address range according to the IPv4 protocol. In such case, on the incoming network traffic path, the VPN manager 210 may convert the virtual addresses from the IPv4 address range to the local addresses in the IPv4 address space and vice versa, on outgoing network traffic path, the VPN manager 210 may convert the local addresses from the IPv6 address range to the virtual addresses in the IPv4 address range.

Reference is now made to FIG. 3, which is a schematic illustration of an exemplary sequence for initializing a private sub-network for a VPN client and managing traffic exchanged between the VPN client and a network node, according to some embodiments of the present disclosure. An exemplary sequence 300 may be followed to establish a VPN link via a gateway such as the gateway 206 between a client device such as the client device 204 and a network node such as the network node 202 connected to a local network such as the local network 220 of a service network such as the service network 200. The gateway 206 may execute, utilize and/or implement a VPN manager such as the VPN manager 210. The network node 202 may be mapped in the local network 220 with a local address Z.

As seen, the sequence 300 starts with a configuration phase initiated when the gateway 206, specifically the VPN manager 210 receives from the client device 204 a request to establish a VPN link with the service network 200. In response to the VPN link request, the VPN manager 210 creates for the client devices 204 an isolated private sub-network comprising one or more network nodes 202 authorized for access by the client device 204 as defined by access credentials of the client device 204 as described in steps 104 and 106 of the process 100. The private sub network created for the client device 204 is isolated from any other sub-networks which may be created for other client devices 204 that may be currently connected via other VPN links to the service network 200.

In particular, the VPN manager 210 assigns a client virtual address V to the client device 204 and a server virtual address Y to the network node 202 which, based on the access credentials of the client device 204, is determined to be accessible to the client device 204. The VPN manager may further assign a local client address A to the client device 204 mapping the client device 204 in the local network 220 of the service network 200.

The VPN manager 210 may then establish the VPN link with the client device 204 by transmitting the client virtual address V and the server virtual address Y to the client device 204 as described in step 110 of the process 100. Once the VPN link is established, on the incoming network traffic path, the client device 204 may access the network node 202 by transmitting one or more messages to the network node 202. The client device 204 may construct the incoming messages to include the virtual addresses assign to it by the VPN manager 210 for designating itself as the source (originator) of the message(s) and mapping the network node 202 as the destination of the message(s). In particular, the client device 204 may set the source and destination addresses of the message(s) to include the client virtual address V and the server virtual address Y respectively.

The VPN manager 210 receiving the incoming message(s) from the client device 204 may adjust each received message to convert the source and destination virtual addresses to the corresponding local addresses. Specifically, the VPN manager 210 may convert the source address from the client virtual address V to the client local address A and the destination address from the server virtual address Y to the server local address Z.

The gateway 206 may then forward the adjusted (converted) incoming message(s) to the network node 202 via the local network 220.

On the response path, i.e. the outgoing network traffic path, the network node 202 may respond to the client device 204 with one or more outgoing messages transmitted to the client device 204 via the VPN link through the gateways 206. The network node 202 which is naturally oblivious to the address translation done for the client device 204 uses the local addresses for mapping the outgoing message(s), i.e. the server local address Z as the source address and the client local address A (retrieved from the incoming message(s)) as the destination address.

The VPN manager may adjust each outgoing message received from the network node 202 to convert the source and destination addresses according to the virtual addresses assigned for the sub-network created for the client device 204. Specifically, the VPN manager 210 may convert the source address from the server local address Z to the server virtual address Y and the destination address from the client local address A to the client virtual address V.

The gateway 206 may then transmit the adjusted (converted) outgoing message(s) to the client device via the VPN link established with the client device 204.

One or more of the network nodes 202 and/or one or more services provided by the network node(s) 202 may be mapped in the external network 230 with names and/or designators, in particular, URIs, for example, URLs. The service network 200 may be therefore deployed with one or more DNS controllers such as the DNS controller 208 configured to resolve and translate URLs of one or more of the network nodes 202 to the local network addresses of these network nodes 202, i.e. to the server local addresses.

In such cases, the VPN manager 210 may extend the isolated sub-network of one or more of the client devices 204 to include the DNS controller(s) 208 in order to enable the client device(s) 204 to access the DNS controller(s) 208 in order to first resolve the URI of each target network node 202 and obtain the server network address of the respective target network node 202.

For example, the DNS controller 208 may respond to the DNS resolution request received from the client device 204 with one or more DNS response messages comprising the server virtual address of the respective target network node 202, which is the target of the client device 204. In another example, the DNS controller 208 may respond to the DNS resolution request received from the client device 204 with one or more DNS response messages comprising the local address of the target network node. The VPN manager 210 receiving the DNS response message(s) may then assign this target network node with a server virtual address that is transmitted to the client device 204 via the VPN link. The VPN manager 210 may further associate the assigned server virtual address with the local address of this target network node 202 in order to control the incoming and/or outgoing network traffic and adjust the exchanged messages accordingly.

After obtaining the server virtual address of the target network node 202, the client device 204 may use the acquired server virtual address to access this target network node 202 as described in the process 100.

Reference is now made to FIG. 4, which is a schematic illustration of an exemplary sequence for initializing a private sub-network for a VPN client using a DNS controller and managing traffic exchanged between the VPN client and the DNS controller and a network node, according to some embodiments of the present disclosure. An exemplary sequence 400 may be followed to establish a VPN link via a gateway such as the gateway 206 between a client device such as the client device 204 and a network node such as the network node 202 connected to a local network such as the local network 220 of a service network such as the service network 200 where a DNS controller such as the DNS controller 208 resolves URIs of one or more of the network nodes 202. The gateway 206 may execute, utilize and/or implement a VPN manager such as the VPN manager 210. The network node 202 may be mapped in the local network 220 with a local address Z while the DNS controller 208 is mapped in the local network 220 with a local address D. As seen, the sequence 400 starts with a configuration phase initiated when the gateway 206, specifically the VPN manager 210 receives from the client device 204 a request to establish a VPN link with the service network 200. In response to the VPN link request, the VPN manager 210 creates for the client devices 204 an isolated private sub-network comprising one or more network nodes 202 authorized for access by the client device 204 as defined by access credentials of the client device 204 as described in steps 104 and 106 of the process 100. The VPN manager 210 further includes the DNS controller 208 in the isolated sub-network created for the client device 204. As described herein before, the private sub-network created for the client device 204 is isolated from any other sub-networks, which may be created for other client devices 204 that may be currently connected via other VPN links to the service network 200.

In particular, the VPN manager 210 assigns a client virtual address V to the client device 204 and a DNS virtual address X to the DNS controller 208. The VPN manager may further assign a local client address A to the client device 204 mapping the client device 204 in the local network 220 of the service network 200.

The VPN manager 210 may then establish the VPN link with the client device 204 by transmitting the client virtual address V and the DNS virtual address X to the client device 204 as described in step 110 of the process 100.

Once the VPN link is established, the client device 204 having only the URI of the network node 202 may first need to obtain the server address of the network node 202. The client device 204 may therefore access the DNS controller 208 via the VPN link using the DNS virtual address in attempt to resolve the URI of the network node 202. In particular, the client device 204 may set the source and destination addresses of the (incoming) message(s) directed to the DNS controller 208 to include the client virtual address V and the server virtual address Y respectively. The client device 204 may further include the URI, for example, the URL of the network node 202, which is the target of the access made by the client device 204 to the service network 200.

The VPN manager 210 receiving the incoming DNS message(s) from the client device 204 may adjust each received DNS message to convert the source and destination virtual addresses to the corresponding local addresses. Specifically, the VPN manager 210 may convert the source address from the client virtual address V to the client local address A and the destination address from the DNS controller virtual address X to the server local address D.

The gateway 206 may then forward the adjusted (converted) incoming DNS message(s) to the DNS controller 208 via the local network 220. In response, the DNS controller may respond to the client device 204 with one or more outgoing DNS messages transmitted to the client device 204 via the VPN link through the gateways 206 which may include the server virtual address Y of the target network node 202 resolved according to the URI and/or URL received in the DNS message(s) from the client device 204. The DNS controller 208 may use the local addresses for mapping the outgoing DNS message(s), i.e. the local address D as the source address and the client local address A (retrieved from the incoming message(s)) as the destination address.

The VPN manager 210 may adjust each outgoing DNS message received from the DNS controller 208 to convert the source and destination addresses according to the virtual addresses assigned for the sub-network created for the client device 204. Specifically, the VPN manager 210 may convert the source address from the DNS local address D to the DNS virtual address X and the destination address from the client local address A to the client virtual address V.

The gateway 206 may then transmit the adjusted (converted) outgoing DNS message(s) to the client device via the VPN link established with the client device 204.

From this point the sequence 400 may be very similar to the sequence 300.

The client device 204 using the server virtual address received in the DNS outgoing message(s) from the DNS controller 208 may now transmit one or more (incoming) messages, via the VPN link, to the network node 202. In particular, the client device 204 may set the source and destination addresses of the incoming message(s) to include the client virtual address V and the server virtual address Y respectively.

The VPN manager 210 receiving the incoming message(s) from the client device 204 may adjust each received message to convert the source and destination virtual addresses to the corresponding local addresses. Specifically, the VPN manager 210 may convert the source address from the client virtual address V to the client local address A and the destination address from the server virtual address Y to the server local address Z.

The gateway 206 may then forward the adjusted (converted) incoming message(s) to the network node 202 via the local network 220.

On the response path, i.e. the outgoing network traffic path, the network node 202 may respond to the client device 204 with one or more outgoing messages transmitted to the client device 204 via the VPN link through the gateways 206. The network node 202 may use the local addresses for mapping the outgoing message(s), i.e. the server local address Z as the source address and the client local address A as the destination address.

The VPN manager 210 may adjust each outgoing message received from the network node 202 to convert the source and destination addresses according to the virtual addresses assigned for the sub-network created for the client device 204. Specifically, the VPN manager 210 may convert the source address from the server local address Z to the server virtual address Y and the destination address from the client local address A to the client virtual address V.

The gateway 206 may then transmit the adjusted (converted) outgoing message(s) to the client device via the VPN link established with the client device 204.

Moreover, the service network 200 deployed over the local network 220, in particular the DNS controller(s) 208 may further apply one or more leasing protocols to release the virtual address assigned to one or more of the client device 204 in case there is no access made by this client device(s) 204 within a predefined lease period of time for example, 300 seconds. For example, assuming a certain client device 204 accessed the DNS controller 208 in request to obtain the network address of a certain target network node 202. As described herein before, this request is responded by the DNS controller and the adjusted by the VPN controller to provide the server virtual address of the certain target network node 202 to the certain client device 204.

Using the server virtual address of the certain target network node 202 obtained from the DNS controller 208, the certain client device 204 may communicate and access the certain target network node 202. However, in case, while communicating with the target network node 202, the client device 204 fails to perform two consecutive accesses the target network node 202 within the predefined lease time, the DNS controller 208 may revoke the server virtual address assigned to the target network node 202 for use by the client device 204. In such case, the client device 204, in attempt to access the target network node 202 again, may initiate another cycle with the DNS controller 208 to obtain the server virtual address of the target network node 202 which may be changed after the lease was revoked.

Furthermore, in case dynamic address allocation is applied in the service network for mapping the network nodes 202 over the local network 220, when assigning the client local address to one or more of the client devices 204, the VPN manager 210 may access one or more Dynamic Host Configuration Protocol (DHCP) controllers to obtain the client local address. Moreover, in such a dynamic addressing deployment, the local addresses of one or more of the network nodes 202 may also change, for example, after restart, after power-down and/or the like. In such case, specifically in case the VPN manager 210 assigns the server virtual address as described in the sequence 300, the VPN manager 210 using a predefined name uniquely designating each of the network nodes 202 may access the DNS controller 208 to obtain the server local address of one or more network nodes 202 which are the target of one or more of the client devices 204. The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant technologies will be developed and the scope of the terms virtual networking, VPN, virtual node and virtual switch are intended to include all such new technologies a priori. As used herein the term “about” refers to ± 10 %.

The terms "comprises", "comprising", "includes", "including", “having” and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of' and "consisting essentially of'.

The phrase "consisting essentially of' means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof. The word “exemplary” is used herein to mean “serving as an example, instance or illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments. The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment of the disclosure may include a plurality of “optional” features unless such features conflict.

Throughout this application, various embodiments of this disclosure may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the disclosure. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals there between.

It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the disclosure. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present disclosure. To the extent that section headings are used, they should not be construed as necessarily limiting. In addition, any priority document(s) of this application is/are hereby incorporated herein by reference in its/their entirety.