IPSEC Key Bypass IKE Firewall for Cloud Management in the SDWAN Architecture

Abstract

Various embodiments of the present disclosure relate to bypassing IKE firewalls for cloud-managed IPSEC keys in SD-WAN architectures. Systems and methods are provided for implementing overlay tunnels between software-defined wide area network (SD-WAN) endpoint devices, while using IPSec pass-through in one or more network devices (such as a modem or router that exists between the endpoint devices). Specifically, the Internet Key Exchange (IKE) protocol can be allowed to proceed until the modem / router is able to establish the IKE tunnel, after which overlay packets using cloud-managed keys can be allowed to pass through the modem / router. The overlay tunnel can then be established between the endpoint devices, and the IKE tunnel can be closed.

Description

Background Art

[0001] In computer networking, a virtual private network (VPN) can refer to an encrypted connection from a device to a network over the internet, where the encryption protects any sensitive data transmitted between the device and the network. Thus, a VPN allows a user to access, for example, a private network via a public network (such as the internet) and exchange sensitive data remotely.

[0002] Associated with VPN is Internet Protocol Security (IPSec), which actually refers to a set of protocols used to encrypt data packets in order to facilitate secure connections between devices exchanging data packets. IPSec can be thought of as a security layer that is itself embedded in the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure is described in detail with reference to the following drawings, in accordance with one or more different embodiments. The drawings are provided for illustration purposes only and merely depict typical or example embodiments.

[0004] Figure 1 Illustrated is an example of an SD-WAN in which embodiments of the present disclosure may be implemented.

[0005] Figure 2A Figure 1 is an example message flow for implementing cloud-managed tunnel orchestration between network devices, albeit using the IPSec pass-through mechanism.

[0006] Figure 2B Pictured Figure 1 An example of an SD-WAN that is adapted to allow cloud-managed tunnel orchestration, albeit using an IPSec pass-through mechanism.

[0007] Figure 3A Illustrated is an example system architecture that may be implemented to perform cloud-managed tunnel orchestration in accordance with various embodiments.

[0008] Figure 3B is an example flow diagram illustrating example operations that may be performed to implement cloud-managed tunnel orchestration in accordance with various embodiments.

[0009] Figure 4 are example computing components that can be used to implement various features of the embodiments described in this disclosure.

[0010] The drawings are not exhaustive and do not limit the disclosure to the precise form disclosed. DETAILED DESCRIPTION

[0011] As described above, network devices can use IPSec to protect sensitive data during transmission in a VPN, where IPSec keys can be used by the network devices to enable an overlay tunnel to be established between the network devices. A feature called IPSec pass-through allows an IPSec tunnel to "pass through" a network device, such as a router or modem. That is, some network devices (such as routers / modems) typically connect to the Internet using a Network Address Translation (NAT) protocol that is incompatible with IPSec. The IPSec pass-through feature makes IPSec compatible with the NAT protocol, where the Layer 2 Tunneling Protocol (L2TP) can be used to support point-to-point sessions over the Internet at the L2 level.

[0012] One environment where using IPSec can be problematic is in software-defined wide-area networks (SD-WANs). In a software-defined branch deployment, SD-WAN technology can be used to centralize the management of an organization's WAN across multiple physical branch locations. SD-WAN technology, typically implemented as a cloud-based management solution, relies on virtualization, overlay networks, and on-site SD-WAN appliances and software platforms to, among other things, better manage network traffic.

[0013] When using cloud-managed tunnel orchestration in SD-WAN, the IPSec data packets used to set up the above-mentioned overlay tunnel will be dropped at the router / modem, thereby preventing the overlay tunnel from being established. This is because with cloud-managed IPSec keys, network devices (such as gateways, VPNCs, etc.) can connect to the SD-WAN orchestrator in the cloud and receive IPSec keys. Subsequently, for example, the first endpoint device will attempt to send a bootstrap encrypted data packet to determine whether the second endpoint device has received the IPSec key. As used herein, an endpoint device may refer to a network device / hardware controller that is capable of communicating with a network (such as the gateway and VPNC mentioned above). Upon receiving a response from the second endpoint device, an overlay tunnel is typically established between the first endpoint device and the second endpoint device.

