Load balancing for VPN traffic

Abstract

In some examples, a load balancer establishes secure connections between itself and multiple destination servers in a trusted network and performs load balancing of encrypted virtual private network (VPN) traffic across these destination servers. The load balancer receives an encrypted data packet from a client device. This encrypted packet includes a VPN message header with a destination identification field that identifies a destination server in the trusted network. The load balancer then determines whether a selected destination server in the trusted network is identified based on the value of the destination identification field in the VPN message header, where the selected destination server is one of a plurality of destination servers.Based on the determination that the selected destination server is identified based on the value of the destination identification field in the VPN header, the load balancer sends the encrypted data packet to the selected destination server.

Description

Cross-Reference to Related ApplicationThis application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 63 / 516,664, filed July 31, 2023, which is hereby incorporated by reference.BackgroundIn network information, secure network protocol suites enable secure communication between clients and servers over a public network, such as the Internet. This is advantageous because public networks are not secure and therefore pose a security risk. Public networks also form a major part of the backbone of world wide communications and are therefore frequently used.Brief Description of the DrawingsSome embodiments of the present disclosure will be described with reference to the following drawings. FIG. 1 is a block diagram of an arrangement including a client device, a load balancer, a trusted network, and a secure network environment, in accordance with some examples. FIG. 2 is a block diagram of an encrypted data packet with a WireGuar segment, according to some examples. FIG. 3 is a block diagram of a storage medium storing machine readable instructions, according to some examples. FIG. 4 is a block diagram of load balancing, in accordance with some examples. FIG. 5 is a flow diagram of a load balancing process, in accordance with some examples.In the drawings, identical reference numerals designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated for ease of illustration of the example shown. Moreover, the drawings include examples and / or embodiments consistent with the description; however, the description is not limited to the examples and / or embodiments illustrated in the drawings.Detailed DescriptionIt is important to note that the embodiments disclosed herein are only examples of the many advantageous uses of the innovative teachings contained herein. In general, the statements made in the specification of the present application do not necessarily limit any of the various claimed embodiments. In addition, some statements may apply to some inventive features, but may not apply to others. In general, unless otherwise indicated, individual elements may be plural and vice versa without the generality suffering. In the drawings, like numerals refer to like parts throughout the several views.A trusted network uses a security model that establishes trust by continuously authenticating and monitoring each network access attempt by entities such as users, devices, and programs. The entities are not trusted implicitly or by default (e.g., when the entities access the network from a local area network that is believed to be more secure than an external network). Rather, the entities must be validated each time they are network accessed before they can be granted network access.The trusted network comprises destination servers, which are computing units (physical servers or virtual servers) with which devices that wish to access destination endpoints via the trusted network can establish secure connections. In some examples, virtual private networks (VPNs) may be deployed with the destination servers to transmit encrypted data packets that are protected from unauthorized access. When VPNs are used, the destination servers may also be referred to as VPN backend servers. The use of VPNs can pose problems related to load balancing of VPN traffic across multiple destination servers of the trusted network. Load balancing aims to distribute the load to several destination servers in order to reduce the probability that a destination server of the zero trust network will be overloaded with VPN traffic. Encrypted data packets are transmitted in VPNs. If the encrypted data packets need to be decrypted for load balancing, this may increase the workload of load balancing because decryption operations consume significant processing resources.In some cases, a transport protocol such as the User Datagram Protocol (UDP) may be used for the transmission of data packets in VPNs. UDP is a connectionless protocol that allows the transport of data packets over a network without establishing connections between endpoints. However, when using UDP, it may be difficult to maintain the affinity of data packets of a particular client device with a particular destination server when load balancing is performed across connections to multiple destination servers. Maintaining affinity refers to the preference for communicating data packets from a particular client device with a particular destination server as compared to other destination servers. The affinity may improve efficiency because the particular destination server may maintain state information for communication with the particular client device while other destination servers may not have this state information.According to some implementations of the present disclosure, a load balancer is used to provide load balancing of VPN traffic across multiple destination servers of a trusted network, where the load balancing aims to distribute the VPN traffic across the multiple destination servers while also taking into account the selection of destination servers made by a client device. In some examples of the present disclosure, selection of a destination server by the client device is indicated using a field in a VPN message header of an encrypted data packet. The field in the VPN message header can be accessed by the load balancer without having to decrypt the encrypted data packet. Different values of the field represent unique identifiers of the multiple destination servers of the trust network. The VPN message header field contains load balancing metadata that affects how the load balancer forwards encrypted data packets.If a destination server identifier is not included in a VPN message header of a first data packet, the load balancing algorithm may be applied to distribute the first data packet to a destination server selected by the load balancing algorithm. Load balancing may be done by the load balancing algorithm without decrypting encrypted data packets in VPNs. For example, the load balancing algorithm may include one or more of the following algorithms: a round robin algorithm that selects destination servers according to the round robin principle; a random selection algorithm that randomly selects a destination server from a plurality of destination servers; a weighted selection algorithm that assigns weights to the destination servers and selects the destination servers based on the weights; a selection algorithm that considers metrics of the destination servers, such as metrics related to processing resource usage or performance, memory usage or performance, communication resource usage or performance, and so forth. The load balancer is capable of adapting to changing conditions, such as conditions of destination servers of the trust network based on the metrics, by distributing the VPN traffic based on the conditions of the destination servers.On the other hand, if a value representing an identifier of a destination server ("identified destination server") is included in a VPN message header of a second data packet, then the load balancer would forward the second data packet to the identified destination server instead of applying the load balancing algorithm. Membership in the respective destination servers can be maintained by allowing the client devices to include values representing identifiers of destination servers in the fields of VPN headers so that the load balancer forwards packets containing the identifiers of destination servers to the specific destination servers identified.As used herein, a "trusted network" may refer to a network environment in which a computing device authorizes access requests from client devices. An example of a trusted network is a trusted-free network. A "destination server" in the trusted network refers to a resource of the trusted network with which a secure connection can be established. In some examples, the destination server may also be capable of performing the authorization of access requests. Alternatively, the destination server may forward an access request to another entity in the trusted network to perform the authorisation. Examples of destination servers are any one or a combination of the following elements: an access portal server, a virtual computing unit such as a container (e.g. a Kubernetes container) or a VM, a serverless function or another type of resource.An access request may include a control message transmitted by a requester to establish a connection to a destination endpoint. In other examples, an access request may include a data packet transmitted by the requester to reach the destination endpoint. In some examples, a destination server may also be referred to as a front-end server or a VPN back-end server.For the secure communication, a secure communication protocol such as the Internet Protocol Security (IPSec) protocol may be used. In some examples, IPSec may be used to secure communication in VPNs. With IPSec as the tunnelling protocol, a secure network tunnel can be established. The IPSec network tunnel protects communication in a VPN. In the communication of data over an IPSec network tunnel, an encryption algorithm is used to encrypt the data of a data packet (e.g., an Internet Protocol (IP) packet). The encrypted data packet is wrapped in outer headers including an authentication header (AH) or an encapsulating security payload (ESP) header.In other examples, various secure communication protocols may be used for VPNs. An example of another secure communication protocol is the WireGuar protocol, an open source protocol which builds on UDP. In further examples, other secure communication protocols (such as OpenVP) may be used for VPNs.When using VPNs that implement one of the above-mentioned secure communication protocols (e.g. IPSec, WireGuar, OpenVP etc.), load balancing becomes a challenge because it is computationally intensive to decrypt encrypted data packets in order to distribute them to the destination servers of a trust network within the framework of load balancing. In addition, the decryption of encrypted data packets in VPNs poses security risks, since the decrypted data packets could become accessible to attackers at the load balancer. On the other hand, if the load balancer is unable to decrypt encrypted data packets routed through the load balancer, the load balancer may not be able to determine where to route the data packets.As mentioned above, a VPN message header may be used to indicate how a data packet is to be handled by the load balancer. The VPN message header of an encrypted data packet is not encrypted, i.e. the VPN message header is accessible to the load balancer without the encrypted data packet having to be decrypted. This allows end-to-end encryption and data protection to be maintained while load balancing by the load balancer continues to be possible. A field in the VPN message header may refer to any collection of bits that can be set to one of multiple values. A "VPN message header" may refer to a header of an encrypted data packet transmitted in a VPN, the header containing information accessible without decryption. In examples where WireGuar is employed, the VPN message header may be a WireGuar header according to the WireGuar protocol.A WireGuar header contains various fields, including a reserved field that is not defined for a particular purpose in the current version of the WireGuar protocol. In accordance with some examples of the present disclosure, the reserved field of the WireGuar header may be used to determine how a load balancer is to forward an encrypted data packet in a VPN. The reserved field contains a predetermined number of reserved bits. If the reserved field is set to a first value (e.g., "0" or another value), this means that a requester that transmitted the encrypted data packet did not select a destination server of the trusted network. In this case, the load balancer applies a load sharing algorithm to select the destination server in the trusted network to which the encrypted data packet is sent. However, if the reserved field is set to another value representing an identifier of a destination server, the load balancing algorithm would forward the encrypted data packet to the identified destination server. Having to decrypt an encrypted data packet in a VPN to determine where the load balancer is to forward the encrypted data packet is advantageous because it maintains the security of the VPN and reduces the computational load of the load balancer, while also allowing the distribution of data packets for load balancing purposes and maintaining the affinity of data packets of a particular client device to a particular destination server by consistently routing the data packets of the particular client device to the particular destination server.FIG. 1 is a block diagram of an example arrangement having a client device 110 communicating with destination servers 152 and 154 in a zero trust network 150 via a load balancer 130. The load balancer 130 may be implemented with one or more computers. The client device 110 may be a router, gateway, or other type of network device through which electronic devices may be connected to other endpoints. More generally, the client device 110 includes a computing device. A computing device may be a personal computing device, a mobile phone, a smartphone, a tablet, a laptop, or other electronic device. Although a null trust network is referred to in some examples, other types of trust networks may also be used in other examples. In some examples, the client device 110 initiates communication with the null trusted network 150 to gain access to a target resource in a secure network environment 160 that is not directly accessible to the client device 110. As shown in FIG. 1, the client device 110 establishes a client-side secure network tunnel 120 with the load balancer 130.In examples where there are a plurality of client devices, a plurality of client-side secure network tunnels may be established between the load balancer 130 and the plurality of client devices such that each client device has its own client-side secure network tunnel with the load balancer 130. Establishing separate client-side secure network tunnel between load balancer 130 and the plurality of client devices is more secure than sharing a client-side secure network tunnel by the plurality of client devices. For example, a common secure client-side network tunnel may mean that the multiple client devices share a key used to encrypt the traffic transmitted in the common secure client-side network tunnel, which is less secure. If one client device out of the plurality of client devices using the same key is compromised, communication would be compromised for each of the other client devices using the key.In some examples, the client device 110 communicates over an unsecured network, e.g., the Internet. To protect communication of sensitive data over the non-secure network that is transmitted to or from a target server 164 in the secure network environment 160, the client device 110 is configured to communicate with the target server 164 over the zero trust network 150. The target server 164 may be an application server, a web server, a cloud server, or another type of target resource. Although only one target server 164 is shown in FIG. 1, in other examples, the secure network environment 160 includes multiple target servers. In further examples, trusted network 150 may also provide protected access to target servers in multiple secure network environments.In some examples, trusted-free network 150 provides various security services. Thus, trusted network 150 (e.g., destination servers 152, 154) may provide any or a combination of the following services: a remote desktop protocol (RDP) service between client device 110 and target server 164, a secure shell access (SSH) to target server 164, an isolated SSH access to target server 164, a secure web gateway (SWG) (that filters the data traffic, passes policies, and guarantees compliance with policies), or other services.The client device 110 transmits a data packet (destined for the target server 164) to the load balancer 130 via the client-side secure network tunnel 120. The destinations of the data packets may include one or more destination servers in the secure network environment 160. The sources (originators) of the data packets may include one or more requesters 170. A "requester" may refer to an entity, e.g., a physical electronic device or a virtual computing device, that can access a target resource.In some examples, the load balancer 130 initiates multiple server-side secure network tunnels 142, 144 with the zero trust network 150. Each server-side secure network tunnel is established between the load balancer 130 and a corresponding destination server of the zero trust network 150. For example, the server-side secure network tunnel 142 is established between the load balancer 130 and the destination server 152, and the server-side secure network tunnel 144 is established between the load balancer 130 and the destination server 154. Each server-side secure network tunnel 142 or 144 may be built with IPSec. Note that it is possible to establish multiple secure network tunnels between the load balancer 130 and any destination server.In an example, a destination server 152 or 154 of the zero trust network 150 may provide a security service (such as an RDP service, SSH service, a SWG service, or other service) between the client device 110 and the target server 164. The destination server 152 or 154 establishes the service by communicating with a backend server 156 of the zero trust network 150. A "backend server" may refer to a server in the zero trust network 150 that is responsible for communicating with a network environment (e.g., the secure network environment 160) that includes target resources to be accessed by the requesters 170. The backend server 156 may communicate with a connector 162 in the secure network environment 160. In an example, the connector 162 forwards data packets between the trusted network 150 and the target resources (including the destination server 164) of the secure network environment 160.In some examples, the load balancer 130 is deployed in the zero trust network 150 or outside the zero trust network 150. In further examples, a plurality of load balancers 130 may be employed. In examples where the trusted network 150 includes the load balancer 130 deployed therein, a secure network tunnel would not need to be established between the load balancer 130 and a destination server 152 or 154 in the trusted network 150. In such examples, the connections between the load balancer 130 and the destination servers are implicitly secured in the zero trust network 150. In other examples, when the load balancer 130 is located outside the trusted network 150, a server-side secure network tunnel is established between the load balancer 130 and a resource of the trusted network 150, e.g., a destination server.In accordance with some examples of the present disclosure, the load balancer 130 includes a VPN message header parser (VMH) 146 to read VPN headers of incoming scrambled data packets that the load balancer 130 receives from one or more client devices. The VMH parser 146 may be implemented with one or more hardware processing circuits or machine readable instructions of the load balancer 130. An encrypted data packet 122 transmitted in a VPN between a requester 170 and the target server 164 is received by the load balancer 130. The VMH parser 146 may read a VPN message header (VMH) 124 in the encrypted data packet 122, without having to decrypt the encrypted data packet 122. The VPN message header 124 is part of the plain text of the encrypted data packet 122.The VMH parser 146 is capable of reading a reserved field in the VPN message header 124 to determine how to forward the encrypted data packet 122 to the trusted network 150. As mentioned above, if the reserved field is set to a first value (e.g., "0" or another value), this means that a requester (e.g., 170) that transmitted the encrypted data packet did not select a destination server of the trusted network. In this case, the load balancer 130 applies a load balancing algorithm to select the destination server in the trusted network to which the encrypted data packet is sent. However, if the reserved field is set to another value representing an identifier of a destination server, then the load balancing algorithm 130 would route the encrypted data packet to the identified destination server.The destination server 152 or 154, receiving the encrypted data packet 122 forwarded from the load balancer 130, may send the encrypted data packet 122 to the target server 164 via the backend server 156 and the connector 162. The target server 164 responds by sending a response packet received from the destination server 152 or 154. The destination server 152 or 154 sends the response packet to the load balancer 330. The response packet received from the load balancer 130 includes an identifier (e.g., an IP address and a UDP port) of the destination server that transmitted the response packet. The IP address and the UDP port of the destination server may be included in a destination IP address field and a destination UDP port field of the IP header and UDP header of the response packet, respectively. The response packet is sent to the client device 110. If the client device 110 is a network device, the client device 110 may forward the response packet to a requester 170. If the client device 110 is a computing device, the client device 110 may be the destination of the response packet. In either case, the requester 170 or the client device 110 (whichever is the destination of the response packet) may record the destination server identifier included in the response packet. A value representing this identifier of the destination server may be added to the reserved field of the VPN message header of a subsequent encrypted data packet sent from the requester 170 or client device 110 to the load balancer 130, such that the load balancer 130 may use this value added to the reserved field of the subsequent encrypted data packet to identify the destination server to which the subsequent encrypted data packet is to be sent.FIG. 2 is a block diagram of portions of the encrypted data packet 122 that may be communicated in a VPN. The encrypted data packet 122 contains encrypted data. In some examples, the encrypted data packet 122 includes an IP header 202, a UDP header 204, and a WireGuar segment 206 (or more generally: a secure communication protocol segment). The WireGuar segment 206 includes a WireGuar header 208 and a payload 210. Payload 210 contains encrypted data. Note that the IP header 202, the UDP header 204, and the WireGuar header 208 are not encrypted, so that the load balancer 130 can access information in the IP header 202, the UDP header 204, and the WireGuar header 208 without decrypting the encrypted data packet 122.The WireGuar header 208 is an example of the VPN message header 124 of FIG. 1. The WireGuar header 208 includes a type field 212 (for indicating a message type), a reserved field 214, and other header fields (not shown).The IP header 202 includes a source address field 216 having a source IP address of a source (e.g., the client device 110 or a requester 170) of the encrypted data packet 122, and a destination address field 218 having a destination IP address of a destination (e.g., the destination server 164) of the encrypted data packet 122.The UDP header 204 includes a source port field 220 with a source UDP port of the source and a destination port field 222 with a destination UDP port of the destinationIn some examples, the reserved field 214 of the WireGuar header 208 may be set to different values. For example, if the reserved field 214 is set to a first value (e.g., "0"), this means that a destination server has not been selected by a source of the encrypted data packet 122. As a result, the load balancer 130 allocates a destination server among a plurality of destination servers based on a load balancing algorithm.The reserved field 214 of the WireGuar header 208 may also be set to other values representing identifiers of different destination servers in the zero trust network 150, respectively. For example, if the reserved field 214 is set to a second value representing the identifier of the destination server 152, then the load balancer 130 would forward the encrypted data packet 122 to the destination server 152 (and not apply the load balancing algorithm). If the reserved field 214 is set to a third value representing the identifier of the destination server 154, the load balancer 130 would forward the encrypted data packet 122 to the destination server 154 (and not apply the load balancing algorithm).In some examples, a value in the reserved field 214 may represent an IP address, a portion of an IP address, or any identifier of a destination server. For example, a function (e.g., a coding function) may be applied to the IP address (or a portion of the IP address) of the destination server to derive the value representing the IP address (the portion). In a more specific example, the last three digits (or a particular number of the least significant bits) of an IP address are encoded into a value that is added to the reserved field 214. The last three digits (or a certain number of the least significant bits) of an IP address are often sufficient to determine which destination server a data packet is to be forwarded to.FIG. 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 storing machine-readable instructions that, when executed, cause a load balancer to perform various tasks.The machine readable instructions include secure connection establishment instructions 302 to establish corresponding secure connections between the load balancer and a plurality of destination servers in a trusted network. The destination servers may include the destination servers 152 and 154 in the null trust network 150 of FIG. 1. The server-side secure connections may include corresponding server-side secure network tunnels, such as 142 and 144 in FIG. 1. In other examples where the load balancer 130 is located within a trusted network (e.g., the zero trust network 150), server-side secure connections may be established over a network connection within the trusted network without establishing secure network tunnels.The machine readable instructions include instructions for load balancing the VPN traffic 304. The encrypted VPN traffic comprises encrypted data packets containing payload data of encrypted data transmitted over one or more VPNs. The encrypted data packets are received by one or more client devices, such as client device 110 of FIG. 1.The machine readable instructions include instructions for receiving encrypted data packets 306 to receive a particular encrypted data packet from a client device. The given encrypted data packet contains a VPN message header, such as the WireGuar header 208 of FIG. 2. An example of the destination identification field is the reserved field 214 of the WireGuar header 208 of FIG. 2.The machine readable instructions include instructions for determining the value of the destination identification field 308 to determine whether a selected destination server in the trusted network is identified based on a value of the destination identification field in the VPN message header. The selected destination server is one of the plurality of destination servers. The destination identification field can be set to one of several possible values. A first value in the destination identification field indicates that a destination server is not identified by the VPN message header. Other possible values in the destination identification field represent identifiers of the respective destination servers.The machine readable instructions include instructions for transmitting encrypted data packets 310 to transmit the encrypted data packet to the selected destination server based on determining that the selected destination server is identified based on the value of the destination identification field in the VPN header.In some examples, the identifiers of the respective destination servers include corresponding portions (e.g., a subset of bits) of the network addresses of the respective destination servers. The network addresses may be, for example, IP addresses. A value representing a network address of a destination server may include a portion of the network address or may be based on applying a function to all or a portion of the network address. The function can be, for example, an encoding function which generates an encoded value which is based on the encoding of at least part of a network address of a destination server.In some examples, the value of the destination identification field in the VPN message header is specified by a source of the encrypted data packet. The source may be a client device (e.g., 130 in FIG. 1 ) or a requester (e.g., 170).In some examples, the value of the destination identification field is a predetermined value indicating that a destination server is not selected. The load balancer receives another encrypted data packet from the client device, the another encrypted data packet comprising a VPN message header having a destination identification field. The load balancer recognizes that the destination identification field in the VPN message header of the further encrypted data packet is set to the predetermined value, which indicates that no destination server is selected in the trust network. Based on the determination that the destination identification field in the VPN message header of the further encrypted data packet is set to the predetermined value, the load balancer applies a load balancing algorithm to select a further destination server from the plurality of destination servers, and the load balancer sends the further encrypted data packet to the further destination server.In some examples, the load balancer sends a response packet received from the another destination server to the client device, the response packet including an identifier of the another destination server. The load balancer receives from the client device a subsequent encrypted data packet with a VPN message header, the destination identification field of which is set to a value representing an identifier of the further destination server.In some examples, the encrypted data packet includes an IP header and a UDP header.In some examples, the field of the encrypted data packet is accessible to the load balancer without decryption of the encrypted data packet.In some examples, the secure connections between the load balancer and the destination servers include server-side secure network tunnels between the load balancer and the destination servers.FIG. 4 is a block diagram of a load balancer 400 according to some examples. An example of the load balancer 400 is the load balancer 130 of FIG. 1. the load balancer 400 includes a processing circuit 410 coupled to a storage medium 430.Processing circuitry 410 may be implemented as one or more hardware logic components and circuitry. Example types of hardware logic components that may be used include, for example and without limitation, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or other hardware logic components that may perform computations or other manipulations of information. The one or more hardware logic components and circuits may be referred to as one or more hardware processors.The storage medium 430 may include a memory or a storage. The memory may be volatile (e.g., random access memory, etc.), nonvolatile (e.g., read only memory, flash memory, etc.), or a combination thereof. The memory may be an on-chip memory, an off-chip memory, a combination thereof, or the like. The memory may include scratch pad memory for the processing circuit 410. Storage medium 430 may alternatively or additionally be magnetic storage, optical storage, solid state storage, a combination thereof, and the like, such as flash memory, a hard disk drive or other storage technology, or any other medium that may be used to store information.In some examples, storage medium 430 may store machine readable instructions for performing various tasks described herein. The machine readable instructions may include one or a combination of the following: software, firmware, middleware, microcode, hardware description language, or others. Machine readable instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable code format). The machine readable instructions, when executed by the processing circuit 410, cause the processing circuit 410 to perform the various processes described herein.The machine readable instructions include secure connection establishment instructions 412 for establishing corresponding secure connections between the load balancer and a plurality of destination servers in a trusted network. The machine readable instructions include instructions 414 for load balancing the VPN traffic to perform load balancing of the encrypted VPN traffic between the plurality of destination servers in the trusted network.The machine readable instructions include instructions for receiving encrypted data packets 416 to receive an encrypted data packet from a client device. The encrypted data packet includes a VPN message header having a destination identification field set to one of a plurality of different values. The plurality of different values includes a first value indicating that no selection of the destination server is made and a plurality of destination server values representing different destination servers of the plurality of destination servers, respectively.The machine readable instructions include instructions 418 for determining the value of the destination identification field to determine whether the value of the destination identification field is a destination server value representing a selected destination server from the plurality of destination servers.The machine readable instructions include instructions 420 for transmitting encrypted data packets to transmit the encrypted data packet from the load balancer to the selected destination server based on determining that the value of the destination identification field is the destination server value representing the selected destination server.In some examples, the encrypted data packet includes a payload including encrypted data, and the VPN message header in the encrypted data packet is unencrypted.In some examples, the value of the destination server in the destination identification field is based on a subset of bits of a network address of the selected destination server.FIG. 5 is a flowchart of a process 500 of a load balancer (e.g., the load balancer 130 of FIG. 1 ) according to some examples of the present disclosure. At 502, the load balancer establishes a client-side secure network tunnel between the load balancer and a client device. An example of the client-side secure network tunnel is shown as 120 in FIG. 1.At 504, the load balancer establishes a plurality of server-side secure connections between the load balancer and the respective destination servers of a trust network.At 506, the load balancer performs load balancing of the encrypted VPN traffic across the plurality of destination servers. The load compensation is effected according to a load compensation algorithm.At 508, the load balancer receives an encrypted data packet from the client device via the client-side secure network tunnel. The encrypted data packet includes a VPN message header having a destination identification field set to one of a plurality of different values. The plurality of different values includes a first value indicating that no selection of the destination server is made and a plurality of destination server values representing different destination servers from the plurality of destination servers, respectively.At 510, the load balancer determines whether the value of the destination identification field is a destination server value representing a selected destination server from the plurality of destination servers.At 512, based on determining that the value of the destination identification field is the destination server value representing the selected destination server, the load balancer sends the encrypted data packet to the selected destination server.In some examples, the load balancer may establish a server-side secure network tunnel to an XFRM interface. In one example, the XFRM interface may communicate with a TUNnel device (TUN) of a destination server. XFRM refers to a frame for implementing IPSec packet path functionality. A TUN device provides a virtual interface that implements software-based abstraction of a network by emulating the behavior of physical network cards such as Ethernet or Wi-Fi cards.In further examples, the ability to establish multiple server-side secure connections (e.g., server-side secure network tunnel) between the load balancer and the trusted network enables maintenance of the client-side secure network tunnel (e.g., 120 in FIG. 1 ) between the client device and the load balancer while transferring a portion of the traffic of the client connections in the client-side secure network tunnel from one server-side secure connection to another server-side secure connection, e.g., when a front-end server is no longer available in the trusted network. This possibility of transmission allows an additional destination server to be provided in the trust network in order to replace a destination server that is no longer available. A destination server may no longer be available due to a failure of the destination server, a failure of the communication connection to the destination server, an update of the destination server (for repair or maintenance, e.g. for updating an operating system, firmware or software), or an overload of the destination server. An increased workload may also be managed by adding further destination servers (e.g., physical servers or virtual servers).In some examples, the load balancer may suspend allocation of new secure network tunnels to a particular destination server when marked for maintenance. However, existing secure network tunnels to a particular destination server remain uninterrupted. The data packets of the existing secure network tunnels may be "dropped" by the respective destination server, which means that the communication of data packets through the existing secure network tunnels may be completed. However, new data traffic is not forwarded to the specified destination server, which is to be shut down for maintenance purposes.If the client device is directly connected to a destination server via a secure network tunnel and the destination server is no longer available, the secure network tunnel must be terminated and a new secure network tunnel must be set up between the client device and the destination server. This interferes with the communication of the client device. By adding the load balancing between the client device and the trusted network, the client-side secure network tunnel between the client device and the load balancing can be kept active, while the traffic of the client connections in the client-side secure network tunnel is transferred to another server-side secure network tunnel, regardless of whether it already exists or has been re-established. For example, rather than terminating a secure network tunnel between the client device and the destination server, another destination server may be provided for the client device's traffic. A "client connection" may refer to a connection established by a client device to a destination endpoint.All examples and conditions listed herein are intended to aid the reader in understanding the principles of the disclosed examples and are to be understood as not being limited to the specific examples and conditions listed. Moreover, all statements herein describing principles, aspects, and examples are intended to include both structural and functional equivalents thereof. Moreover, such equivalents are intended to include both currently known equivalents and equivalents developed in the future, i.e., all elements developed that perform the same function regardless of their structure.It should be understood that any reference to an element having a designation such as "first," "second," etc., does not generally limit the amount or order of these elements. Rather, these terms are generally used herein as a practical method of distinguishing between two or more elements or instances of an element. Thus, when a first and a second element are mentioned, this does not mean that only two elements may be used or that the first element must precede the second element in some way. Unless otherwise indicated, a group of elements comprises one or more elements.In the present disclosure, the use of the term "a", "an" or "the" also includes the plural forms unless the context clearly indicates otherwise. Also, the term "comprises", "including", "comprises", "comprises", "have" or "have" when used in this disclosure specifies the presence of the stated elements, but does not exclude the presence or addition of other elements.In the foregoing description, numerous details are set forth in order to provide an understanding of the subject matter disclosed herein. However, implementations without some of these details may be practiced. Other implementations may include modifications and variations from the details described above. It is intended that the appended claims cover such modifications and variations.References included in the specificationThis list of documents cited by the applicant has been produced in an automated manner and is only included for the better information of the reader. The list is not part of the German patent application or utility model application. The DPMA does not take any adhesion for any faults or omissions.Patent Literature citedUS 63 / 516,664

