Bypassing the IKE firewall for cloud-managed IPSEC keys in the SDWAN fabric

Abstract

A procedure that includes: at a first network device (120, 122) between a second network device (112) and a third network device (154), detecting an Internet Key Exchange Protocol (IKE) key negotiation between the second network device and the third network device; based on the detection of the IKE key negotiation! between the second network device and the third network device, creating a firewall session in the first network device between the second and the third network device, wherein a first Internet Protocol Security (IPSec) tunnel (212) is established by the first network device between the second and the third network device using the IKE key negotiation, the first tunnel being compliant with the firewall session and allowing the passage of IPSec data packets through the first network device between the second and the third network device; Passing the IPSec data packets exchanged between the second and third network devices through the first network device based on the establishment of the first tunnel using cloud-managed IPSec keys from a cloud-based orchestrator (142), wherein the IPSec data packets are exchanged as part of a handshake operation that results in the establishment of a second tunnel between the second and third network devices according to the cloud-managed IPSec keys, the second tunnel being an overlay tunnel (218) on an underlay network; and After the second tunnel has been established and the cloud-managed IPSec keys are active, discard the negotiated IKE and carefully dismantle the first IPSec tunnel without disrupting encrypted communication between the second and third network devices.

Description

background

[0001] In computer networking, a virtual private network (VPN) can refer to an encrypted connection over the internet from a device to a network, with encryption protecting all sensitive data transmitted between the device and the network. For example, VPNs allow users to access a private network and exchange sensitive data over public networks, such as the internet.

[0002] Associated with VPNs is Internet Protocol Security (IPSec), a suite of protocols used to encrypt data packets to enable secure connections between the devices exchanging them. IPSec can be thought of as a security layer that is itself embedded within a network.

[0003] US 2020 / 0 252 234 A1 relates to the routing of packets within a network and in particular to route management within a wide area network (WAN).

[0004] US 2016 / 0 080 502 A1 relates to methods and systems for a controller-based secure session key.

[0005] US 2021 / 0 185 013 A1 refers to Software-Defined Networking (SDN) and Virtual Private Networks (VPNs).

[0006] The present invention is defined by independent claims 1, 6, and 12. Embodiments are subject to the respective dependent claims. Brief description of the drawings

[0007] The present disclosure will be described in detail in accordance with one or more various embodiments with reference to the following figures. The figures are for illustrative purposes only and represent merely typical or exemplary embodiments. Fig. 1 shows an example SD-WAN in which embodiments of the present disclosure may be implemented. Fig. Figure 2A is an example of a message flow between network devices that results in cloud-managed tunnel orchestration despite using the IPSec passthrough mechanism. Fig. Figure 2B shows the SD-WAN example of Fig. 1, which has been adapted to enable cloud-managed tunnel orchestration despite using the IPSec passthrough mechanism. Fig. 3A shows an example system architecture that may be implemented to realize cloud-managed tunnel orchestration according to various embodiments. Fig. 3B is an example flowchart illustrating example operations that may be performed to effect cloud-managed tunnel orchestration according to various embodiments. Fig. 4 is an example of a computer component that may be used to implement various features of the embodiments described in the present disclosure.

[0008] The figures are not exhaustive and do not limit the present disclosure to the precise form disclosed. Detailed description

[0009] As described above, network devices can use IPSec to protect sensitive data in transit over a VPN. IPSec keys from network devices can be used to enable the establishment of an overlay tunnel between the network devices. A feature known as IPSec passthrough allows IPSec tunnels to "pass" through a network device such as a router or modem. This means that certain network devices such as routers / modems typically connect to the internet using a NAT (Network Address Translation) protocol, which is incompatible with IPSec. The IPSec passthrough feature makes IPSec compatible with the NAT protocol, allowing the use of Layer 2 Tunneling Protocol (L2TP) to enable point-to-point sessions over the internet at the L2 layer.

[0010] One environment where the use of IPSec can be problematic is that of a software-defined wide area network (SD-WAN). In software-defined branch office deployments, SD-WAN technology can be used to centralize the management of an organization's WAN across multiple physical locations. SD-WAN technologies are typically implemented as a cloud-based management solution and rely on virtualization, overlay networks, and on-premises SD-WAN devices and software platforms to better manage network traffic, among other things.

[0011] When cloud-managed tunnel orchestration is used in an SD-WAN, IPSec packets used to establish the aforementioned overlay tunnel are dropped at the router / modem, preventing the overlay tunnel from being established. This occurs because network devices (e.g., gateways, VPNCs, etc.) with cloud-managed IPSec keys can connect to an SD-WAN orchestrator in the cloud and receive the IPSec keys. For example, a first endpoint device would then attempt to send encrypted bootstrap packets to determine if the IPSec keys have been received from a second endpoint device. Endpoint devices here can be defined as network devices / hardware controllers that can communicate with a network, such as the aforementioned gateways and VPNCs. After receiving a response from the second endpoint device, an overlay tunnel is typically established between the first and second endpoint devices.