[0014] However, when a network device such as a router / modem uses the IPSec pass-through feature (which is typically enabled by default in next-generation router / modem configurations), the NAT traversal session between the first endpoint device and the second endpoint device is inspected. IPSec data packets are allowed to pass through the router / modem between the first endpoint device and the second endpoint device only if an Internet Key Exchange (IKE) protocol exchange occurs and is observed. It should be understood that most IPSec implementations include an IKE daemon running in user space and an IPSec stack that processes IP data packets. IKE is the protocol used in the IPSec protocol to establish security associations (SAs). Due to the IPSec pass-through feature, there is no need to perform an IKE exchange. Instead, the first endpoint device and the second endpoint device can simply receive IPSec keys from the cloud-based SD-WAN orchestrator for direct use, where the first endpoint device and the second endpoint device engage in (multiple) types of direct handshakes using the IPSec keys to establish the overlay tunnel. It should be understood that no traffic can be transmitted between the first endpoint device and the second endpoint device without performing an IKE exchange, i.e., an IKE protocol exchange should typically be performed before the overlay tunnel is established using the IPSec keys.

[0015] Accordingly, various embodiments are directed to circumventing or bypassing the IKE firewall / exchange requirements of the IPSec pass-through feature. Specifically, when network devices (such as the first and second endpoint devices discussed above) attempt to exchange data, each device is connected to a cloud-based SD-WAN orchestrator and can receive IPSec keys. An IKE negotiation process is initiated, making the router / modem 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, thereby enabling the establishment of an IKE / IPSec tunnel. The first and second endpoint devices perform a handshake operation using IPSec data packets using cloud-managed IPSec keys provided by the cloud-managed SD-WAN orchestrator. Because 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. Thereafter, the IKE / IPSec tunnel can be (gracefully) closed. Graceful closure of the IKE / IPSec tunnel can refer to disabling the link between the first and second endpoint devices without causing a communication interruption or impacting / impacting user data traffic therebetween. In this way, an overlay tunnel can be established between endpoint devices despite the use of IPSec pass-through in a device such as a router / modem, where the uplink passes through the router / modem.

[0016] Figure 1 An example SD-branch deployment according to various examples of the presently disclosed technology is depicted. The SD-branch deployment 100 includes a first endpoint device, such as a branch gateway 112 at a branch / customer site 110, an Internet Service Provider (ISPS 130, 132) that at least partially constitutes a WAN 160 controlled via an SD-WAN 134, and a second endpoint device, which in this case may be a VPNC 154 of a data center 150 (which receives traffic from a traffic flow source 152).

[0017] A traffic flow 152 may be any data transmission (e.g., streaming media, information dissemination, etc.) addressed to one or more receivers / endpoints. Figure 1 In the example shown, only one service flow (i.e., service flow 152) is depicted in the data center source 150. However, in other examples, the data center 150 may include any number of service flows. In short, the SD-branch deployment 100 may include any number of service sources, receivers, etc.

[0018] In general, a VPNC (such as VPNC 154) can refer to a hardware or software application used to connect to a VPN. As depicted, data center 150 includes VPNC 154. Thus, VPNC 154 can be used to transmit data associated with traffic flow 152 to one or more branches, in this example, to branch gateway 112 of branch 110 (orchestrated by overlay tunnel orchestrator 142).

[0019] SD-WAN 140 may be a cloud-based SD-WAN technology platform that includes a centralized service capable of performing orchestration operations within a given WAN (e.g., WAN 160). Generally, SD-WAN orchestration may refer to centralized management service(s) that provide cloud-delivered WAN control and management. In certain examples, SD-WAN 140 may include additional centralized network management services. Thus, residing within SD-WAN 140 may be various sub-services. As depicted, SD-WAN 140 includes overlay tunnel orchestrator 142, which may be a sub-service of SD-WAN orchestrator 144 that, in addition to orchestrating tunnels, may also orchestrate routing, orchestrate key exchanges, and the like.

[0020] The overlay tunnel orchestrator 142 may be a central management entity that orchestrates routing for traffic between the data center 150 and the branch 110. To accomplish this task, the overlay tunnel orchestrator 142 must understand various aspects of the network topology / configuration, as well as the needs of the network endpoints. With this information, the overlay tunnel orchestrator 142 may then orchestrate routing between the appropriate VPNCs and branch gateways and on to the recipients of interest. As a central management entity contained within the SD-WAN 140, the overlay tunnel orchestrator 142 may gather this information and make these determinations in a manner that reduces WAN bandwidth consumption. In other words, centralized decision making within the overlay tunnel orchestrator 142 greatly reduces the number of communications / decisions required to transport traffic (such as multicast traffic) within, for example, a large-scale SD-branch deployment. As described above, under the decentralized approach used by the prior art, much of the aforementioned information would be communicated between the various network devices / nodes (e.g., routers, branch gateways, VPNCs) of the network responsible for transporting the traffic. Overlay tunnel orchestrator 142 may obtain certain network configuration / topology information from additional service(s) of SD-WAN orchestrator 144, as well as information related to the needs of the network's receivers / hosts from designated branch gateway leaders.

