WO2024189386A1

WO2024189386A1 - Gateway for enabling secure communication between two devices

Info

Publication number: WO2024189386A1
Application number: PCT/IB2023/052279
Authority: WO
Inventors: Wassim Michel Haddad; Heikki Mahkonen; David Schubert
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2023-03-10
Filing date: 2023-03-10
Publication date: 2024-09-19

Abstract

A method (400) performed by a gateway. The method includes receiving a first protocol data unit (PDU) transmitted by a first device and addressed to a second device, the first PDU comprising: 1) a header comprising i) a source address field containing an address allocated to the first device and ii) a destination address field containing an address allocated to a second device and 2) a payload comprising a first initiation message intended for initiating establishment of a first VPN connection (a.k.a., tunnel) between the first device and the second device. The method also includes, after receiving the first PDU, generating a second PDU comprising: 1) a header comprising i) a source address field containing the address allocated to the first device and ii) a destination address field containing the address allocated to the second device and 2) a payload comprising a second initiation message for initiating establishment of a second VPN connection between the gateway and the second device. The method further includes transmitting the second PDU to the second device.

Description

TITLE

GATEWAY FOR ENABLING SECURE COMMUNICATION BETWEEN TWO DEVICES

TECHNICAL FIELD

[001] Disclosed are embodiments related to a security gateway for enabling secure communication between two devices.

BACKGROUND

[002] A virtual private network (VPN) connection is a logical connection between devices that enables the devices to communicate securely (i.e., with encryption). The WireGuard® VPN protocol creates a VPN connection using state-of-the-art cryptography. WireGuard is gaining high market adoption alongside existing VPN technologies. WireGuard is implemented on top of the User Datagram Protocol (UDP), implements modern, high speed crypto primitives, does not allow crypto agility, and uses a public key as an identifier.

SUMMARY

[003] Certain challenges presently exist. For instance, in general, any device can initiate a VPN connection (a.k.a., secure session) with another device, and a problem can arise when one device uses a first VPN technology (e.g., WireGuard) while the other device uses another VPN technology (e.g., IPSec, Secure Socket Layers (SSL), Transport Layer Security (TLS), or Secure Socket Shell (SSH)) because the technologies may not be compatible.

[004] Accordingly, in one aspect there is provided a method performed by a gateway.

The method includes receiving a first protocol data unit (PDU) transmitted by a first device and addressed to a second device, the first PDU comprising: 1) a header comprising i) a source address field containing an address allocated to the first device and ii) a destination address field containing an address allocated to a second device and 2) a payload comprising a first initiation message, or portion thereof, intended for initiating establishment of a first VPN connection between the first device and the second device. The method also includes, after receiving the first PDU, generating a second PDU comprising: 1) a header comprising i) a source address field containing the address allocated to the first device and ii) a destination address field containing the address allocated to the second device and 2) a payload comprising a second initiation message, or portion thereof, for initiating establishment of a second VPN connection between the gateway and the second device. The method further includes transmitting the second PDU to the second device.

[005] In another aspect there is provided a method performed by a control plane entity

(CPE). The method includes receiving from a first device a request requesting a public key belonging to a second device, wherein the request comprises an address allocated to the second device. The method also includes transmitting to the first device a response comprising a public key belonging to a gateway. The method further includes transmitting to the gateway a control message comprising an address allocated to the first device and the address allocated to the second device.

[006] In another aspect there is provided a network node, such as a gateway or control plane entity, that is configured to perform the methods disclosed herein. The network node may include memory and processing circuitry coupled to the memory.

[007] An advantage of the embodiments disclosed herein is that they enable real-time provisioning of devices and/or security gateway in order to adapt security and/or privacy requirements to a particular session.

BRIEF DESCRIPTION OF THE DRAWINGS

[008] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[009] FIG. 1 illustrates a system according to an embodiment.

[0010] FIG. 2 is a message flow diagram according to an embodiment.

[0011] FIG. 3 is a message flow diagram according to an embodiment.