[0012] However, when network devices such as routers / modems use the IPSec passthrough feature (typically enabled by default in next-generation router / modem configurations), NAT traversal sessions between the first and second endpoint devices are examined. IPSec packets are only allowed to pass through the router / modem between the first and second endpoint devices if Internet Key Exchange (IKE) protocol exchanges are occurring and observed. It is understood that most IPSec implementations include an IKE daemon running in user space and an IPSec stack that processes IP packets. IKE is a protocol used to establish a security association (SA) in the IPSec protocol. Because of the IPSec passthrough feature, no IKE exchanges need to be performed.Rather, the first and second endpoint devices can simply receive the IPSec keys from the cloud-based SD-WAN orchestrator and use them directly. The first and second endpoint devices perform a type of direct handshaking with the IPSec keys to establish the overlay tunnel. It should be understood that without performing an IKE exchange, no traffic can be transmitted between the first and second endpoint devices. This means that the IKE protocol exchange should generally take place before an overlay tunnel with IPSec keys can be established.

[0013] Accordingly, various embodiments aim to bypass or circumvent the IKE firewall / exchange requirement of the IPSec passthrough function. Specifically, when network devices such as the first and second endpoint devices described above attempt to exchange data, each connects to the cloud-based SD-WAN orchestrator and can obtain IPSec keys. The IKE negotiation process is initiated so that the router / modem is aware of the IKE exchange, so that, from the router / modem's perspective, the first and second endpoint devices comprise endpoints of a legitimate IKE / IPSec session, enabling the establishment of an IKE / IPSec tunnel. The first and second endpoint devices perform a handshake operation with IPSec data packets using the IPSec keys provided by the cloud-managed SD-WAN orchestrator.Since the first and second endpoint devices are known to the router / modem due to the IKE exchange, a cloud-managed overlay tunnel can be established between the first and second endpoint devices. The IKE / IPSec tunnel can then be (gentle) terminated. Gentle termination of an IKE / IPSec tunnel can be understood as deactivating a connection between the first and second endpoint devices without causing communication outages or impacting user traffic passing between them. In this way, despite the use of IPSec passthrough in devices such as routers / modems, an overlay tunnel can still be established between endpoint devices, with the uplinks passing through the routers / modems.

[0014] Fig. 1 shows an example of an SD-branch device in accordance with various examples of the presently disclosed technology. SD-branch device 100 includes a first endpoint device, e.g., a branch gateway 112 at branch / customer site 110, Internet Service Providers (ISPS 130, 132) that at least partially form a WAN 160 controlled by SD-WAN 134, and a second endpoint device, which in this case may be the VPNC 154 (receiving traffic from a data stream source 152) of a data center 150.

[0015] The traffic stream 152 may be any data transmission (e.g., streaming media, information dissemination, etc.) directed to one or more recipients / endpoints. In the example of Fig. 1, only one traffic stream (i.e., traffic stream 152) is shown in the data center source 150. However, in other examples, the data center 150 may contain any number of traffic streams. Similarly, the SD branch facility 100 may include any number of traffic sources, receivers, etc.

[0016] In general, a VPNC, such as VPNC 154, may refer to a hardware or software application used to connect VPNs. As illustrated, data center 150 includes VPNC 154. Accordingly, VPNC 154 may be used to transmit data associated with traffic flow 152 to one or more branch offices, in this example, to branch gateway 112 of branch office 110 (as orchestrated by overlay tunnel orchestrator 142).

[0017] SD-WAN 140 may be a cloud-based SD-WAN technology platform that includes a central service capable of performing orchestration operations within a specific WAN (e.g., WAN 160). In general, SD-WAN orchestration may refer to a central management service that provides WAN control and management in the cloud. In certain examples, SD-WAN 140 may include additional centralized network management services. Accordingly, various subservices may be included within SD-WAN 140. As illustrated, SD-WAN 140 includes the overlay tunnel orchestrator 142, which may be a subservice of SD-WAN orchestrator 144, which, in addition to orchestrating tunnels, may also orchestrate routes, orchestrate key exchange, etc.

[0018] The overlay tunnel orchestrator 142 can be a central management entity that manages the routes for traffic between the data center 150 and the branch office 110. To accomplish this task, the overlay tunnel orchestrator 142 must be aware of aspects of the network topology / configuration as well as the requirements of the network's endpoints. Based on this information, the overlay tunnel orchestrator 142 can then orchestrate routes between a suitable VPNC and a branch office gateway, and onward to interested recipients. As a central management entity within the SD-WAN 140, the overlay tunnel orchestrator 142 can gather this information and make these decisions in a way that reduces WAN bandwidth consumption. In other words, centralized decision-making within the overlay tunnel orchestrator 142 reduces the number of communications / decisions required to transmit traffic, e.g.,Multicast traffic required in a large-scale SD-WAN branch office is significantly reduced. As described above, with the decentralized approach of existing technologies, much of the above-mentioned information would be exchanged between the various network devices / nodes (e.g., routers, branch gateways, VPNCs) of a network tasked with transmitting data traffic. The overlay tunnel orchestrator 142 can obtain certain network configuration / topology information from other services of the SD-WAN orchestrator 144 and information about the needs of the network's recipients / hosts from specific branch gateways.