[0021] 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 an organization with a way to manage its virtualized applications, clusters, and containers. CaaS may include a container orchestration engine that runs and maintains infrastructure between the organization's clusters. CaaS may also manage clusters associated with branch gateways, which may be referred to as BG clusters. Within a given BG cluster, there will be only one leader. As will be described in more detail below, only the leader of a given BG cluster will: (a) send a request to the overlay multicast orchestrator 142 to join or leave a multicast group; and (b) receive multicast traffic from one of the VPNCs residing in the data center 150. By leveraging existing cloud-based service infrastructure and features, examples of the presently disclosed technology can enhance multicast orchestration services without consuming large amounts of additional WAN bandwidth, cloud resources, etc.

[0022] In some examples, a routing calculation engine in overlay tunnel orchestrator 142 can calculate routes for traffic based on the aforementioned source information (e.g., which VPNC is associated with a given multicast flow) and receiver information (which branch gateway is the designated leader for a given multicast flow). In some of these examples, the routing calculation engine can learn to calculate optimal routes for reducing bandwidth consumption on WAN 160. For example, overlay tunnel orchestrator 142 can employ artificial intelligence (AI) or machine learning to determine overlay tunnels for multicast traffic between VPNCs and branch gateways based on traffic needs and historical data.

[0023] In other examples, overlay tunnel orchestrator 142 can leverage routes already calculated by SD-WAN 140 (and / or its sub-services). Existing SD-WAN services typically calculate routes for unicast traffic between VPNCs and branch gateways. Therefore, overlay tunnel orchestrator 142 can orchestrate traffic using these pre-calculated routes.

[0024] It should be understood that in a given network, the underlay (or underlay network) may refer to the physical connections of a network (e.g., Ethernet). In contrast, an overlay (or overlay network) may refer to a logical network that uses virtualization to establish connectivity on top of the physical infrastructure of the network using tunnel encapsulation. In other words, an "overlay tunnel" may refer to a virtual link connecting network nodes. Here, an overlay tunnel may connect a VPNC and a branch gateway. Various protocols such as IPSec and GRE may be used to transport network traffic through these overlay tunnels. Typically, an SD-WAN architecture such as the one described may rely on overlay tunnels to connect the various branches and other nodes of its network.

[0025] As used herein, a branch may refer to a physical location where one or more endpoint devices may connect to the WAN 160. For example, a branch may be an organization's remote office, a cafe / coffee shop, a home office, etc. Figure 1 The example depicted in FIGURE 1 depicts only a single branch (branch 110), but a large-scale SD-branch deployment can include any number of branches. In some examples, these can be branches of a particular organization. In other examples, the branches may not all be associated with a single organization. Although not depicted, each branch can have its own local area network (LAN). Various network devices of a given branch (e.g., hosts (user-related devices), endpoint devices (such as branch gateways), network devices (such as routers, etc.)) can communicate with each other via the branch's LAN. A branch can have any number of endpoints. In this example, branch gateway 112 can receive services associated with service flow 152 (such as multicast services).

[0026] A given host (an example of which is a smartphone 114) may be connected to (i.e., "behind") a branch gateway 112. As described above, multiple branch gateways may be deployed at a branch for load balancing and redundancy purposes. Thus, a given host may connect to a given branch gateway based on factors such as path latency.

[0027] A branch gateway can refer to a network device (hardware or software) that transmits traffic between a branch and other networks. For example, Figure 1The branch gateways 112 depicted in FIG. 1 can transmit traffic between the WAN 160 and various network devices (not shown) at their branches (eg, other branch gateways, hosts, etc.).