[0012] FIG. 4 is a flowchart illustrating a process according to an embodiment.

[0013] FIG. 5 is a flowchart illustrating a process according to an embodiment.

[0014] FIG. 6 is a block diagram of a network node according to an embodiment.

DETAIEED DESCRIPTION [0015] FIG. 1 illustrates a system 100 according to an embodiment. System 100 includes a device 101 (a.k.a., “device A”) that is able to communicate securely with a device 102 (a.k.a., “device B”) via a gateway (GW) 104 in a secure and privacy preserving manner. Because GW 104 facilitates secure communications, GW is referred to herein as “security” GW (SGW) 104. There is no requirement that device 101 and device 102 use the same security protocols. That is, device 101 can use a first security protocol (e.g., WireGuard) while device 102 uses a second security protocol (e.g., SSL/TLS). SGW 104, which can be provisioned in real time, enables the secure, private communication between the two devices. In one embodiment, a zero trust paradigm is employed.

[0016] In one embodiment, SGW 104 functions to ensure that each device has the right security credentials (e.g., public key) to use during a particular secure session, in order to establish mutual authentication and encrypt data traffic. There are scenarios where privacy is at least as important as enabling secure communication depending on the initiator and/or responder. In such case, “transient” security credentials may be used as they are better suited for avoiding traceability.

[0017] In one embodiment, SGW 104 is located “on-path,” which means that SGW 104 is able to intercept traffic, such as, for example, Internet Protocol (IP) protocol data units (PDUs) (a.k.a., “IP packets”), between the two devices. In one embodiment, SGW 104 is a type of Secure Access Service Edge (SASE) node that is operable to securely communicate with a control plane entity (CPE) 106 capable of taking decision based on each communicating device’s available credentials.

[0018] In one embodiment, CPE 106 is an enhanced WireGuard control plane entity that is enhanced to enable dynamic provisioning of the devices and/or SGW 104 to address a hybrid mode whereby the two devices may or may not speak the same security protocol and/or when different security credentials need to be provisioned on the fly, to enable such communication.

[0019] In the two scenarios described below, device 101 uses the WireGuard protocol, but device 102 does not.

[0020] First Scenario - device 101 Initiates a Session with device 102. [0021] FIG. 2 is a message flow diagram illustrating a process according to the first scenario.

[0022] In a first step, device 101 obtains device 102’s IP address. For example, device 101 may obtain device 102’s address by sending to a domain name server (DNS) a request for device 102’s IP address and receiving from the DNS a response message comprising device 102’s IP address.

[0023] After obtaining device 102’s IP address, device 101 uses the IP address to find a public key associated with the IP address. If device 101 cannot find the public key associated with device 102’s IP address, then device 101 determines it cannot establish a secure tunnel (e.g., a WireGuard tunnel) with device 102 because the protocol that device 101 is using requires device 102’s public key to create the VPN connection (e.g., to create a symmetric encryption key for encrypting data to send to device 102 and for decrypting encrypted data sent by device 102 to device 101).

[0024] In a next step, device 101 sends to CPE 106 (e.g., its WireGuard Control Plane (WGCP)) a request for device 102’s public key (PubK). That is, device 101 sends to CPE 106 a request message m204 comprising device 102’s IP address (denoted IP(B)) or other identifier associated with device 102 (e.g., a domain name).

[0025] In response to receiving the request message m204, CPE 106 transmits to device 101 a query response message m206 containing a PubK. Device 101 will assume that this PubK belongs to device 102. That is, device 101 will assume that device 102 is in possession of the private key (PrivK) that is paired with the PubK. This PubK, however, is assigned to SGW 104 (i.e., SGW 104 is in possession of, or can obtain, the PrivK paired with the PubK). Because the PubK provided to device 101 is assigned to SGW 104, the PubK will now be denoted PubK(SGW).