[0019] For example, the SD-WAN orchestrator 144 may include a Container-as-a-Service (CaaS) service (not shown), which may refer to a cloud-based service that provides enterprises with a way to manage their virtualized applications, clusters, and containers. A CaaS may include a container orchestration engine that operates and manages the infrastructure between an organization's clusters. A CaaS may also manage clusters associated with branch gateways, which may be referred to as BG clusters. Within a given BG cluster, there is a leader. As described in more detail below, only the leader of a given BG cluster (a) sends requests to join or leave a multicast group to the overlay multicast orchestrator 142 and (b) receives multicast traffic from any of the VPNCs located in the data center 150.By leveraging existing cloud-based service infrastructures and capabilities, examples of the technology presented here can enhance a multicast orchestration service without consuming significant additional WAN bandwidth, cloud resources, etc.

[0020] In some examples, a route calculation engine in the overlay tunnel orchestrator 142 may calculate routes for the traffic based on the aforementioned source information (e.g., which VPNC is connected to a particular multicast stream) and receiver information (which branch gateways are designated as leaders for the particular multicast stream). In some of these examples, the route calculation engine may learn to calculate optimal routes to reduce bandwidth consumption for the WAN 160. For example, the overlay tunnel orchestrator 142 may employ artificial intelligence (AI) or machine learning to determine overlay tunnels for multicast traffic between VPNCs and branch gateways based on traffic requirements and historical data.

[0021] In other examples, the overlay tunnel orchestrator 142 may utilize routes already calculated by the SD-WAN 140 (and / or its subservices). Existing SD-WAN services typically calculate routes for unicast traffic between VPNCs and branch gateways. Accordingly, the overlay tunnel orchestrator 142 may route traffic over these pre-calculated routes.

[0022] It should be noted that in a given network, the underlay (or underlay network) can refer to the physical connections of the network (e.g., Ethernet). In contrast, the overlay (or overlay network) can refer to a logical network that leverages virtualization to build connectivity on top of the physical infrastructure of the network by using tunnel encapsulation. In other words, "overlay tunnels" can refer to virtual connections that connect nodes of a network. In this case, overlay tunnels can connect VPNCs and branch gateways. Various protocols, such as IPSec and GRE, can be used to transport network traffic through these overlay tunnels. In general, SD-WAN architectures like the one shown here can rely on overlay tunnels to connect the various branch offices and other nodes of their network.

[0023] As used here, a branch office can refer to a physical location where one or more endpoint devices can connect to the WAN 160. For example, a branch office can be a remote office of an organization, a coffee shop, a home office, etc. While in the example of Fig. 1 only shows a single branch office (branch office 110), large-scale SD branch deployments can include any number of branch offices. In certain examples, these may be branches of a particular organization. In other examples, not all branches are connected to a single organization. Each branch office may have its own local area network (LAN), but this is not shown. The various network devices (e.g., hosts (user-associated devices), endpoint devices such as branch gateways, network devices such as routers, etc.) of a particular branch office can communicate with each other over the branch office's LAN. A branch office can have any number of endpoints. In this example, branch gateway 112 can receive traffic (e.g., multicast traffic) associated with traffic stream 152.

[0024] A particular host, such as smartphone 114, may be connected to (i.e., "behind") branch gateway 112. As described above, multiple branch gateways may be deployed within a branch office for load balancing and redundancy purposes. Accordingly, a particular host may connect to a specific branch gateway based on factors such as path latency.

[0025] A branch gateway can refer to a network device (hardware or software) that transmits traffic between a branch office and other networks. For example, the Fig. 1, the branch gateway 112 transmits traffic between the WAN 160 and the various network devices (not shown) of the branch office (e.g., other branch gateways, hosts, etc.).

[0026] As already indicated, if IPSec passthrough is enabled in network devices such as modems and routers, which are included in the example of Fig. 1, which owns modems 120 and 122, no overlay tunnel can be established using conventional mechanisms / methods. In this specific example, the uplinks from branch office 112 pass through two modems / routers 120 and 122, each connected to a different service provider, specifically an Internet service provider (ISP).

[0027] When the IPSec passthrough feature is enabled on a network device such as network device 120, which can be a modem, network device 120 checks for 4500 sessions for IKE transactions / exchanges between endpoint devices, such as VPNC 154 and branch gateway 112. Typically, a network device's UDP port 4500 is enabled for NAT traversal. As previously mentioned, network device 120 will not allow IPSec packets to pass through until an IKE exchange has occurred between the endpoints—in this example, between VPNC 154 and branch gateway 112. It should be understood that IPSec packets can pass through a network device without NAT traversal support using the IPSec passthrough feature.