[0028] As mentioned above, when network devices such as modems and routers ( Figure 1 In an example of a branch gateway 112 (including modems 120 and 122), when IPSec pass-through is enabled, an overlay tunnel cannot be established according to conventional mechanisms / methods. In this particular example, the uplink from the branch gateway 112 passes through two modems / routers 120 and 122, each of which is associated with a different service provider, specifically an Internet Service Provider (ISP).

[0029] When the IPSec pass-through feature is enabled in a network device (such as network device 120, which can be a modem), the network device 120 checks for 4500 sessions for IKE transactions / exchanges between endpoint devices (e.g., VPNC 154 and branch gateway 112). Typically, the network device's UDP port 4500 is enabled for NAT traversal. As described above, the network device 120 allows IPSec data packets to pass only after an IKE exchange has been performed between the endpoints, in this example, VPNC 154 and branch gateway 112. It should be understood that IPSec data packets can pass through a network device that does not have NAT traversal support (relative to the IPSec pass-through feature).

[0030] In an SD-WAN managed network such as WAN 160, overlay tunnel orchestrator 142 may establish an overlay tunnel without requiring an IKE exchange. Instead, overlay tunnel orchestrator 142 may push or transmit the IPSec keys (derived) directly to the endpoint device. In this example, Figure 1 Such IPSec keys are illustrated as being pushed to VPNC 154 and branch gateway 112 via links 142a and 142b, respectively. In this example, links 142a and 142b are Internet or INET links. It should be understood that an INET link is only one example of a type of link / uplink that can exist between endpoint devices. In other embodiments, the uplink can be a Multi-Protocol Label Switching (MPLS) link, a Long Term Evolution (LTE) / 4G link, a Metro Ethernet link, etc.

[0031] However, because the IPSec keys are provided directly from the cloud (overlay tunnel orchestrator 142) to the VPNC 154 and the branch gateway 112, there is no need to perform a key exchange according to the IKE protocol. Therefore, there is no mechanism to allow such an IKE exchange to occur. As a result, overlay packets (from, for example, the branch gateway 112) that 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. Therefore, as Figure 1 As shown, the overlay packets transmitted via link 124 are inspected but ultimately discarded at modem 120, and therefore, an IPSec tunnel (nor a subsequent overlay tunnel) cannot be established between the endpoints (branch gateway 112 and VPNC 154). Accordingly, SD-WAN cloud-managed tunnel orchestration is not possible in conventional systems / methods that involve the use of IPSec pass-through features of network devices.

[0032] Now refer to Figure 2A In a typical scenario, the branch gateway 112 and VPNC 154 will engage in an IPSec key exchange using the IKE protocol. Specifically, the branch gateway 112 and VPNC 154 will engage in an IKE_SA_INIT exchange (to establish a secure data channel). In this example, the branch gateway 112 may transmit an initial IKE_SA_INIT packet 200 to the VPNC 154, which may be a request including at least a proposed security association (SA) and key information. The purpose of this IKE_SA_INIT exchange is for the initiator (in this example, the branch gateway 112) to send a list of SA proposals to the responder (in this example, the VPNC 154). A nonce and Diffie-Hellman value may also be transmitted in the IKE_SA_INIT request 200. The VPNC 154, as the responder, may select one of the SA proposals sent by the branch gateway 112 (an SA proposal acceptable to the VPNC 154) and transmit its selection (along with its corresponding nonce and Diffie-Hellman value) in the responding IKE_SA_INIT message / response 202. In some embodiments, message authentication, key generation, encryption algorithms, and Diffie-Hellman group information can be negotiated during this IKE_SA_INIT exchange. It should be understood that the Diffie-Hellman value can refer to the value used by the Diffie-Hellman key algorithm to generate a shared master key that can be used by the branch gateway 112 and VPNC 154 (or to derive IPSec keys for the SA).

[0033] Following the IKE_SA_INIT exchange, the branch gateway 112 and VPNC 154 can independently generate keying information to support the IKE SA. This information can include a key pair for authenticating the IKE peers, a key pair for authenticating messages, a key pair for encrypting messages sent under the established IKE SA, and keying information that can be used to derive keys for child SAs. The branch gateway 112 and VPNC 154 can then engage in an IKE_AUTH exchange. Specifically, the IKE_AUTH exchange can be performed to authenticate the VPNC 154 and create the first IPSec SA. This completes the activation of the IKE SA, with the branch gateway 112 transmitting an IKE_AUTH request 204 (which contains the network identity of the branch gateway 112, e.g., the IP or MAC address of the branch gateway 112, and an identification certificate, or other information / mechanism for identifying the endpoint device / network device), and authentication information, which depends on the authentication type specified by the initiator (branch gateway 112) in its IKE_SA_INIT request 200. The authentication information can include an encrypted hash or a digital signature. In some embodiments, the IKE_SA_INIT request 200 may include the identity of the intended responder (VPNC 154). The VPNC 154 may respond to the IKE_AUTH request 204 with an IKE_AUTH response 206 that includes the VPNC 154's identity and authentication information.

[0034] Following the IKE_SA_INIT exchange, the branch gateway 112 and VPNC 154 may engage in an IKE_INFORMATIONAL exchange. The information exchanged between the branch gateway 112 and VPNC 154 via the IKE_INFORMATIONAL request 208 and IKE_INFORMATIONAL response 210, respectively, may include one or more of the following: a "Notification" payload, a "Delete" payload, or a "Configuration" payload. The Notification payload may carry error / status information. The Delete payload may notify the peer network device that the sender of the IKE_informational request has deleted at least one of its incoming SAs and that the responder should delete these SAs. The Configuration payload contains information that can be used to negotiate configuration data between the peers (between the branch gateway 112 and VPNC 154).

[0035] As described above, the IKE negotiation process is initiated so that the router / modem can become aware of the IKE exchange. This is done so that, from the perspective of the router / modem, the first endpoint device and the second endpoint device comprise endpoints of a legitimate IKE / IPSec session, thereby enabling the establishment of an IKE / IPSec tunnel. In this example, network device 120 monitors / inspects 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 through network device 120 if an IKE exchange is observed to have occurred between the first endpoint device and the second endpoint device. By observing such an IKE exchange, network device 120 can deem the first endpoint device and the second endpoint device to be "legitimate." To determine the legitimacy of the endpoint devices, a typical IKE exchange (SA, authentication, and information exchange) should be completed. It should be noted that while IPSec utilizes the ESP protocol / packets, IPSec can also utilize the Authentication Header (AH) protocol / packets. Therefore, in some embodiments, monitoring / inspecting IPSec packets may include monitoring / inspecting AH packets.

[0036] Upon determining that the endpoint devices in question are legitimate, in this example, branch gateway 112 and VPNC 154, an IKE / IPSec tunnel can be established between branch gateway 112 and VPNC 154. Based on the SA, modem / router 120 can establish firewall 214. In this example, firewall 214 can be applied to data / traffic from traffic flow 152.

[0037] Now that the IKE / IPSec tunnel 212 has been established and IPSec pass-through is enabled, the branch gateway 112 and VPNC 154 can perform the handshake process described above using the cloud-managed keys (received from the overlay tunnel orchestrator 142). That is, overlay (IPSec / ESP / AH) packets are allowed to pass through the modem 120. The negotiated IKE keys can be used until the cloud-managed keys become active, at which point the negotiated IKE keys are removed / discarded and no longer used to encrypt / protect traffic between the first and second endpoint devices. Once the branch gateway 112 and VPNC 154 have completed the handshake operation using the cloud-managed IPSec keys, the overlay tunnel 218 can be established, and the IKE / IPSec tunnel 212 can be closed at operation 220. As described above, this closure is performed smoothly to avoid any disruption to communications. 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 terms of how the keys (on which the tunnel is generated) are derived. Likewise, the IKE / IPsec tunnel 212 is based on keys negotiated by the IKE / IPSec protocol, while the overlay tunnel 218 is based on cloud-managed keys.

[0038] Now refer to Figure 2B ,and Figure 1 Similarly, SD-branch deployment 100 includes a first endpoint device (branch gateway 112 at a branch / customer site 110), internet service providers (ISPS 130, 132) that at least partially comprise a WAN 160 controlled via SD-WAN 134, and a second endpoint device (VPNC 154) at a data center 150 that receives traffic from a traffic flow source 152. Likewise, traffic flow 152 can be any data transmission (e.g., streaming media, information dissemination, etc.) addressed to one or more receivers / endpoints.

[0039] When the IPSec pass-through feature is enabled in a network device such as network device 120, network device 120 examines 4500 sessions for IKE transactions / exchanges between VPNC 154 and spoke gateway 112. As described above, the IKE exchange(s) are allowed to begin and proceed to completion so that, upon receiving cloud-managed keys from overlay tunnel orchestrator 142, overlay packets (IPSec / ESP packets) used to establish overlay tunnels can pass through network device 120, e.g., over links 120 a and 124, to / from spoke gateway 112 and VPNC 154.

[0040] VPNC 154 and branch gateway 112 continue their handshake process to establish the overlay tunnel between the two endpoint devices using the cloud-managed IKE keys received from overlay tunnel orchestrator 142. Now that the IKE / IPSec tunnel has been established between VPNC 154 and branch gateway 112, the handshake process can proceed (IPSec / IKE packets can now be exchanged). The overlay tunnel can then be established using the cloud-managed keys, and the original / initial IKE / IPSec tunnel (established according to a typical IKE exchange) can be gracefully closed. As previously described, a graceful close can refer to closing the IKE / IPSec tunnel without disrupting existing communications or data flows. In some embodiments, this graceful close can be achieved by switching to using cloud-managed keys and the overlay tunnel, while maintaining the timeout duration of the initial IKE / IPSec tunnel before closing. For example, the IKE / IPSec tunnel can have a timeout of 9 to 10 seconds to allow any transmitted / incoming packets to be processed. Alternatively, the original IKE negotiated keys can be discarded when there are no longer any incoming packets on the IKE / IPSec tunnel. Thus, instead of the IKE / IPSec overlay packets being dropped by or at the network device 120 , they are allowed to pass so that an overlay tunnel can be established between the branch gateway 112 and the VPNC 154 .

[0041] Figure 3A and Figure 3B They will be described in conjunction with each other. Figure 3A illustrates an example system architecture for bypassing IKE firewalls when using cloud-managed or cloud-provided IPSec / IKE keys, and Figure 3B The diagram shows the corresponding operation method for bypassing the IKE firewall.

[0042] like Figure 3A As shown, the computing device 300 can be embodied as / in a network device such as the modem 120. The computing device 300 can be implemented in a network such as an SD-WAN, where the computing device 300 facilitates connectivity between a branch gateway such as the branch gateway 112 and a remote endpoint device such as the VPNC 154 with respect to the Internet or other data network. It will be appreciated that the computing device 300 can be associated with a particular Internet Service Provider (ISP).

[0043] The computing device 300 may include one or more computing components embodied by a hardware processor 302, such as one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in a machine-readable storage medium 304. As described in more detail below, the hardware processor 302 may retrieve, decode, and execute instructions such as those embodied in the machine-readable storage medium 304. Figure 3BAs an alternative or in addition to retrieving and executing instructions, the hardware processor 302 may include one or more electronic circuits including functional electronic components for executing one or more instructions, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other electronic circuits.

[0044] A machine-readable storage medium, such as machine-readable storage medium 304, can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, machine-readable storage medium 304 can be, for example, random access memory (RAM), non-volatile RAM (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 can be a non-transitory storage medium, where the term "non-transitory" does not include transient propagating signals. As described in detail below, machine-readable storage medium 304 can be encoded with executable instructions.

[0045] In some embodiments, computing device 300 may include a firewall creation component 306. Figure 3B As shown, at operation 306a, after IKE negotiation between a first network device and a second network device (such as an endpoint device), a firewall session can be established. As described above, IKE negotiation or exchange may involve a series of requests and responses for SA initiation to establish the necessary security associations, authenticate the first endpoint device and the second endpoint device, and exchange relevant information (such as certain notifications, configuration data, etc.). That is, the endpoint devices (or IPSec peers) use IKE for authentication and can negotiate IKE SAs. IKE can negotiate IPSec SA parameters and establish matching IPSec SAs in the endpoint devices. A firewall session can be established to determine whether a packet should be processed and forwarded / transmitted or dropped (due to a protocol violation, information mismatch, etc.).

[0046] As described above, when the IPSec pass-through feature is enabled in a network device such as network device 300, cloud-managed IKE / IPSec keys are distributed directly to the endpoint device, rather than creating keys based on IKE negotiation. However, without IKE negotiation, network device 300 will discard / drop any IPSec / IKE overlay packets intended to establish an overlay tunnel. Therefore, with respect to the above, the firewall session can operate to allow overlay packets to pass through network device 300. That is, according to operation 308a, IPSec data packets (or ESP packets) are allowed to pass from the first network (endpoint) device to the second network (endpoint) device. A first (IKE / IPSec) tunnel can then be established. In operation 310a, establishment of this first tunnel allows the first network (endpoint) device and the second network (endpoint) device to perform a handshake operation utilizing IPSec data packets to establish a second tunnel comprising a cloud-managed overlay tunnel. Therefore, IPSec data packets are not discarded by network device 300, but can instead pass through network device 300 based on the cloud-managed IPSec / IKE keys received from the SD-WAN orchestrator to facilitate establishment of the overlay tunnel. Once the second / overlay tunnel has been established, the first tunnel can be shut down smoothly.

[0047] Figure 4 A block diagram of an example computer system 400 is depicted in which various embodiments described herein may be implemented. Computer system 400 includes a bus 402 or other communication mechanism for communicating information, and one or more hardware processors 404 coupled to bus 402 for processing information. Hardware processor(s) 404 may be, for example, one or more general-purpose microprocessors.

[0048] Computer system 400 also includes a main memory 406, such as a random access memory (RAM), a cache, and / or other dynamic storage device, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 404. Such instructions, when stored in a storage medium accessible to processor 404, present computer system 400 as a special-purpose machine customized to perform the operations specified in the instructions.

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

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

[0051] The computing system 400 may include a user interface module that implements a GUI, which may be stored in a mass storage device as executable software code executed by the computing device(s). By way of example, this module and other modules may include components, such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0052] Generally, as used herein, the terms "component," "engine," "system," "database," "data repository," and the like may refer to logic embodied in hardware or firmware, or to a collection of software instructions, which may have entry and exit points, written in a programming language such as, for example, Java, C, or C++. Software components may be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It should be understood that software components may be called from other components or themselves, and / or may be called in response to detected events or interrupts. Software components configured for execution on a computing device may be provided on a computer-readable medium, such as a compact disc, digital video disc, flash drive, magnetic disk, or any other tangible medium, or as a digital download (and may be originally stored in a compressed or installable format that requires installation, decompression, or decryption prior to execution). Such software code may be stored in part or in whole on a memory device of the executing computing device for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. It will also be understood that hardware components may include connected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.

[0053] Computer system 400 can implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which in combination with the computer system makes computer system 400 a special-purpose machine or programs computer system 400. According to one embodiment, the techniques 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 sequences of instructions contained in main memory 406 causes processor(s) 404 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

[0054] As used herein, the term "non-transient media" and similar terms refer to any medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such non-transient media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 410. Volatile media include dynamic memory, such as main memory 406. Common forms of non-transient media include, for example, floppy disks, diskettes, hard disks, solid-state drives, magnetic tape or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge memory, and networked versions of the same.

[0055] Non-transient media are distinct from, but may be used in conjunction with, transmission media. Transmission media facilitate the transfer of information between non-transient media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 402. Transmission media may also take the form of acoustic or light waves, such as those generated during radio and infrared data communications.

[0056] Computer system 400 also includes a communication interface 418 coupled to bus 402. Network interface 418 provides a bidirectional data communication coupling to one or more network links connected to one or more local networks. For example, communication interface 418 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection with a corresponding type of telephone line. As another example, network interface 418 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or a WAN component that communicates with a WAN). Wireless links can also be implemented. In any such implementation, network interface 418 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0057] A network link typically provides data communication through one or more networks to other data devices. For example, a network link can provide a connection to a host computer or data equipment operated by an Internet Service Provider (ISP) through a local network. The ISP, in turn, provides data communication services through the global packet data communication network now commonly referred to as the "Internet." Both the local network and the Internet use electrical, electromagnetic, or optical signals to carry digital data streams. The signals through the various networks, as well as the signals on the network link and the signals through the communication interface 418, that carry digital data to and from the computer system 400, are example forms of transmission media.