[0026] CPE 106 also uses IP(B) included in the query message to retrieve a PubK certificate (or “certificate” for short) associated with IP(B). Accordingly, the retrieved certificate is associated with device 102. The certificate associated with device 102, which is now denoted Cert(B), may be retrieved from a database local to CPE 106 or may be retrieved from a remote database using a mechanism such as DNS-Based Authentication of Named Entities (DANE). The certificate includes, among other things, a PubK belonging to device 102, which is now denoted (PubK(B)). CPE 106 also uses IP(A) (device 101’s IP address) to obtain Cert(A) (i.e., a certificate associated with IP(A)). Cert(A) includes PubK(A), a public key that is paired with a private key belonging to device 101.

[0027] After obtaining Cert(A) and Cert(B), CPE 106 sends to SGW 104 a control message m208 containing: IP(A) and its associated certificate Cert(A), IP(B) and its associated certificate Cert(B), and lifetime information indicating the lifetime of Cert(A). In some embodiments, the lifetime information is a component of Cert(A). Message m208 may also include PubK(SGW) and PrivK(SGW), which is the private key that is paired with PubK(SGW). Message m208 also may include a protocol identifier that CEP 106 determined based on IP(B). The protocol identifier identifies the VPN protocol that device 102 supports (or prefers). Accordingly, in some embodiments, SGW 104 uses the protocol identified by the protocol identifier to communicate with device 102.

[0028] After receiving message m208, SGW 104 will have the IP address for device 101 and the IP address for device 202. SGW 104 then creates an IP filter (i.e., a data structure) that comprises IP(A) and IP(B). For example, the filter may comprise two attribute-value -pairs: (1) source=IP(A) and (2) destination=IP(B).

[0029] After obtaining PubK(SGW), device 101 initiates a first VPN connection by sending an initiation message m210 (e.g., a WireGuard handshake initiation message) intended for device 102. That is, device 101 transmits an IP protocol data unit (PDU) containing the initiation message m210, where the IP destination address of the IP PDU is set to the IP address for device 102 (also, the IP source address of the IP PDU is set to the IP address for device 101). In some embodiments, initiation message m210 includes data that device 101 generated using PubK(SGW), which device 101 obtained from CPE 106.

[0030] Because SGW 104 is on the path between device 101 and device 102, SGW 104 receives the IP PDU containing message m210 and determines whether the IP PDU contains a VPN connection initiation message and matches the IP filter. The IP PDU matches the filter if the source address of the IP PDU is IP(A) and the destination address of the IP PDU is IP(B).

[0031] As a result of determining that the IP PDU matches the IP filter and the IP PDU contains a VPN connection initiation message, SGW 104 does not forward the IP PDU to device 102, but rather SGW 104 establishes a second VPN connection (e.g., an IPsec or TLS session) with device 102 using device 101 ’s device ID (e.g., device 101 ’s IP address) and Cert(A). For example, SGW 104 transmits to device 102 a message m212 containing Cert(A) or information derived using Cert(A); the IP PDU carrying this message has device 101 ’s IP address as the source IP address and device 102’s IP address as the destination address. Accordingly, from device 102’s perspective, it is receiving an initiation message from device 101, not SGW 104. Depending on the protocol used to establish the VPN connection with device 102, after device 102 receives message m212, device 102 may transmit to SGW 104 a response message, at which point the second VPN connection between SGW 104 and device 102 is established.

[0032] After the VPN connection between SGW 104 and device 102 is established, SGW 104 transmits to device 101 a handshake response message m216 (e.g., a WireGuard handshake response message) responsive to initiation message m210, thereby enabling the completion of the establishment of the VPN connection between device 101 and SGW 104. For example, in some embodiments, after device 101 receives response message m216, device 101 uses data included in response message m216 to generate an encryption key (e.g., a symmetric encryption key) that device 101 will use to encrypt the data that device 101 sends and intends to be delivered to device 102. In some embodiments, handshake response message m216 comprises data that SGW 104 generated using PubK(A), PubK(SGW), and PrivK(SGW).