[0028] In an SD-WAN-managed network, such as WAN 160, the overlay tunnel orchestrator 142 can establish an overlay tunnel without requiring an IKE exchange. Instead, the overlay tunnel orchestrator 142 can forward or transmit the (derived) IPSec keys directly to the endpoint devices. This example illustrates Fig. 1, such IPSec keys are transmitted over connections 142a and 142b to VPNC 154 and branch gateway 112, respectively. In this example, connections 142a and 142b are Internet or INET connections. It should be understood that INET connections are only one example of the type of connections / uplinks that may exist between endpoint devices. In other embodiments, the uplink may be a Multiprotocol Label Switching (MPLS) connection, an LTE / 4G connection, a Metro Ethernet connection, etc.

[0029] However, since the IPSec keys are transmitted from the cloud (overlay tunnel orchestrator 142) directly to VPNC 154 and the branch gateway 112, a key exchange according to the IKE protocol is not required. Therefore, there is no mechanism that enables such an IKE exchange. As a result, overlay packets (e.g., from the branch gateway 112), which would normally be used to establish an IPSec tunnel between the branch gateway 112 and the VPNC 154, are not allowed to pass through the network device / modem 120. As described in Fig. As shown in Figure 1, the overlay packets transmitted over connection 124 are inspected but ultimately discarded at modem 120, preventing the establishment of an IPSec tunnel (and subsequent overlay tunnel) between the endpoints, branch gateway 112, and VPNC 154. Accordingly, SD-WAN cloud-managed tunnel orchestration is not possible in traditional systems / methods that utilize the IPSec passthrough capability of network devices.

[0030] Under typical circumstances, the branch gateway 112 and the VPNC 154 would perform an IPSec key exchange using the IKE protocol (see Fig. 2A). Specifically, the branch gateway 112 and the VPNC 154 would perform an IKE_SA_INIT exchange (to establish a secure data channel). In this example, the branch gateway 112 may send a first IKE_SA_INIT packet 200 to the VPNC 154, which may be a request containing at least a proposed security association (SA) and key information. The purpose of such an IKE_SA_INIT exchange is for an initiator (in this example, the branch gateway 112) to send a list of SA proposals to a responder (in this example, the VPNC 154). A nonce and a Diffie-Hellman value may also be conveyed in the IKE_SA_INIT request 200. VPNC 154, as the responder, may select one of the SA proposals sent by branch gateway 112 (an SA proposal acceptable to VPNC 154) and send its selection in an IKE_SA_INIT message / response 202 (along with the corresponding nonce and Diffie-Hellman values).In some embodiments, message authentication, key generation, encryption algorithm, and Diffie-Hellman group information may be negotiated during this IKE_SA_INIT exchange. The Diffie-Hellman values ​​may refer to values ​​used by a Diffie-Hellman key algorithm to generate a shared master key that can be used by branch office 112 and VPNC 154 (or to derive IPSec keys for SAs).