[0058] Computer system 400 can send messages and receive data, including program code, through network(s), network links, and communication interface 418. In the Internet example, a server may transmit the requested code for an application program through the Internet, an ISP, a local network, and communication interface 418.

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

[0060] Each of the processes, methods, and algorithms described in the preceding sections can be embodied in a code component executed by one or more computer systems or computer processors comprising computer hardware, and fully or partially automated by the code component. One or more computer systems or computer processors can also operate to support the execution of related operations in a "cloud computing" environment or as "software as a service" (SaaS). The processes and algorithms can be implemented in part or in whole in dedicated circuits. The various features and processes described above can be used independently of each other, or can be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process blocks can be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the blocks or states associated therewith can be executed in other appropriate orders, or can be executed in parallel, or in some other manner. Blocks or states can be added to or removed from the disclosed example embodiments. The performance of certain operations or processes can be distributed among computer systems or computer processors, not just within a single machine, but deployed across multiple machines.

[0061] As used herein, any form of hardware, software or their combination can be utilized to realize circuit.For example, one or more processors, controllers, ASIC, PLA, PAL, CPLD, FPGA, logic components, software routines or other mechanisms can be realized to form circuit.In implementation, the various circuits described herein can be implemented as discrete circuits, or the functions and features described can be partially or entirely shared between one or more circuits.Even if the various features or elements of functionality can be described or declared as independent circuits separately, these features and functionality can also be shared between one or more common circuits, and this description should not require or imply that independent circuits are needed to realize these features or functionality.When using software to realize circuit in whole or in part, this software can be realized to operate together with a computing system or a processing system (such as computer system 400) that can perform the functionality described about it.