[0033] After the first VPN connection is established, device 101 uses an encryption key for the first VPN connection (e.g., the above-mentioned symmetric key) to encrypt data and then sends for delivery to device 102 a message m218 containing the encrypted data. That is, the IP PDU containing message m218 (or portion thereof) is addressed to device 102 and the source address is set to the address of device 101.

[0034] SGW 104 intercepts the IP PDU containing message m218, decrypts the encrypted data using a key (e.g., the above-mentioned symmetric key) for the first VPN connection, then re-encrypts the data using another key (e.g., PubK(B) or a key derived using PubK(B)), and then sends to device 102 an IP PDU containing a message m220 containing the encrypted data. The IP PDU containing message m220 (or portion thereof) is addressed to device 102 and the source address is set to the address of device 101. Device 102 receives message m220 and decrypts the received encrypted data using a key for the second VPN connection. [0035] Similarly, device 102 uses PubK(A), obtained from Cert(A) to encrypt data, and then device 102 sends the encrypted data to device 101. SGW 104 does not intercept this encrypted traffic. In this way, device 101 and device 102 can communicate securely even though device 101 and device 102 may implement different security protocols.

[0036] Second Scenario - device 102 Initiates a Session with device 101.

[0037] FIG. 3 is a message flow diagram illustrating a process according to the second scenario.

[0038] In a first step, device 102 obtains IP(A) and initiates a secure session by transmitting an initiation message m310 addressed to IP(A). That is, device 102 transmits an IP PDU containing the initiation message m310, where the IP destination address of the IP PDU is set to IP(A) (also, the IP source address of the IP PDU is set to IP(B)). Because SGW 104 is on the path between device 101 and device 102, SGW 104 receives the IP PDU containing message m310. Rather than forwarding the IP PDU toward device 101, SGW 104 transmits to CPE 106 a message m312 indicating that device 102 is attempting to establish a VPN connection with device 101 (e.g., message m312 may include IP(A) and IP(B)).

[0039] After CPE 106 receives message m312, CPE 106 determines whether to allow device 102 to communicate with device 101. Assuming CPE 106 determines to allow device 102 to communicate with device 101, CPE 106 sends to SGW 104 an instruction message m314 instructing SGW 104 to initiate a VPN connection (e.g., WireGuard secure session) with device 101. In one embodiment, message m314 comprises Cert(A).

[0040] After receiving instruction message m314, SGW 104 initiates the VPN connection with device 101 by transmitting to device 101 an initiation message m316 (e.g., a WireGuard Handshake Initiation message). That is, SGW 104 transmits to device 101 an IP PDU containing the initiation message m316, where the IP source address of the IP PDU is set to IP(B) (also, the IP destination address of the IP PDU is set to IP(A)). In some embodiments, initiation message includes data that SGW 104 generated using PubK(A), PubK(SGW), and PrivK(SGW). Device 101 responds to initiation message m316 by sending to SGW 104 a response message m318 (e.g., a WireGuard Handshake response message), thereby completing the handshake with SGW 104 and providing SGW 104 with the information it needs to generate a key for encrypting data for device 101. [0041] After SGW 104 receives response message m318, SGW 104 completes the establishment of the VPN connection with device 102 by transmitting to device 102 a response message m320.

[0042] After the VPN connection with device 102 is established, device 102 obtains data to be provided to device 101, encrypts the data using a key for the VPN connection with SGW 104, and transmits for delivery to device 101 a message m322 comprising the encrypted data. That is, the IP PDU containing message m322 (or portion thereof) is addressed to device 101 and the source address is set to the address of device 102.

[0043] SGW intercepts message m322. After intercepting the message, SGW 104 decrypts the encrypted data included in message 322 to recover the data, encrypts the recovered data using the key for the VPN connection with device 101, thereby producing encrypted data, and transmits to device 101 an IP PDU contain a message m324 (or portion thereof) comprising the encrypted data that was generated using the key for the VPN connection with device 101. This IP PDU is addressed to device 101, but the source address of the IP PDU is set to the IP address of device 102, not SGW 104. Device 101 receives message m324, which appears to have originated from device 102, and decrypts the encrypted data included in message m324 using the key for the VPN connection with SGW 104.