[0031] Following the IKE_SA_INIT exchange, the branch gateway 112 and the VPNC 154 may independently generate key information to support IKE SA (this includes a key pair for authenticating IKE peers, a key pair for authenticating messages, and a key pair for encrypting messages sent under the protection of the established IKE SA, as well as key information that can be used to derive keys for subordinate SAs). The branch gateway 112 and VPNC 154 may perform an IKE_AUTH exchange. In particular, the IKE_AUTH exchange may be performed to authenticate VPNC 154 and create an initial IPSec SA. This completes the activation of the IKE SA, during which the branch 112 sends the IKE_AUTH request 204 (which specifies the network identity of the branch 112, e.g.,The IKE_SA_INIT request 200 transmits a user-defined authentication information (e.g., the IP or MAC address of branch office 112, and an identification certificate or other information / mechanism for identifying an endpoint device / network device), as well as authentication information depending on the type of authentication specified by an initiator (branch office 112) in its IKE_SA_INIT request 200. The authentication information may include an encrypted hash or a digital signature. The IKE_SA_INIT request 200, in some embodiments, may include an expected identity of the responder (VPNC 154). VPNC 154 may respond to the IKE_AUTH request 204 with an IKE_AUTH response 206 containing the identity and authentication information of VPNC 154.

[0032] Following the IKE_AUTH exchange, the branch gateway 112 and the VPNC 154 may perform an IKE_INFORMATIONAL exchange. The information that may be exchanged between the branch gateway 112 and the VPNC 154 via the IKE_INFORMATIONAL request 208 or the IKE_INFORMATIONAL response 210, respectively, may include one or more of the payloads "notification," "deletion," or "configuration." Notification payloads may contain error / status information. Deletion payloads may inform a peer network device that the sender of the IKE_informational request has deleted at least one of its incoming SAs and that the responder is expected to delete those SAs. Configuration payloads contain information that may be used to negotiate configuration data between peers (between the branch gateway 112 and the VPNC 154).

[0033] As previously mentioned, the IKE negotiation process is initiated so that the router / modem becomes aware of the IKE exchanges. This is done so that, from the router / modem's perspective, the first and second endpoint devices are endpoints of a legitimate IKE / IPSec session, allowing the establishment of an IKE / IPSec tunnel. In this example, network device 120 monitors / examines IPSec (or Encapsulating Security Payload (ESP) packets) between branch gateway 112 and VPNC 154. ESP refers to a specific protocol used by IPSec, and ESP packets are only allowed to pass through network device 120 if an IKE exchange has been observed between the first and second endpoint devices. By observing such IKE exchanges, network device 120 can consider the first and second endpoint devices to be "legitimate."The entirety of a typical IKE exchange (SA, authentication, and information exchange) should be completed to determine the legitimacy of the endpoint devices. Note that while IPSec utilizes the ESP protocol / packets, it can also utilize an Authentication Header (AH) protocol / packets. Therefore, monitoring / examining IPSec packets may, in some embodiments, also include monitoring / examining AH packets.

[0034] After determining that the endpoint devices in question—in this example, the branch gateway 112 and the VPNC 154—are legitimate, an IKE / IPSec tunnel can be established between the branch gateway 112 and the VPNC 154. In accordance with the SAs, the modem / router 120 can establish a firewall 214. In this example, the firewall 214 can be applied to data / traffic from traffic stream 152.

[0035] Now that the IKE / IPSec tunnel 212 has been established and IPSec passthrough is enabled, the branch gateway 112 and VPNC 154 can perform the aforementioned handshake process using the cloud-managed keys (received from the overlay tunnel orchestrator 142). This means that overlay packets (IPSec / ESP / AH) are allowed to pass through the modem 120. The negotiated IKE keys can be used until the cloud-managed keys become active. At that point, the negotiated IKE keys are removed / discarded and are no longer used to encrypt / secure traffic between the first and second endpoint devices. Once the branch gateway 112 and the VPNC 154 have completed the handshake process with the IPSec keys managed in the cloud, the overlay tunnel 218 can be established and the IKE / IPSec tunnel 212 can be torn down at process 220.As mentioned above, this dismantling is performed carefully to avoid any disruption to communication. It should be understood that the IKE / IPSec tunnel 212 is also an overlay tunnel. However, the IKE / IPSec tunnel 212 differs from the overlay tunnel 218 in the way the keys (on the basis of which the tunnels are generated) are derived. Again, the IKE / IPSec tunnel 212 is based on keys negotiated using the IKE / IPSec protocol, while the overlay tunnel 218 is based on cloud-managed keys.

[0036] Fig. 2B: Similar to Fig. 1, the SD-branch device 100 includes a first endpoint device (branch gateway 112 at the branch / customer location 110), Internet service providers (ISPS 130, 132) that form, at least in part, a WAN 160 controlled by SD-WAN 134, and a second endpoint device (VPNC 154 receiving traffic from traffic stream source 152) of the data center 150. Again, the traffic stream 152 may be any data transmission (e.g., streaming media, information dissemination, etc.) directed to one or more recipients / endpoints.

[0037] When the IPSec passthrough function is enabled in a network device, such as network device 120, network device 120 checks 4500 sessions for IKE transactions / exchanges between VPNC 154 and branch gateway 112. As described above, the IKE exchange is allowed to begin and continue until completion, so that after receiving the cloud-managed keys from the overlay tunnel orchestrator 142, the overlay packets (IPSec / ESP packets) can be routed through network device 120 to establish an overlay tunnel, e.g., to / from branch gateway 112 and VPNC 154 via links 120a and 124.

[0038] VPNC 154 and branch gateway 112 proceed with their handshaking process to establish an overlay tunnel between the two endpoint devices using the cloud-managed IKE keys obtained from the overlay tunnel orchestrator 142. Once the IKE / IPSec tunnel between VPNC 154 and branch gateway 112 is established, the handshaking process is possible (IPSec / IKE packets can now be exchanged). An overlay tunnel can then be established using the cloud-managed keys, and the original / initial IKE / IPSec tunnel (established according to the typical IKE exchange) can be gracefully torn down. As previously indicated, "graceful torn down" can refer to the IKE / IPSec tunnel being torn down without disrupting existing communication or data flows.In some embodiments, such "gentle teardown" may be accomplished by switching to the use of cloud-managed keys and overlay tunnels, maintaining the original IKE / IPSec tunnel with a timeout period before teardown. For example, the IKE / IPSec tunnel may have a timeout of 9 to 10 seconds to allow all incoming packets to be processed. Alternatively, the originally negotiated IKE keys may be discarded when no more packets arrive on the IKE / IPSec tunnel. Thus, instead of the IKE / IPSec overlay packets being dropped by / at network device 120, they are allowed through, allowing the overlay tunnel between branch gateway 112 and VPNC 154 to be established.

[0039] Fig. 3A and Fig. 3B are described in conjunction with each other. Fig. Figure 3A shows an example system architecture for bypassing an IKE firewall when using cloud-managed or cloud-provisioned IPSec / IKE keys, and Fig. Figure 3B shows a corresponding operating procedure for bypassing the IKE firewall.

[0040] As in Fig. As illustrated in Figure 3A, a computing device 300, which may be embodied as or within a network device, such as modem 120, may be implemented in a network, such as an SD-WAN, where the computing device 300 facilitates a connection between a branch gateway, such as branch gateway 112, and a remote endpoint device, such as a VPNC 154, to the Internet or other data network. It is understood that the computing device 300 may be connected to a particular Internet Service Provider (ISP).

[0041] Computing device 300 may include one or more computing components embodied by a hardware processor 302, e.g., one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices capable of retrieving and executing instructions stored in a machine-readable storage medium 304. Hardware processor 302 may retrieve, decode, and execute instructions, such as instructions that implement the Fig. 3B, as described in more detail below. Alternatively, or in addition to fetching and executing instructions, the hardware processor 302 may include one or more electronic circuits containing electronic components for performing the functionality of one or more instructions, such as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or other electronic circuits.

[0042] A machine-readable storage medium, such as machine-readable storage medium 304, may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. For example, machine-readable storage medium 304 may be random access memory (RAM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), a storage device, an optical disk, or the like. In some examples, machine-readable storage medium 304 may be a non-transitory storage medium, where the term "non-transitory" does not include transitory transmission signals. As described in detail below, machine-readable storage medium 304 may be encoded with executable instructions.

[0043] In some embodiments, computing device 300 may include a firewall creation component 306. As in Fig. 3B at operation 306a, a firewall session may be established after IKE negotiation between first and second network devices, such as endpoint devices. The IKE negotiation, or IKE exchange, may include, as described above, a series of requests and responses related to SA initialization to establish the required security associations, authentication of the first and second endpoint devices, and exchange of relevant information (such as certain notifications, configuration data, etc.). That is, the endpoint devices (or IPSec peers) are authenticated with IKE, and IKE SAs may be negotiated. IKE may negotiate the IPSec SA parameters, and appropriate IPSec SAs are established on the endpoint devices.The firewall session can be created to determine whether a packet should be processed and forwarded / transmitted or dropped (due to a protocol violation, information mismatch, etc.).

[0044] As described above, when the IPSec passthrough feature is enabled in a network device such as network device 300, the cloud-managed IKE / IPSec keys are distributed directly to the endpoint devices, rather than creating keys according to IKE negotiation. However, without IKE negotiation, network device 300 would drop / discard any IPSec / IKE overlay packets intended to establish an overlay tunnel. Therefore, the firewall session may operate to allow overlay packets to pass through network device 300. That is, according to operation 308a, the passage of IPSec data packets (or ESP packets) from the first network (endpoint) device to the second network (endpoint) device is permitted. A first (IKE / IPSec) tunnel may then be established.Establishing this first tunnel enables the first and second network (endpoint) devices to perform a handshake operation with IPSec data packets to establish a second tunnel, including a cloud-managed overlay tunnel at operation 310a. Thus, instead of being dropped by network device 300, the IPSec data packets can pass through network device 300 after receiving cloud-managed IPSec / IKE keys from an SD-WAN orchestrator to facilitate the establishment of the overlay tunnel. The first tunnel can be gracefully torn down once the second / overlay tunnel is established.

[0045] Fig.Figure 4 shows a block diagram of an example computer system 400 in which various embodiments described herein may be implemented. Computer system 400 includes a bus 402 or other communication mechanism for conveying information, and one or more hardware processors 404 connected to bus 402 for processing information. For example, hardware processor(s) 404 may be one or more general-purpose microprocessors.

[0046] Computer system 400 also includes main memory 406, such as random access memory (RAM), a cache, and / or other dynamic storage devices connected to bus 402, for storing information and instructions to be executed by processor 404. Main memory 406 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 404. When such instructions are stored in storage media accessible to processor 404, computer system 400 becomes a special-purpose machine adapted to perform the operations specified in the instructions.

[0047] Computer system 400 further includes a read-only memory (ROM) 408 or other static storage device connected to bus 402 for storing static information and instructions for processor 404. A storage device 410, such as a magnetic disk, an optical disk, or a USB flash drive, etc., is provided and connected to bus 402 for storing information and instructions.

[0048] Computer system 400 may be connected to a display 412, such as a liquid crystal display (LCD) (or a touch screen), via bus 402 to display information to a computer user. An input device 414, including alphanumeric and other keys, is coupled to bus 402 to communicate information and command selections to processor 404. Another type of user input device is cursor control 416, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to processor 404 and controlling cursor movement on display 412. In some embodiments, the same direction information and command selections as with cursor control may be implemented via receiving touches on a touchscreen without a cursor.

[0049] Computer system 400 may include a user interface module for implementing a graphical user interface, which may be stored on a mass storage device as executable software code executed by the computing device(s). This and other modules may include, for example, components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0050] In general, the word "component," "engine," "system," "database," "data store," and the like, as used herein, may refer to logic embodied in hardware or firmware, or to a collection of software instructions that may have entry and exit points and may be written in a programming language such as Java, C, or C++. A software component may be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as BASIC, Perl, or Python. It is understood that software components may be callable by other components or by themselves, and / or may be called in response to detected events or interrupts. Software components configured to run on computing devices may be embodied on a computer-readable medium, such as a hard disk.a compact disc, digital video disc, flash drive, magnetic disk, or other tangible medium, or as a digital download (and may be originally stored in a compressed or installable format that must be installed, decompressed, or decrypted before execution). Such software code may be stored partially or entirely in a memory of the executing computing device so that it can be executed by the computing device. Software instructions may be embedded in firmware, such as an EPROM. In addition, the hardware components may consist of interconnected logic units, such as gates and flip-flops, and / or programmable units, such as programmable gate arrays or processors.