[0062] As used herein, the term "or" may be interpreted as inclusive or exclusive. Furthermore, descriptions of resources, operations, or structures in the singular should not be interpreted as excluding the plural. Unless expressly stated otherwise, or otherwise understood in the context of use, conditional language such as "can," "could," "might," or "may" is generally intended to convey that some embodiments include, while other embodiments do not include, certain features, elements, and / or steps.

[0063] Unless expressly stated otherwise, the terms and phrases used in this document, and variations thereof, should be interpreted as open ended and non-restrictive. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be interpreted as limiting the items described to a given time period or items available at a given time, but should be understood to include conventional, traditional, normal, or standard technology that may be available or known at any time now or in the future. In some cases, the presence of phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be understood as intending or requiring the use of a narrower context where such expanded phrases may not be present.

[0064] It should be understood that, as used herein, the terms "optimize," "optimal," and the like may be used to refer to achieving or obtaining a performance that is as efficient or perfect as possible. However, those of ordinary skill in the art who read this document will recognize that perfection is not always achievable. Thus, these terms may also encompass achieving or obtaining the best possible, efficient, or practical performance under given circumstances, or achieving or obtaining a performance that is better than that achievable using other settings or parameters.

Claims

1. A method comprising: detecting, at a first network device between the second network device and the third network device, an Internet Key Exchange (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 network device and the third network device based on detecting the IKE key negotiation between the second network device and the third network device, wherein a first Internet Protocol Security (IPSec) tunnel between the second network device and the third network device is established using the IKE key negotiation, the first IPSec tunnel conforming to the firewall session and allowing IPSec data packets to pass through the first network device between the second network device and the third network device; based on the establishment of the first IPSec tunnel, transmitting the IPSec data packets exchanged between the second network device and the third network device through the first network device using a cloud-managed IPSec key from a cloud-based orchestrator, wherein the IPSec data packets are exchanged as part of a handshake operation that results in establishment of a second tunnel between the second network device and the third network device based on the cloud-managed IPSec key, wherein the second tunnel is an overlay tunnel on an underlay network; as well as After the establishment of the second tunnel and the cloud-managed IPSec key is active, the negotiated IKE key is discarded and the first IPSec tunnel is smoothly closed without interfering with the encrypted communication between the second network device and the third network device.

2. The method of claim 1, wherein the second network device comprises a branch gateway operating in a software-defined wide area network (SD-WAN).

3. The method of claim 2, wherein the cloud-based orchestrator is an SD-WAN orchestrator.

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). The method of claim 1 , comprising enabling an IPSec pass-through feature at the first network device.