[0044] Similarly, after the VPN connection with SGW 104 is established, device 101 obtains data to be provided to device 102, encrypts the data using a key for the VPN connection with SGW 104, and transmits for delivery to device 102 a message m326 comprising the encrypted data. That is, the IP PDU containing message m326 (or portion thereof) is addressed to device 102 and the source address is set to the address of device 101.

[0045] SGW intercepts message m326. After intercepting the message, SGW 104 decrypts the encrypted data included in message m326 to recover the data, encrypts the recovered data using the key for the VPN connection with device 102, thereby producing encrypted data, and transmits to device 102 an IP PDU contain a message m328 (or portion thereof) comprising the encrypted data that was generated using the key for the VPN connection with device 102. This IP PDU is addressed to device 102, but the source address of the IP PDU is set to the IP address of device 101, not SGW 104. Device 102 receives message m328, which appears to have originated from device 101, and decrypts the encrypted data included in message m328 using the key for the VPN connection with SGW 104.

[0046] While FIGs. 1-3 show CPE 106 being separate and apart from SGW 104, in some embodiments, CPE 106 may be a component of SGW 104. Hence, for example, device 101 may send request message m204 to SGW 104 and SGW 104 responds as described above.

[0047] FIG. 4 is a flow chart illustrating a process 400, according to an embodiment, performed by a gateway, e.g., SGW 104. Process 400 may begin in step s402.

[0048] Step s402 comprises receiving a first PDU transmitted by device 101 and addressed to device 102. The first PDU comprises: 1) a header comprising i) a source address field containing an address allocated to device 101 and ii) a destination address field containing an address allocated to device 102 and 2) a pay load comprising a first initiation message, or portion thereof, intended for initiating establishment of a first VPN connection (a.k.a., tunnel) between device 101 and device 102.

[0049] Step s404 comprises, after receiving the first PDU, generating a second PDU comprising: 1) a header comprising i) a source address field containing the address allocated to device 101 and ii) a destination address field containing the address allocated to device 102 and 2) a payload comprising a second initiation message, or portion thereof, for initiating establishment of a second VPN connection between the gateway and device 102.

[0050] Step s406 comprises transmitting the second PDU to device 102.

[0051] In some embodiments, the first VPN connection is a WireGuard® connection and the second VPN connection is a non-WireGuard® connection (e.g., IPsec tunnel).

[0052] In some embodiments the process also includes the gateway obtaining a first private key and a first public key paired with the first private key, wherein the first initiation message for establishing the first VPN connection was generated by device 101 using the first public key paired with the first private key. In some embodiments the process also includes, prior to receiving the first PDU, receiving a query from device 101, wherein the query comprises the address allocated to device 102, and transmitting to device 101 a response to the query, wherein the response comprises the first public key. [0053] In some embodiments the process also includes generating a first response message responsive to the first initiation message; transmitting the first response message to device 101; receiving from device 102 a second response message responsive to the second initiation message; after transmitting the first response message to device 101, receiving a data message transmitted by device 101, wherein the data message comprises first encrypted data; decrypting the first encrypted data to produce un-encrypted data; encrypting the un-encrypted data to produce second encrypted data; and, after receiving the second response message, transmitting to device 102 a third PDU. The third PDU comprises: a header comprising i) a source address field containing the address allocated to device 101 and ii) a destination address field containing the address allocated to device 102, and the third PDU further comprises a payload comprising the second encrypted data.

[0054] In some embodiments the process also includes: obtaining a filter comprising a first address and a second address and, after receiving the first PDU and prior to transmitting the second PDU to the second device, determining whether the first PDU matches the filter. Determining whether the first PDU matches the filter comprises i) determining whether the address of the source address field of the first PDU is the same as the first address and ii) determining whether the address of the destination address field of the first PDU is the same as the second address. The gateway generates the second PDU after determining that the first PDU matches the filter.