[0051] Computer system 400 may implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, makes or programs computer system 400 into a special-purpose machine. According to one embodiment, the techniques described herein are performed by computer system 400 in response to processor(s) 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another storage medium, such as storage device 410. Execution of the instruction sequences contained in main memory 406 causes processor(s) 404 to perform the process steps described herein.In alternative embodiments, hard-wired circuits may be used instead of or in combination with software instructions.

[0052] The term "non-transitory media" and similar terms as used herein refer to any media that stores data and / or instructions that cause a machine to operate in a particular manner. Such non-transitory media may include non-volatile media and / or volatile media. Examples of non-volatile media include optical or magnetic disks, such as storage device 410. Volatile media includes dynamic memory, such as main memory 406. Common forms of non-transitory media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or other magnetic data storage media, CD-ROMs, other optical data storage media, physical media with hole patterns, RAM, PROM and EPROM, FLASH EPROM, NVRAM, other memory chips or cartridges, and networked versions thereof.

[0053] Non-transitory media are distinct from transmission media but can be used in conjunction with them. Transmission media are involved in the transfer of information between non-transitory media. Examples of transmission media include coaxial cables, copper cables, and fiber optic cables, including the wires that make up bus 402. Transmission media can also take the form of sound or light waves, such as those generated in data communications via radio and infrared waves.