6. A first network device, comprising: Hardware processor; as well as a non-transitory storage medium storing instructions executable on the hardware processor to: performing an Internet Key Exchange (IKE) key negotiation with a second network device, including exchanging messages passing through a third network device between the first network device and the second network device, wherein the third network device has an Internet Protocol security (IPSec) pass-through feature enabled; establishing a first IPSec tunnel between the first network device and the second network device using a key from the IKE key negotiation, the first IPSec tunnel being transmitted through the third network device; receiving, at the first network device, a cloud-managed IPSec key from a cloud-based orchestrator; performing a handshake operation between the first network device and the second network device, wherein IPSec data packets are transmitted through the third network device in the first IPSec tunnel, the IPSec data packets being used to establish a second tunnel based on cloud-managed IPSec keys; The second tunnel is an overlay tunnel on the underlying network; as well as After the establishment of the second tunnel and the cloud-managed IPSec key is active, the negotiated IKE key is discarded and the first IPSec tunnel is smoothly closed without interfering with encrypted communications between the first network device and the second network device. The first network device of claim 6 , wherein the first network device comprises a branch gateway.

8. The first network device of claim 6, wherein the IPSec data packets are allowed to pass through the third network device according to the IPSec pass-through feature 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 the closing of the first IPSec tunnel comprises: A link between the first network device and the second network device is disabled.