[0055] In some embodiments, obtaining the filter comprises receiving from a control plane entity a control message comprising the filter, the control message further comprises a first certificate for device 101 and a second certificate for device 102, and the gateway uses the first certificate and the second certificate to establish the second VPN connection. In some embodiments the control message further comprises a protocol identifier identifying a protocol, and the second initiation message conforms to the identified protocol.

[0056] In some embodiments the first VPN connection is a non-WireGuard® connection and the second VPN connection is a WireGuard® connection. In this embodiment the process may also include, after receiving the first PDU and before transmitting the second PDU, transmitting to a control plane entity a control message comprising information indicating that the first device is attempting to establish a VPN connection with the second device and receiving from the control plane entity a response to the control message. The response instructs the gateway to establish the second VPN connection with the second device, the response comprises a first public key associated with the first device, a second public key associated with the second device, and a first private key paired with the first public key, and the gateway uses the first public key, the second public key, and the first private key to generate the second initiation message.

[0057] FIG. 5 is a flow chart illustrating a process 500, according to an embodiment, that is performed by CPE 106. Process 500 may begin in step s502. Step s502 comprises receiving from device 101 request m204 requesting a public key belonging to device 102, wherein the request comprises an address allocated to device 102. Step s504 comprises transmitting to device 101 a response comprising a public key belonging to SGW 104 (i.e., PubK(SGW)). Step s506 comprise providing to SGW 104 (e.g., transmitting to SGW 104) a control message m208, which comprises IP(A) and IP(B). In some embodiments, the control message further comprises Cert(A). In some embodiments, CPE is a component of SGW 104.

[0058] FIG. 6 is a block diagram of a network node 600 that implements the functionality of SGW 104 and/or CPE 106, according to some embodiments. As shown in FIG. 6, network node 600 may comprise: processing circuitry (PC) 602, which may include one or more processors (P) 655 (e.g., one or more general purpose microprocessors and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., network node 600 may be a distributed computing apparatus); a first network interface 648 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 645 and a receiver (Rx) 647 for enabling network node 600 to transmit data to and receive data from other nodes connected to a network 110 (e.g., an Internet Protocol (IP) network) to which network interface 648 is connected (physically or wirelessly) (e.g., network interface 648 may be coupled to an antenna arrangement comprising one or more antennas for enabling network node 600 to wirelessly transmit/receive data); at least a second network interface 678 comprising a transmitter (Tx) 675 and a receiver (Rx) 677 for enabling network node 600 to transmit data to and receive data from other nodes connected to network 109 (e.g., an Internet Protocol (IP) network) to which network interface 648 is connected (physically or wirelessly); and a storage unit (a.k.a., “data storage system”) 608, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. In embodiments where PC 602 includes a programmable processor, a computer readable storage medium (CRSM) 642 may be provided. CRSM 642 may store a computer program (CP) 643 comprising computer readable instructions (CRI) 644. CRSM 642 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 644 of computer program 643 is configured such that when executed by PC 602, the CRI causes network node 600 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, network node 600 may be configured to perform steps described herein without the need for code. That is, for example, PC 602 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

[0059] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above -described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0060] As used herein transmitting a message “to” or “toward” an intended recipient encompasses transmitting the message directly to the intended recipient or transmitting the message indirectly to the intended recipient (i.e., one or more other nodes are used to relay the message from the source node to the intended recipient). Likewise, as used herein receiving a message “from” a sender encompasses receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Further, as used herein “a” means “at least one” or “one or more.”

[0061] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Claims

1. A method (400) performed by a gateway (104), comprising: receiving (s402) a first protocol data unit, PDU, transmitted by a first device (101) and addressed to a second device (102), the first PDU comprising: 1) a header comprising i) a source address field containing an address allocated to the first device and ii) a destination address field containing an address allocated to a second device and 2) a payload comprising a first initiation message (m210), or portion thereof, intended for initiating establishment of a first VPN connection between the first device and the second device; after receiving the first PDU, generating (s404) a second PDU comprising: 1) a header comprising i) a source address field containing the address allocated to the first device and ii) a destination address field containing the address allocated to the second device and 2) a payload comprising a second initiation message (m212), or portion thereof, for initiating establishment of a second VPN connection between the gateway and the second device; and transmitting (s406) the second PDU to the second device.