[0054] Computer system 400 also includes a communications interface 418 connected to bus 402. Network interface 418 establishes a two-way data communications connection to one or more network connections connected to one or more local area networks. For example, communications interface 418 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem for establishing a data communications connection to a corresponding type of telephone line. As another example, network interface 418 may be a Local Area Network (LAN) card for establishing a data communications connection to a compatible LAN (or a WAN component for communicating with a WAN). Wireless connections may also be implemented.In each of these implementations, the network interface 418 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams containing various types of information.

[0055] A network connection typically enables data communication across one or more networks to other data devices. For example, a network connection may connect across a local area network to a host computer or data devices operated by an Internet service provider (ISP). The ISP, in turn, provides data communication services across the worldwide packet data communications network, now commonly referred to as the "Internet." Both the local area network and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. The signals across the various networks and the signals on the network connection and across the communications interface 418 that carry the digital data to and from the computer system 400 are examples of transmission media.

[0056] Computer system 400 can send messages and receive data, including program code, over the network(s), the network connection, and the communications interface 418. In the Internet example, a server could transmit requested code for an application program over the Internet, the ISP, the local network, and the communications interface 418.

[0057] The received code may be executed by processor 404 as soon as it is received and / or stored in storage device 410 or other non-volatile memory for later execution.

[0058] The processes, methods, and algorithms described in the preceding sections may each be embodied in, and fully or partially automated by, code components executed by one or more computer systems or computer processors comprising computer hardware. The one or more computer systems or computer processors may also operate to support the performance of the corresponding operations in a cloud computing environment or as software as a service (SaaS). The processes and algorithms may be partially or fully implemented in application-specific circuitry. The various features and methods described above may be used independently of one another or combined in various ways.Various combinations and subcombinations are intended to be within the scope of this disclosure, and certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the associated blocks or states may be executed in other suitable orders, in parallel, or otherwise. Blocks or states may be added to or removed from the disclosed examples. The execution of certain operations or processes may be distributed among computer systems or computer processors located not only on a single machine, but distributed across a number of machines.

[0059] A circuit may be implemented in any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms may be implemented to form a circuit. In implementation, the various circuits described herein may be implemented as discrete circuits, or the described functions and features may be distributed, in part or in whole, among one or more circuits. Even though various features or functional elements are individually described or claimed as separate circuits, those features and functions may be shared by one or more common circuits, and such description is not intended to assume or imply that separate circuits are required to implement those features or functions.If a circuit is implemented in whole or in part with software, that software may be implemented to operate with a computer or processing system capable of performing the functionality described with respect to it, such as computer system 400.

[0060] As used herein, the term "or" can be interpreted both inclusively and exclusively. Furthermore, descriptions of resources, acts, or structures in the singular should not be construed as excluding the plural. Conditional phrases such as "may," "can," "could," or "might," unless expressly stated otherwise or understood by context, are generally understood to imply that certain embodiments include certain features, elements, and / or steps, while other embodiments do not.

[0061] Unless expressly stated otherwise, the terms and expressions used in this document, as well as their variations, are not to be interpreted as limiting but as open-ended. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar import are not to be construed as limiting the subject matter described to a particular period of time or to a subject matter available at a particular time, but should be understood to include conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future.The presence of broader words and expressions such as “one or more,” “at least,” “but not limited to,” or similar expressions in some cases should not be construed as meaning that the narrower case is intended or required in the absence of such broader expressions.