[0001]

Claims

A non-transitory machine readable storage medium containing instructions that, when executed, cause a load balancer to: establish respective secure connections between the load balancer and a plurality of destination servers in a trusted network; perform load balancing on encrypted virtual private network (VPN) traffic via the plurality of destination servers; receive an encrypted data packet from a client device, wherein the encrypted data packet comprises a VPN message header comprising a destination identification field related to identifying a destination server in the trusted network; determining whether a selected destination server in the trusted network is identified based on a value of the destination identification field in the VPN message header, wherein the selected destination server is one of the plurality of destination servers; and based on determining that the selected destination server is identified based on the value of the destination identification field in the VPN header, sending the encrypted data packet from the load balancer to the selected destination server.The non-transitory machine readable storage medium of claim 1, wherein different values of the destination identification field in the VPN message header represent respective identifiers of the plurality of destination servers in the trusted network.The non-transitory machine readable storage medium of claim 2, wherein the respective identifiers of the plurality of destination servers comprise respective portions of network addresses of the plurality of destination servers.The non-transitory machine readable storage medium of claim 3, wherein the network addresses comprise Internet Protocol (IP) addresses, and wherein the identifier of a given destination server of the plurality of destination servers comprises a subset of bits of the IP address of the given destination server.The non-transitory machine readable storage medium of claim 1, wherein the value of the destination identification field in the VPN message header comprises an encoded value based on encoding at least a portion of a network address of the selected destination server.The non-transitory machine readable storage medium of claim 1, wherein the value of the destination identification field in the VPN message header is set from a source of the encrypted data packet.The non-transitory machine readable storage medium of claim 1, wherein the instructions, when executed, cause the load balancer to: receive a further encrypted data packet from the client device, the further encrypted data packet comprising a VPN message header having a destination identification field; detect that the destination identification field in the VPN message header of the further encrypted data packet is set to a predetermined value indicating that a destination server in the trusted network is not selected; based on detecting that the destination identification field in the VPN message header of the further encrypted data packet is set to the predetermined value, applying a load balancing algorithm by the load balancer to select a further destination server from the plurality of destination servers; and transmitting the further encrypted data packet from the load balancer to the further destination server.The non-transitory machine readable storage medium of claim 7, wherein the instructions, when executed, cause the load balancer to: send a response packet received from the further destination server from the load balancer to the client device, the response packet comprising an identifier of the further destination server; and receive a subsequent encrypted data packet comprising a VPN message header having a destination identification field set to a value representing an identifier of the further destination server at the load balancer from the client device.The non-transitory machine readable storage medium of claim 1, wherein the encrypted data packet comprises a user datagram protocol (UDP) header.The non-transitory machine readable storage medium of claim 1, wherein the destination identification field of the encrypted data packet is accessible to the load balancer without decryption of the encrypted data packet.The non-transitory machine readable storage medium of claim 1, wherein the secure connections comprise secure network tunnels between the load balancer and the plurality of destination servers.The non-transitory machine readable storage medium of claim 1, wherein the VPN message header comprises a WireGuar header, and the destination identification field is included in the WireGuar header.The non-transitory machine readable storage medium of claim 1, wherein the encrypted data packet comprises a payload including encrypted data, and wherein the encrypted data packet comprises an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, and the VPN message header.A load balancer comprising: a processor; and a non-transitory storage medium storing instructions executable on the processor to: establish respective secure connections between the load balancer and a plurality of destination servers in a trusted network; perform load balancing on encrypted virtual private network (VPN) traffic via the plurality of destination servers; receiving an encrypted data packet from a client device, the encrypted data packet comprising a VPN message header set to one of a plurality of different values, the plurality of different values comprising a first value indicating that a destination server selection is not made and a plurality of destination server values representing different destination servers from the plurality of destination servers; determining whether the value of the destination identification field is a destination server value representing a selected destination server from the plurality of destination servers; and based on determining that the value of the destination identification field is the destination server value representing the selected destination server, sending the encrypted data packet from the load balancer to the selected destination server.The load balancer of claim 14, wherein the encrypted data packet comprises a payload including encrypted data, and the VPN message header is unencrypted in the encrypted data packet.The load balancer of claim 14, wherein the instructions are executable on the processor to: receive a further encrypted data packet from the client device, wherein the further encrypted data packet comprises a VPN message header having a destination identification field; detect that the destination identification field in the VPN message header of the further encrypted data packet is set to a predetermined value indicating that no destination server selection is made; based on detecting that the destination identification field in the VPN message header of the further encrypted data packet is set to the first value, applying a load balancing algorithm by the load balancer to select a further destination server from the plurality of destination servers; and transmitting the further encrypted data packet from the load balancer to the further destination server.The load balancer of claim 16, wherein the instructions are executable on the processor to: send a response packet received from the further destination server from the load balancer to the client device, the response packet comprising an identifier of the further destination server; and receive a subsequent encrypted data packet comprising a VPN message header having a destination identification field set to a destination server value representing an identifier of the further destination server at the load balancer from the client device.The load balancer of claim 14, wherein the destination server value in the destination identification field is based on a subset of bits of a network address of the selected destination server.A method comprising: by a load balancer, establishing a client-side secure network tunnel between the load balancer and a client device; establishing a plurality of server-side secure connections between the load balancer and a plurality of destination servers of a trusted network by the load balancer; performing load balancing of the encrypted virtual private network (VPN) traffic via the plurality of destination servers by the load balancer; receiving, by the load balancer, an encrypted data packet from the client device via the client-side secure network tunnel, the encrypted data packet including a VPN message header including a destination identification field set to one of a plurality of different values, the plurality of different values including a first value indicating that selection of the destination server is not made and a plurality of destination server values each representing different destination servers of the plurality of destination servers; determining whether the value of the destination identification field is a destination server value representing a selected destination server from the plurality of destination servers by the load balancer; and based on determining that the value of the destination identification field is the destination server value representing the selected destination server, sending the encrypted data packet from the load balancer to the selected destination server.The method of claim 19, wherein the client device comprises a network device through which electronic devices are connected to destination endpoints via the trusted network.

Images