2. The method of claim 1, wherein the first VPN connection is a WireGuard® connection and the second VPN connection is a non-WireGuard® connection.

3. The method of claim 1 or 2, further comprising: obtaining a first private key and a first public key paired with the first private key, wherein the first initiation message for establishing the first VPN connection was generated by the first device using the first public key paired with the first private key.

4. The method of claim 3, further comprising: prior to receiving the first PDU, receiving a query (m204) from the first device, wherein the query comprises the address allocated to the second device; and transmitting to the first device a response (m206) to the query, wherein the response comprises the first public key.

5. The method of any one of claims 1-4, further comprising: generating a first response message (m216) responsive to the first initiation message; transmitting the first response message to the first device; receiving from the second device a second response message responsive to the second initiation message; after transmitting the first response message to the first device, receiving a data message (m218) transmitted by the first device, wherein the data message comprises first encrypted data; decrypting the first encrypted data to produce un-encrypted data; encrypting the un-encrypted data to produce second encrypted data; and after receiving the second response message, transmitting to the second device a third PDU, wherein the third PDU comprises: a header comprising i) a source address field containing the address allocated to the first device and ii) a destination address field containing the address allocated to the second device, and the third PDU further comprises a payload comprising the second encrypted data.

6. The method of any one of claims 1-5, further comprising: obtaining a filter comprising a first address and a second address; and after receiving the first PDU and prior to transmitting the second PDU to the second device, determining whether the first PDU matches the filter, wherein determining whether the first PDU matches the filter comprises i) determining whether the address of the source address field of the first PDU is the same as the first address and ii) determining whether the address of the destination address field of the first PDU is the same as the second address, wherein the gateway generates the second PDU after determining that the first PDU matches the filter.

7. The method of claim 6, wherein obtaining the filter comprises receiving from a control plane entity, CPE, a control message (m208) comprising the filter, the control message further comprises a first certificate for the first device and a second certificate for the second device, and the gateway uses the first certificate and the second certificate to establish the second VPN connection.

8. The method of claim 7, wherein the control message further comprises a protocol identifier identifying a protocol, and the second initiation message conforms to the identified protocol.

9. The method of claim 1, wherein the first VPN connection is a non-WireGuard® connection and the second VPN connection is a WireGuard® connection.

10. The method of claim 9, further comprising: after receiving the first PDU and before transmitting the second PDU, transmitting to a control plane entity a control message comprising information indicating that the first device is attempting to establish a VPN connection with the second device; and receiving from the control plane entity a response to the control message, wherein the response instructs the gateway to establish the second VPN connection with the second device, the response comprises a first public key associated with the first device, a second public key associated with the second device, and a first private key paired with the first public key, and the gateway uses the first public key, the second public key, and the first private key to generate the second initiation message.

11. A method (500) performed by a control plane entity (106), the method comprising: receiving (s502) from a first device (101) a request (m204) requesting a public key belonging to a second device (102), wherein the request comprises an address allocated to the second device; transmitting (s504) to the first device a response (m206) comprising a public key belonging to a gateway (104); and providing (s506) to the gateway a control message (m208) comprising an address allocated to the first device and the address allocated to the second device.

12. The method of claim 11, wherein the control message further comprises a certificate for use by the gateway in establishing a VPN connection with the second device.

13. The method of claim 11 or 12, wherein the CPE (106) is a component of the gateway (104).