11. The first network device of claim 6, wherein the closing of the first IPSec tunnel comprises: The negotiated IKE key from the key negotiation is discarded.

12. A non-transitory machine-readable storage medium comprising instructions that, when executed, cause a first network device to: performing, at the first network device, an Internet Key Exchange (IKE) key negotiation with a second network device, including exchanging messages passing through a third network device between the first network device and the second network device, wherein the third network device has an Internet Protocol Security (IPSec) pass-through feature enabled; establishing a first IPSec tunnel between the first network device and the second network device using a key from the IKE key negotiation, the first IPSec tunnel being transmitted through the third network device; receiving, at the first network device, a cloud-managed IPSec key from a cloud-based orchestrator; performing a handshake operation between the first network device and the second network device, wherein IPSec data packets are transmitted through the third network device in the first IPSec tunnel, the IPSec data packets being used to establish a second tunnel; establishing a second tunnel between the first network device and the second network device based on the cloud-managed IPSec key, wherein the second tunnel is an overlay tunnel on an underlay network; as well as After the establishment of the second tunnel and the cloud-managed IPSec key is active, the negotiated IKE key is discarded and the first IPSec tunnel is smoothly closed without interfering with the encrypted communication between the second network device and the third network device.

13. The non-transitory machine-readable storage medium of claim 12, wherein the closing of the first IPSec tunnel comprises: disabling the link between the first network device and the second network device, or The IPSec key from the key negotiation is discarded.

14. The non-transitory machine-readable storage medium of claim 12, wherein the first network device comprises a branch gateway or a virtual private network concentrator.

Images