[0062] It should be noted that the terms "optimize," "optimal," and the like, as used herein, may be used to mean making or achieving performance as effective or perfect as possible. However, as one of ordinary skill in the art will understand upon reading this document, perfection cannot always be achieved. Accordingly, these terms may also mean making or achieving performance as good or effective as possible or practical under the circumstances, or making or achieving performance better than that achievable with other settings or parameters.

Claims

[1] A process comprising: at a first network device (120, 122) between a second network device (112) and a third network device (154), detecting an Internet Key Exchange Protocol (IKE) key negotiation between the second network device and the third network device; based on the detection of the IKE key negotiation! between the second network device and the third network device, creating a firewall session in the first network device between the second and the third network device, wherein a first Internet Protocol Security (IPSec) tunnel (212) is established by the first network device between the second and the third network device using the IKE key negotiation, the first tunnel being compliant with the firewall session and allowing the passage of IPSec data packets through the first network device between the second and the third network device; Passing the IPSec data packets exchanged between the second and third network devices through the first network device based on the establishment of the first tunnel using cloud-managed IPSec keys from a cloud-based orchestrator (142), wherein the IPSec data packets are exchanged as part of a handshake operation that results in the establishment of a second tunnel between the second and third network devices according to the cloud-managed IPSec keys, the second tunnel being an overlay tunnel (218) on an underlay network; and After the second tunnel has been established and the cloud-managed IPSec keys are active, discard the negotiated IKE and carefully dismantle the first IPSec tunnel without disrupting encrypted communication between the second and third network devices. [2] The method of claim 1, wherein the second network device comprises a branch gateway (112) operating in a software-defined wide area network (SD-WAN) (140). [3] The method of claim 2, wherein the cloud-based orchestrator is an SD-WAN orchestrator (144). [4] The method of claim 1, wherein the second network device comprises a virtual private network concentrator operating in a software-defined wide area network (SD-WAN). [5] The method of claim 1, comprising enabling an IPSec passthrough function at the first network device. [6] A first network device (110, 300) comprising: a hardware processor (302, 404) and a non-transitory storage medium (304, 406, 408, 410) storing instructions executable on the hardware processor for: Performing an Internet Key Exchange Protocol (IKE) key negotiation with a second network device (154) comprising an exchange of messages passed through a third network device (120, 122) between the first network device and the second network device; establishing a first Internet Protocol Security (IPSec) tunnel (212) between the first network device and the second network device using keys from the IKE key negotiation, the first IPSec tunnel passing through the third network device; Receiving cloud-managed IPSec keys at the first network device from a cloud-based orchestrator (142); Performing a handshake operation between the first network device and the second network device, in which IPSec data packets in the first IPSec tunnel are passed through the third network device, the IPSec data packets being intended for establishing a second tunnel according to cloud-managed IPSec keys; wherein the second tunnel is an overlay tunnel (218) on an underlay network; and After the second tunnel has been established and the cloud-managed IPSec keys are active, discard the negotiated IKE and carefully dismantle the first IPSec tunnel without disrupting encrypted communication between the second and third network devices. [7] The first network device of claim 6, wherein the first network device comprises a branch gateway (112). [8] The first network device according to claim 6, wherein the IPSec data packets are passed through the third network device according to an IPSec passthrough function enabled on the third network device. [9] The first network device of claim 6, wherein the first network device comprises a virtual private network concentrator. [10] The first network device of claim 6, wherein tearing down the first tunnel comprises: Disabling a connection between the first network device and the second network device. [11] The network device of claim 6, wherein tearing down the first tunnel comprises: Discard the negotiated IKE keys from the key negotiation. [12] A non-transitory machine-readable storage medium (304, 406, 408, 410) comprising instructions that, when executed, cause a first network device (110, 300) to: Performing an Internet Key Exchange Protocol (IKE) key negotiation on the first network device with a second (154) network device, comprising an exchange of messages passed through a third network device (120, 122) between the first network device and the second network device, establishing a first Internet Protocol Security (IPSec) tunnel (212) between the first network device and the second network device using keys from the IKE key negotiation, the first IPSec tunnel passing through the third network device; Receiving cloud-managed IPSec keys at the first network device from a cloud-based orchestrator (142); Performing a handshake operation between the first network device and the second network device, in which IPSec data packets in the first tunnel are passed through the third network device, the IPSec data packets being intended for establishing a second tunnel; between the first network device and the second network device, establishing the second tunnel according to the cloud-managed IPSec keys, wherein the second tunnel is an overlay tunnel (218) on an underlay network; and After the second tunnel has been established and the cloud-managed IPSec keys are active, discard the negotiated IKE and carefully dismantle the first IPSec tunnel without disrupting encrypted communication between the second and third network devices. [13] The non-transitory machine-readable storage medium of claim 12, wherein tearing down the first tunnel comprises: Disabling a connection between the first network device and the second network device or Discard the IPSec keys from the key negotiation. [14] The non-transitory machine-readable storage medium of claim 12, wherein the first network device comprises a branch gateway (112) or a virtual private network concentrator.

Images