14. A gateway (104), the gateway being configured to perform a method comprising: receiving (s402) a first protocol data unit, PDU, transmitted by a first device (101) and addressed to a second device (102), the first PDU comprising: 1) a header comprising i) a source address field containing an address allocated to the first device and ii) a destination address field containing an address allocated to a second device and 2) a payload comprising a first initiation message (m210), or portion thereof, intended for initiating establishment of a first VPN connection between the first device and the second device; after receiving the first PDU, generating (s404) a second PDU comprising: 1) a header comprising i) a source address field containing the address allocated to the first device and ii) a destination address field containing the address allocated to the second device and 2) a payload comprising a second initiation message (m212), or portion thereof, for initiating establishment of a second VPN connection between the gateway and the second device; and transmitting (s406) the second PDU to the second device.

15. The gateway of claim 14, wherein the first VPN connection is a WireGuard® connection and the second VPN connection is a non-WireGuard® connection.

16. The gateway of claim 14 or 15, wherein the method further comprises: obtaining a first private key and a first public key paired with the first private key, wherein the first initiation message for establishing the first VPN connection was generated by the first device using the first public key paired with the first private key.

17. The gateway of claim 16, wherein the method further comprises: prior to receiving the first PDU, receiving a query (m204) from the first device, wherein the query comprises the address allocated to the second device; and transmitting to the first device a response (m206) to the query, wherein the response comprises the first public key.

18. The gateway of any one of claims 14-17, wherein the method further comprises: generating a first response message (ml6) responsive to the first initiation message; transmitting the first response message to the first device; receiving from the second device a second response message responsive to the second initiation message; after transmitting the first response message to the first device, receiving a data message (m218) transmitted by the first device, wherein the data message comprises first encrypted data; decrypting the first encrypted data to produce un-encrypted data; encrypting the un-encrypted data to produce second encrypted data; and after receiving the second response message, transmitting to the second device a third PDU, wherein the third PDU comprises: a header comprising i) a source address field containing the address allocated to the first device and ii) a destination address field containing the address allocated to the second device, and the third PDU further comprises a payload comprising the second encrypted data.

19. The gateway of any one of claims 14-18, wherein the method further comprises: obtaining a filter comprising a first address and a second address; and after receiving the first PDU and prior to transmitting the second PDU to the second device, determining whether the first PDU matches the filter, wherein determining whether the first PDU matches the filter comprises i) determining whether the address of the source address field of the first PDU is the same as the first address and ii) determining whether the address of the destination address field of the first PDU is the same as the second address, wherein the gateway is configured to generate the second PDU after determining that the first PDU matches the filter.

20. The gateway of claim 19, wherein obtaining the filter comprises receiving from a control plane entity a control message (m208) comprising the filter, the control message further comprises a first certificate for the first device and a second certificate for the second device, and the gateway uses the first certificate and the second certificate to establish the second VPN connection.

21. The gateway of claim 20, wherein the control message further comprises a protocol identifier identifying a protocol, and the second initiation message conforms to the identified protocol.

22. The gateway of claim 14, wherein the first VPN connection is a non-WireGuard® connection and the second VPN connection is a WireGuard® connection.

23. The gateway of claim 22, wherein the method further comprises: after receiving the first PDU and before transmitting the second PDU, transmitting to a control plane entity a control message comprising information indicating that the first device is attempting to establish a VPN connection with the second device; and receiving from the control plane entity a response to the control message, wherein the response instructs the gateway to establish the second VPN connection with the second device, the response comprises a first public key associated with the first device, a second public key associated with the second device, and a first private key paired with the first public key, and the gateway uses the first public key, the second public key, and the first private key to generate the second initiation message.

24. A control plane entity (106), the control plane entity being configured to perform a method comprising: receiving (s502) from a first device (101) a request (m204) requesting a public key belonging to a second device (102), wherein the request comprises an address allocated to the second device; transmitting (s504) to the first device a response (m206) comprising a public key belonging to a gateway (104); and providing (s506) to the gateway a control message (m208) comprising an address allocated to the first device and the address allocated to the second device.

25. The control plane entity of claim 24, wherein the control message further comprises a certificate for use by the gateway in establishing a VPN connection with the second device.

26. The control plane entity of claim 24 or 25, wherein the CPE (106) is a component of the gateway (104).