Patent ID: 12231400

DESCRIPTION

The description that follows includes example systems, methods, techniques, and program flows that embody aspects of the disclosure. However, it is understood that this disclosure may be practiced without these specific details. For instance, this disclosure refers to performing firewall switchover events by entering a pseudo-active/active firewall configuration for firewalls in a cloud in illustrative examples. Aspects of this disclosure can be instead applied to various passive, active, and pseudo-active state configurations for firewalls or other computing components in operational contexts such as on-premises, across a wide area network, in an Internet of things, etc. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.

Overview

During switchover events in cloud firewall systems, stateful network sessions can experience disconnection due to previously-passive, now-active firewalls having no knowledge of current session states for network sessions that are redirected during the switchover event. Session state syncing requires control plane (CP) data (i.e., the session states) to be synced between pairs of firewalls in a high availability configuration. For transport layer protocols, the latency in communications along CP links would result in slowing down network throughput for these transport layer protocol sessions. The present disclosure proposes a “pseudo-active” state for a currently active firewall (firewall A) during a switchover event that allows firewall A to pair with a passive firewall (firewall B) in the high availability configuration. Using high availability data plane (DP) links, firewalls A and B sync session states to minimize session disconnection and dropped traffic during the switchover event. Once the IP address binding update begins, the CP of firewall A instructs the DP of firewall A to enter a forwarding state wherein it forwards ingress network sessions to the DP of firewall B. The DP of firewall A modifies packet headers in the ingress network sessions to include session state information so that firewall B can track session states. The CP of firewall B instructs the DP of firewall B to record session state information for packets received from firewall A along with other capture logs and discards packet contents. Prior to the IP address binding update, ingress and egress traffic is processed normally at firewall A with the addition of the forwarded ingress traffic to firewall B. Subsequent to initiating the IP address binding update and prior to expiration of the pseudo-active timer, a forwarding rule for firewalls in the cloud is updated according to a configuration for forwarding across a network of firewalls in the cloud to include firewall B and remove firewall A. Once the IP address binding update occurs and firewall B receives ingress and egress network sessions normally, firewall B is configured to track session states according to state information previously communicated via forwarded packets from firewall A. Firewall A is then deactivated when the pseudo-active timer expires and Firewall B handles stateful sessions that were previously established with firewall A without dropping traffic or disconnecting sessions.

Terminology

An “active” state for a firewall refers to a configuration for the firewall that allows handling of ingress and egress network traffic. While in its active state, a firewall is capable of handling traffic according to internal protocols for the firewall and/or a corresponding network including packet analysis, route advertisement, etc.

A “passive” state for a firewall refers to a configuration for the firewall wherein the firewall cannot handle ingress and egress network traffic. Firewalls in passive states can be completely deactivated preventing future deployment or can be in a suspended state awaiting reactivation. For instance, a firewall running on a computing device can be set to passive by powering down the computing device or setting the device to a sleep mode. Alternatively, a firewall can be set to a passive state by querying a CSP to remove the firewall from deployment.

A “pseudo-active” state for a firewall refers to a configuration prior to entering a passive state wherein the firewall is still able to handle ingress and egress traffic according to its active state and is on a pseudo-active timer that designates when the firewall will be deactivated. Firewalls in the pseudo-active state can be configured to perform operations in addition to normal operations performed in the active state such as data plane forwarding of network traffic.

Example Illustrations

FIGS.1and2are schematic diagrams illustrating pseudo-active/active configurations for cloud-based firewalls in a high availability (HA) deployment. High availability deployments of firewall disclosed herein have DP and CP links that sync sessions, security configurations, forwarding tables, Address Resolution Protocol (ARP) tables, etc. A load-balancer or other orchestration component detects switchover and failover events and instructs firewalls to enter active, passive, and pseudo-active states according to switchover and failover events to preserve network traffic flow at high availability. Firewalls can have internal timers that automatically detect switchover and/or failover events such as monitor fail timers, preemption hold timers, heartbeat timers, promotion timers, hello timers, etc. To exemplify, firewalls can be paired in a high availability configuration, and two paired firewalls can send heartbeat messages to each other that verify functionality in the form of Internet Control Message Protocol (ICMP) pings and if the time since the last ping exceeds the heartbeat timer, then a failover event is detected. While described in reference to a firewall switchover event, any of the embodiments disclosed herein can alternatively be applied to failover events detected at a firewall or by a firewall orchestrator.

FIGS.1and2are annotated with a series of letters A-F. These letters represent stages of operations. Although these stages are ordered for this example, the stages illustrate one example to aid in understanding this disclosure and should not be used to limit the claims. Subject matter falling within the scope of the claims can vary with respect to the order and some of the operations.

FIG.1is a schematic diagram of an example system performing a firewall switchover event using a pseudo-active/active firewall configuration. Pseudo-active/active firewall configuration refers to a configuration of firewall A100and firewall B102with firewall A100in a pseudo-active state and firewall B102in an active state. The firewall switchover event is an event triggered by a request to initiate a passive state for firewall A100wherein it does not receive ingress or egress network traffic. For instance, the firewall switchover event can be that firewall A100is due for software updates, that firewall A100is overloaded in a cloud150or other load-balancing complications, that firewall A100is deprecated, etc. To perform the firewall switchover event, ingress and egress network traffic from the Internet160should be correctly routed at a cloud provider gateway104according to its current network address translation (NAT) table107A. Accordingly, an orchestrator170managing firewall A100and firewall B102in the cloud150queries the cloud provider gateway104to update an IP address binding106A in the current NAT table107A by which traffic is routed to firewall A100to instead route to firewall B102. During the transitional period while the IP address binding is updated by a CSP, firewall A100and firewall B102enter the pseudo-active/active configuration during which firewall A100continues to receive egress and ingress network traffic until a transitional IP address binding106B (i.e., the current binding during the transition from the IP binding update that could map to either of firewalls100and102depending on whether the update has occurred) and NAT table107B are successfully updated.

Firewall A100and firewall B102are running on cloud instances110and112, respectively, in a high availability configuration. Cloud instances110and112can be any cloud instances hosted natively or by a cloud provider. For instance, cloud instances110and112can be Amazon EC2 ® instances, Google Cloud Provider® virtual machines, etc. The high availability configuration comprises a CP link and a DP link. The CP HA link can exchange heartbeats, hello messages, state information, routing synchronization data, user ids, etc. The DP HA link can synchronize sessions, forwarding tables, Internet Protocol Security (IPsec) security associations, Address Resolution Protocol (ARP) tables, etc. The firewalls100and102are configured to handle both switchover and failover events, and in some embodiments can automatically detect these events and perform corrective action (e.g., entering pseudo-active/active states) accordingly.

Throughout the operations at stages A-D, the orchestrator170communicates instructions for traffic redirection during the pseudo-active/active configuration. These instructions can be communicated to a CSP via an application programming interface (API) that manages firewalls in the cloud150. In other embodiments, the orchestrator170communicates with a natively hosted service managing the cloud150that manages firewall states and traffic routing. Firewalls in the cloud150can be configured to directly receive instructions from the orchestrator170and, alternatively, can have native instructions for initiating active, pseudo-active, and passive states. While the cloud provider gateway104is depicted as a routing service provided by a CSP managing firewalls in the cloud150, it can be any wide area network (WAN) router or software-defined wide area network (SD-WAN) router configured to direct traffic between firewalls in the cloud150and the Internet160.

Various operations inFIGS.1and2for interacting with a CSP and entering various active/passive, pseudo-active/active, and passive/active configurations for firewalls are performed by the orchestrator170. Any of the various operations can be performed by code executed at the firewalls100and102and/or other components not depicted inFIGS.1and2. In some embodiments, firewall A100communicates instructions to firewall B102to perform the sequence of depicted operations. Operations within the pseudo-active/active configuration can vary, andFIGS.1and2are two example embodiments of traffic handling with minimized traffic disruption during this configuration.

At stage A, during an initial active/passive configuration, firewall A100is initially in an active state wherein it receives ingress network traffic103A and sends egress network traffic101A. Ingress and egress traffic are processed through a cloud provider gateway104that acts as a middle-man between the cloud150and the Internet160. In some embodiments, the cloud provider gateway104processes ingress and egress network traffic across protocols for traffic in the cloud150and traffic to the Internet160and modifies packet headers accordingly. While depicted as a gateway for a cloud provider, the cloud provider gateway104can be any Internet gateway configured as an interface between traffic at the firewalls100,102and traffic to and from the Internet160.

Firewall B102is initially in a passive state wherein it does not receive or send network traffic. The cloud provider gateway104has a NAT table107A including the firewall A IP address binding106A that maps a public IP address 192.0.2.0 to private IP address 10.0.0.0 corresponding to firewall A100. During flow of network traffic, upon receiving ingress network traffic103A, the cloud provider gateway104updates the public IP address from packets having a destination IP address field 192.0.2.0 to have a destination IP address field 10.0.0.0 and maps the public destination port corresponding to firewall A100to the private port for firewall A100. For egress network traffic101A received from the firewall A100, the cloud provider gateway104updates the source IP address for packets from the private IP address 10.0.0.0 to the public IP address 192.0.2.0 and also updates the private source port for firewall A100to the public source port corresponding to firewall A100. The cloud provider gateway104can store private/public port pairs in the NAT table107A in addition to private/public IP address pairs (e.g., when multiple firewalls are routed through the same public IP address according to their public/private ports) or, in other embodiments, can route traffic according to the public to private IP address entry.

At some point during network traffic flow for the active/passive configuration of firewall A100and firewall B102, respectively, firewall A100is designated for a firewall switchover event. The firewall switchover event can be triggered by firewall A100or the orchestrator170. For instance, firewall A100or the orchestrator170can detect a traffic load at firewall A100above a threshold, the orchestrator170can detect an out-of-date software version running on firewall A100, an external entity can determine that firewall A100should be deactivated/suspended (e.g., a user monitoring the cloud150), etc. The orchestrator170initiates the firewall switchover event and starts a pseudo-active timer. Subsequently, firewall A100switches from an active to a pseudo-active state, and firewall B102switches from a passive to an active state. The pseudo-active timer is a timer that exceeds an expected time interval for the firewall A IP address binding106A to update and can include a buffer time interval to ensure that the pseudo-active timer doesn't expire prior to the firewall A IP address binding106A successfully updating. For instance, if the average time for previously-seen IP address binding updates at the cloud provider gateway104is 30 seconds and the maximal previously-seen IP address binding update is 1 minute, then the pseudo-active timer can be chosen as 2 minutes with a buffer time interval of 1 minute. The pseudo-active timer can account for latency in communications between the orchestrator170and the cloud150during operations at stages B and C.

At stage B, the orchestrator170instructs firewall A100to enter a pseudo-active state and firewall B102to enter an active state. The orchestrator170queries firewall B102or, in some embodiments, a CSP managing the cloud150for firewall B102to enter an active state. In some embodiments, a passive state means that a firewall ceases receiving and sending all network traffic. In other embodiments, a passive state is specific to the public IP address, depicted as 192.0.2.0 inFIG.1, and passive firewalls can be active for other IP addresses. Traffic is handled normally at firewall A100during its pseudo-active state. In some embodiments, one of firewalls100and102detect the switchover event and the firewalls100,102automatically enter the pseudo-active/active configuration by communicating instructions via a CP link. In other embodiments, certain types of network traffic according to certain Internet protocols (e.g., Transmission Control Protocol (TCP) sessions, Transport Layer Security (TLS) sessions) are handled granularly in the data plane at firewall A100, and the orchestrator170sends instructions to firewall A100to enter the pseudo-active state accordingly. This granular handling of network traffic is described in greater detail in an embodiment depicted inFIG.2.

At stage C, the orchestrator170instructs the cloud provider gateway104to update the firewall A IP address binding106A to a binding that indicates the private IP address of firewall B102. Because this operation is not performed instantly at the cloud provider gateway104, during the pseudo-active/active configuration, there is a transitional IP address binding106B for a NAT table107B. The transitional IP address binding106B can route to either firewall A100or firewall B102, and accordingly, the NAT table107B comprises an entry from the public IP address 192.0.2.0 to either private IP address 10.0.0.0 corresponding to firewall A100or private IP address 10.0.0.1 corresponding to firewall B102depending on whether the transitional IP address binding106B has updated. Ingress network traffic103B is processed at the cloud provider gateway104and mapped to private IP address 10.0.0.0 or 10.0.0.1 according to the current transitional IP address binding106B, as indicated by the dashed line between the transitional IP address binding106B and the circle connecting traffic flow to and from both firewalls depicted inFIG.1. Egress network traffic101B from firewall A100and egress network traffic101C from firewall B102have the source IP address mapped to 192.0.2.0 at the cloud provider gateway104. The cloud provider gateway104, when updating the transitional IP address binding106B, can maintain the same public port number (i.e., the port number for network traffic that has been translated to the public IP address) for firewall A100prior to updating and firewall B102subsequent to updating. Thus, ingress network traffic103B directed at this port with public IP address 192.0.2.0 will be correctly routed to firewall A100prior to updating the binding and firewall B102subsequent to updating the binding.

At stage D, on expiration of the pseudo-active timer, the orchestrator170instructs firewall A100to enter a passive state, initiating a passive/active configuration. Because the cloud provider gateway104maintained the same public port number for both firewall A100and firewall B102in the NAT table107B, ingress network traffic will be routed to firewall B102and there is no dropped traffic routed to firewall A100during its passive state. In embodiments where the firewall switchover event is temporary (e.g., firewall A100is temporarily load balanced, software on firewall A100is upgraded, etc.), the operations inFIG.1can be performed with firewall A100and firewall B102switched, i.e., the firewalls enter an active/pseudo-active configuration and then an active/passive configuration.

FIG.2is a schematic diagram of an example system for directing flow of traffic corresponding to network sessions for a pseudo-active/active configuration of firewalls. Rerouting traffic corresponding to network sessions from firewall A100to firewall B102(running on cloud instances110,112respectively) can result in dropping network sessions requiring session reconnection. To exemplify, TCP sessions have a state (e.g., ESTAB, FINWAIT-1, FINWAIT-2, CLOSING, TIMEWAIT, CLOSED, etc.) that transitions via control bits contained in TCP headers (e.g., ACK, FIN, SYN, etc.). With no prior knowledge of current states of TCP sessions at firewall A100, after the transitional IP address binding106B is updated and traffic from these TCP sessions routes to firewall B102, firewall B102will have no notion of how to handle the TCP traffic and will let each TCP session timeout and enter a CLOSE state. Thus, the orchestrator170instructs firewall A100and firewall B102to sync session states for pre-update ingress network sessions205, and for firewall A100to enter a forwarding state in its data plane (DP). In this forwarding state, firewall A100forwards network traffic to firewall B102in the data plane, and firewall B102records session data from the traffic before discarding. This allows firewall B102to appropriately handle traffic from sessions originally established with firewall A100after the transitional IP address binding106B updates.

At stage A, a CP for firewall A100(operating in a pseudo-active state) forwards forwarding state instructions211to a DP for firewall A100. The CP and DP as used herein are abstractions of routing components for traffic processing and routing at firewalls in the cloud150. The CP refers to the component(s) that performs operations involving routing of traffic across firewalls, for instance updating routing tables, advertising routes, load balancing firewalls, and other operations that affect network topology of a network of firewalls in the cloud150including the firewall A100and the firewall B102. The DP refers to the component(s) that performs operations involving packet handling, e.g., parsing of packet headers and processing of packets according to corresponding protocols, and the DP is managed via instructions from the CP. These abstractions are used for illustrative purposes and various components of the firewalls100102can perform the described operations across both the CP and DP and, in some embodiments, operations can be performed by a WAN controller operating on the cloud150.

The forwarding state instructions211comprise instructions to forward copies of packets for pre-update ingress network sessions205to the DP of firewall B102, to communicate pre-update session state data209for existing sessions at firewall A100to firewall B102, and to continue to process established sessions in the pre-update ingress network sessions205and egress network sessions203A at firewall A100. The forwarding state instructions211can additionally comprise instructions to forward unseen/not previously established (“new”) sessions (e.g., based on an establishment message for a corresponding session protocol) in the pre-update ingress network sessions205to firewall B102so that firewall B102may establish and handle those new sessions while the transitional IP address binding106B updates. In these embodiments, firewall A100discards traffic in the new sessions of the pre-update ingress network sessions205after communicating this traffic to firewall B102. The DP at firewall A100then communicates pre-update session state data209to the DP at firewall B102. The CP at firewall B102receives the pre-update session state data209from the DP and updates session state data for the firewall B102to include states for those sessions currently active at firewall A100. In some embodiments, when traffic is forwarded from the DP of firewall A100to the DP of firewall B102, the forwarding state instructions211include adding session state data into packet headers of the forwarded traffic. The session state data can be added into packet headers according to a corresponding session protocol, and firewall B102can be configured to receive packets for certain protocols that have the additional state information in the packet headers.

Prior to or simultaneous with the communication of forwarding state instructions211, firewall A100begins a pseudo-active timer that corresponds to the length of time that firewall A100operates in a pseudo-active state. Firewall A100additionally communicates an indication of starting the pseudo-active timer to firewall B102. Firewall A100and firewall B102can be configured to appropriately handle the pseudo-active/active configuration, for instance by having hard-coded values for the pseudo-active timer and various protocols according to types of network sessions to be handled, types of firewall switchover events, etc. In contrast toFIG.1, the pseudo-active timers inFIG.2are synced, so that firewall A100and firewall B102both track the pseudo-active timer. Thus, firewall B102can migrate its public IP address in the cloud150prior to or simultaneous with expiration of the pseudo-active timer as depicted at stage F. In some embodiments, the orchestrator107tracks the pseudo-active timer and communicates with the firewall A100, the firewall B102, and the cloud provider gateway104. In these embodiments, firewall A100may not communicate the pseudo-active timer to firewall B102.

At stage B, the CP for firewall B102communicates packet handling instructions215to the DP at firewall B102. The packet handling instructions215comprise instructions to, upon receipt of packets in the pre-update ingress network sessions207for established sessions at firewall A100, record session information for the packets and then discard them. The packet handling instructions215can comprise instructions to record further data from the packets besides session information such as header fields, capture logs, etc. Additionally, for these established sessions at firewall A100the orchestrator170instructs the cloud provider gateway104to not advertise the route from the cloud provider gateway104to the firewall B102via firewall A100created by the forwarding state initialized at stage A. This is in accordance with split horizon route advertisement and avoids the count to infinity problem where the link in the DP between firewall A100and firewall B102goes down. In the count to infinity problem, for packets routed from the cloud provider gateway104to the firewall B102via firewall A100, firewall B102determines that the direct route from firewall A100to firewall B102is down and detects the route from the cloud provider gateway104to firewall B102in its routing table, resulting in firewall B102sending the packet back to the cloud provide gateway104. The packet would then alternate between the cloud provider gateway104and firewall B102endlessly. The packet handling instructions215can additionally comprise instructions to establish and handle traffic of new sessions in the pre-update ingress network sessions207not previously established by firewall A100. In other embodiments, these new sessions are handled by firewall A100while the session states are forwarded to firewall B100in the pre-update network sessions207until the transitional IP address binding106B is updated.

At stage C, the orchestrator170instructs the cloud provider gateway104to update the transitional IP address binding106B to, for packets with destination IP address 192.0.2.0, route these packets to private IP address 10.0.0.1 for firewall B102instead of private address 10.0.0.0 for firewall A100. Accordingly, the entry in NAT table107B is updated with this private to public IP address entry. The processing time for the binding update depends on the CSP managing the cloud provider gateway104or, in other embodiments, the native system managing the cloud provider gateway104(for instance, the orchestrator170), and can take 30 seconds. The pseudo-active timer is chosen to give a buffer between completion of updating the transitional IP address binding106B and transitioning firewall A100from a pseudo-active to a passive mode. For instance, the pseudo-active timer can be chosen at 2 minutes to give a 1.5 minute buffer from the expected binding update durations.

At stage D, ingress network sessions201are mapped from public IP address 192.0.2.0 to private IP address 10.0.0.0 corresponding to firewall A100. The ingress network sessions201are then routed by a router component of the cloud provider gateway104to firewall A100as pre-update ingress network sessions205. During this phase after the pseudo-active timer starts and before the transitional IP address binding106B is updated, firewall A100continues to process pre-update ingress network sessions205and egress network sessions203A according to its active state protocols. Additionally, firewall A100copies packets received at the DP in the pre-update ingress network sessions205and forwards the copies as pre-update ingress network sessions207to firewall B102. Firewall B102, based on the packet handling instructions215communicated to its DP, records session information for established sessions at firewall A100in the pre-update ingress network sessions207, tracks session states, and may record additional information such as capture logs before discarding these packets without processing or sending response messages. Additionally, in some embodiments, firewall B establishes and handles traffic for new sessions received at firewall A100in the pre-update ingress network sessions207. In other embodiments, these new sessions in the pre-update ingress network sessions205are established and handled by firewall A100and firewall B102records session information for the new sessions upon receiving them in the pre-update ingress network sessions207and discards the corresponding traffic.

At stage E, after the transitional IP address binding106B is updated, the cloud provider gateway104maps ingress network sessions201with destination IP address 192.0.2.0 to private IP address 10.0.0.1 corresponding to firewall B102. Accordingly, the ingress network sessions201are routed to firewall B102as post-update ingress network sessions213. Firewall B102, in an active state, processes post-update ingress network sessions213and egress network sessions203B according to its active configuration.

At stage F, firewall B102or, in some embodiments, the orchestrator107instructs the cloud provider gateway104to update a forwarding rule to include firewall B102and remove firewall A from available ports for load-balancing in the cloud150. For instance, the orchestrator107can instruct the cloud provider gateway104through its API to add a port that maps to private IP address 10.0.0.1 in the NAT table107B to its list of available ports for load balancing and to remove a port that maps to private IP address 10.0.0.0 in the NAT table from the list. Forwarding rules can be formatted according to a configuration of a cloud provider and/or native host of the cloud150. This operation occurs at a time so that expiration of the pseudo-active timer and updating of the public IP address for firewall B102are synced as closely as possible. For instance, this can occur at a time of (pseudo-active timer—expected public IP address update time) subsequent to starting the pseudo-active timer. The operation at stage F is not depicted inFIG.1for brevity and can additionally be performed after the operations at stage C inFIG.1and prior to the operations at stage D inFIG.1.

The example operations inFIGS.3-5are described with reference to firewalls, a cloud provider gateway, and an orchestrator for consistency with the earlier figures. As mentioned in the foregoing, operations can be alternatively performed by various components. The name chosen for the program code is not to be limiting on the claims. Structure and organization of a program can vary due to platform, programmer/architect preferences, programming language, etc. In addition, names of code units (programs, modules, methods, functions, etc.) can vary for the same reasons and can be arbitrary.

FIG.3is a flowchart of example operations for performing a firewall switchover event with a pseudo-active/active firewall configuration. At block300, an orchestrator detects a firewall switchover event for a currently active firewall A. For instance, the orchestrator can determine that a software and/or hardware upgrade is required for firewall A, that firewall A is deprecated, that a load for firewall A exceeds a threshold and that traffic at firewall A to and from a public IP address will lessen the traffic load at firewall A to below the threshold, that firewall A needs a (metaphorical) vacation, etc.

At block301, an orchestrator initiates an active state for a currently passive firewall (firewall B) running in a cloud. The orchestrator can query a CSP API to initiate an active state for firewall B or, in embodiments where the orchestrator is managing a natively hosted cloud, the orchestrator can directly initiate the active state for firewall B (e.g., via a native API for the cloud). In some embodiments, the orchestrator can determine that a new firewall should be initialized, and firewall B is initialized and then subsequently initiated into an active state. The determination that a new firewall should be initialized can be based on a number of currently active/passive firewalls, network topology for the cloud, load balancing, etc. In its active state, firewall B is configured to handle ingress and egress network traffic. For instance, firewall B is configured to capture logs for packets in ingress and egress network traffic and generate features from the capture logs such as malware verdicts. Malicious malware verdicts can trigger security events such as blocking and/or remediating devices, IP addresses, etc. at the cloud.

At block303, the orchestrator queries a CSP that offers the cloud to update a public to private IP address binding from firewall A to firewall B. The binding update occurs at a cloud provider gateway or other routing component that routes traffic from firewalls in the cloud to the Internet, and a NAT table is updated at the cloud provider gateway. A NAT table at the cloud provider gateway is updated to replace an entry that maps a public IP address for firewall A to a private IP address for firewall A to an entry that maps the public IP address to a private IP address for firewall B. In some embodiments, the orchestrator and/or the firewalls themselves update the binding via a router (e.g., a WAN controller) managing traffic to the firewalls in the cloud. The update operation can take time interval (e.g., 30 seconds) during which immediately shutting down firewall A would result in traffic disruption.

At block305, the orchestrator initiates a pseudo-active state for firewall A and starts a pseudo-active timer. The pseudo-active timer is tuned so that the timer is longer than a period of time during which the binding updates. For instance, when the binding update takes 30 seconds, then the pseudo-active timer can be 2 minutes to give a buffer of 1.5 minutes. Once the pseudo-active timer starts, firewall A enters a pseudo-active state. In the pseudo-active state, firewall A continues to process ingress and egress traffic as in its active state to prevent traffic disruption during the firewall switchover event.

At block307, firewalls A and B receive traffic during activity of the pseudo-active timer. Traffic gets routed according to the current binding at the cloud provider gateway or other router, which is to the private IP address for firewall A prior to the binding update and to the private IP address for firewall B after the binding update. With firewall A in the pseudo-active state and firewall B in the active state, both are able to handle traffic according to normal handling protocols at the firewalls. Block307is depicted with a dotted outline inFIG.3to express that firewalls A and B both can process traffic during the pseudo-active timer.

At block309, the orchestrator determines whether the pseudo-active timer has expired. In some embodiments, the firewall A can track the pseudo-active timer and can determine whether the timer has expired. Firewall B may not track the pseudo-active timer because the operations subsequent to timer expiration involve firewall A, and firewall B continues in its active state. If the pseudo-active timer is expired, operations continue to block311. Otherwise, operations continue to block307for additional traffic handling at firewalls A and B.

At block311, the orchestrator initiates a passive state for firewall A. Alternatively, firewall A can be configured to enter a passive state on its own. The passive state comprises a state where firewall A cannot send or receive network traffic. Depending on the firewall switchover event, the passive state for firewall A can be a suspended state that maintains the firewall instance for later active operations (e.g., for a software update at firewall A) or, in other instances, the firewall instance for firewall A can be deactivated/deleted (e.g., when firewall A is deprecated). For instance, for deactivating/deleting the firewall A, one or more servers hosting the firewall A can be powered down, a CSP can be queried to delete the firewall instance, memory for the firewall A can be reallocated in a native cloud environment, etc.

FIG.4is a flowchart of example operations for maintaining active sessions while firewalls are in a pseudo-active/active firewall configuration. Sessions are stateful; thus, performing the binding update inFIG.3without accounting for how to handle traffic at a pseudo-active firewall (firewall A) and an active firewall (firewall B) would result in session disconnection of active sessions with firewall A when the binding is updated. The example operations ofFIG.4address this issue by intelligently handling traffic to sync states of active sessions at firewall A with firewall B so that, post-binding update, firewall B can handle these network sessions.FIG.4describes various operations between firewalls A and B. These firewalls can be configured to natively execute these operations when a pseudo-active timer is started or, in other embodiments, an orchestrator can track timers and instruct firewalls A and B accordingly.

At block400, an orchestrator starts a pseudo-active timer and a forwarding rule timer and initiates a binding update. The pseudo-active timer indicates how long firewalls in a cloud will maintain a pseudo-active/active configuration during a firewall switchover event and is tuned to exceed an expected period of time to update a binding and to update a public IP address with additional buffer to account for possible lag in both of these events. The forwarding rule timer is tuned so that beginning a public IP address update at the expiration of the forwarding rule timer will result in the public IP address updating at approximately the expiration of the pseudo-active timer. For instance, the forwarding rule timer can be chosen as (pseudo-active timer—expected time to update public IP address). The expected time to update the public IP address may be a value selected based on expert/domain knowledge or experimentation. The binding update is an update for public to private IP address translation between firewalls A and B and an Internet gateway by which ingress and egress traffic is sent between the firewalls and the Internet. The binding update comprises an update to the entry that maps a private IP address for firewall A to a public IP address of the Internet gateway in front of one or more firewalls, where the updated binding maps a private IP address for firewall B to the public IP address. In some embodiments, this binding update is performed at a cloud provider gateway for a CSP hosting the firewalls in a cloud. As depicted inFIG.4, the pseudo-active timer expires at block415, the forwarding rule timer expires at block411, and the binding update occurs sometime during operations at block407. Due to the tuning of the pseudo-active and forwarding rule timers, this binding update occurs prior to blocks411and415.

At block401, a pseudo-active firewall (firewall A) communicates session state data to an active firewall (firewall B). Firewall A was previously active and firewall B was previously passive prior to starting the pseudo-active session timer. Thus, firewall A maintains records of active sessions in ingress and egress network traffic. The session state data comprise session state data for active sessions at firewall A that are stateful, e.g., TCP and TLS sessions.

At block403, the CP for firewall A instructs the DP for firewall A to duplicate and forward ingress network traffic to firewall B. The DP for firewall A forwards packets to firewall B for the purpose of tracking sessions states so that firewall B can properly handle active sessions once firewall A is passive. In some embodiments, the DP for firewall A forwards packet headers and/or state information along with session identifiers (e.g., source IP address/port, destination IP address/port, etc.). Due to low latency of traffic in the data plane, the forwarding state for firewall A can be efficient, e.g., when firewalls A and B are on-premises so that a data plane link is fast. Accordingly, firewalls A and B can be configured with a DP link that ensures a high-fidelity, high-speed communication of forwarded packets, and moreover, this link can be specific to maintaining state information at each firewall (e.g., via a dedicated port).

At block405, the CP of firewall B instructs the DP of firewall B to record session state data for firewall A traffic and to subsequently discard forwarded packets. For instance, for TCP traffic the DP of firewall B can parse the transport layer packet header in packets to determine current sate information based on a previously stored state for each active session at firewall A. For instance, the DP of firewall B can read control bits in TCP headers (e.g., SYN, ACK, etc.) that dictate transitions through the state diagram for TCP that is internally coded at firewall B. Firewall B does not send responses for any forwarded packets to avoid split-horizon route advertisement by a router handling ingress/egress traffic for firewalls A and B.

At block407, firewalls A and B receive traffic for the duration of the pseudo-active timer. Firewalls A and B continue to process traffic according to their active state. Block407is depicted with a dashed outline to indicate that operations for receiving traffic occur until expiration of the pseudo-active timer. Traffic is routed to firewalls A and B according to the current public to private IP address binding. Initially, ingress traffic is routed to firewall A, and as indicated by the box “binding update occurs” inFIG.4, a binding update occurs during activity of the pseudo-active timer and forwarding rule timer. The pseudo-active timer and forwarding rule timer are tuned so that the binding update occurs prior to either of blocks409or413being satisfied.

At block409, firewalls A and B determine whether the forwarding rule timer has expired. This determination can be according to an internal clock at each firewall. In some embodiments, the forwarding rule timer is only tracked at firewall B. If the forwarding rule timer has expired, operations continue to block411. Otherwise, operations continue to block413.

At block411, at least one of firewalls A and B initiates a forwarding rule update for firewall B. For instance, firewall B can communicate to a CSP to update a forwarding rule that enumerates available firewalls (e.g., indexed by port number) over a network to replace firewall A with firewall B. The operations of updating the public IP address are not instantaneous, and the forwarding rule timer is tuned so that the update occurs in proximity to or simultaneous to expiration of the pseudo-active timer. After the update occurs, a router or Internet gateway managing the network will have firewall B on its list of available firewalls and firewall A will be removed from the list.

At block413, firewalls A and B determine whether the pseudo-active timer has expired. If the pseudo-active timer has expired, operations continue to block415. Otherwise, operations continue to block407.

At block415, firewall A initiates a passive state, and firewall B stops handling forwarded packets from firewall A. For instance, the CP at firewall B can instruct the DP at firewall B to process forwarded packets from firewall A according to its normal procedure for handling forwarded packets (e.g., not discarding packets after session states are tracked). Firewall A can be powered down, disconnected from the cloud, deactivated by a CSP, etc.

FIG.4describes operations for maintaining active (i.e., previously established) sessions during a pseudo-active/active firewall configuration of firewalls A and B. In some embodiments, unseen (“new”) sessions that aren't previously established by firewall A are handled by firewall B during this pseudo-active/active firewall configuration. In these embodiments, CP instructions to the DP of firewall A include instructions to forward new sessions without processing these sessions according to an active configuration for firewall A and without sending response packets according to a corresponding session protocol. Additionally, CP instructions to the DP of firewall B include instructions to establish and handle traffic in the new sessions according to the corresponding session protocol.

FIG.5is a flowchart of example operations for processing ingress traffic in a pseudo-active/active firewall configuration while maintaining active sessions. At block501, packets are received at a cloud provider gateway. Block501is depicted with a dashed outline to indicate that receipt of packets while firewalls are in the pseudo-active/active firewall configuration can be ongoing as the remainder of operations depicted inFIG.5are performed. Although described as being received at a cloud provider gateway, packets can be received and routed by any routing component managing routes in a cloud (e.g., a WAN controller).

At block503, the cloud provider gateway maps public IP address in packets to private IP addresses according to a current NAT table. The private IP addresses correspond to firewalls in the cloud, and the NAT table can change during the pseudo-active/active firewall configuration based on a binding update previously initiated at the cloud provider gateway.

At block505, if the packets were sent to the pseudo-active firewall A (i.e., the NAT table mapped the public IP address to a private IP address for firewall A), operations proceed to blocks515and509. Otherwise, operations proceed to block507. As depicted by the dashed outlines inFIG.5, the operations at blocks507,515, and517are performed at an active firewall (firewall B), while the operations at blocks509and513are performed at a pseudo-active (firewall A). The operations at firewall A and firewall B can occur simultaneously and in parallel as packets are processed and sent to firewalls A and B by the cloud provider gateway.

At block507, firewall B processes packets. Firewall B processes packets according to its active state including any corresponding parsing, logging, throttling, classification, intercepting, etc. operations.

At block509, firewall A duplicates and forwards packets in the DP to the active firewall B. Firewall A can communicate packets in the DP to firewall B along a high availability, on premises link. This data link can be specifically allocated to state syncing across firewalls and can be allocated to a specific port at each firewall. In some embodiments, forwarding from firewall A to firewall B occurs in a CP link.

At block513, the pseudo-active firewall A processes the packets. This operation occurs according to an active state for firewall A and can differ from the active state at firewall B, for instance when firewalls A and B are running different software versions (e.g., the firewall switchover event resulting in the pseudo-active/active firewall configuration was a software upgrade for firewall A). In some embodiments, for unseen (“new”) sessions not previously established at firewall A, firewall A forwards packets in these new sessions to firewall B without processing these packets (e.g., without establishing/handling sessions according to a session protocol).

At block515, after firewall B receives packets forwarded from firewall A at block509, the DP at firewall B records sessions for forwarded packets in session state data at firewall B. Firewall B can, for instance, determine state transitions for sessions corresponding to forwarded packets (e.g., with the same source IP address/port, destination IP address/port, and protocol) based on control bits in packet headers. Firewall B can store session states as tuples in a table comprising session identifiers and current session state.

At block517, the active firewall B discards forwarded packets. Firewall B discards the packets and does not send response messages to the cloud provider gateway to avoid split horizon route advertisement. For forwarded packets in new sessions (e.g., as indicated by an establishment field in a packet header according to a session protocol), firewall B can process these packets according to its active configuration including establishing and handling the new sessions and, in these embodiments, these new sessions are not established/handled by firewall A.

At block519, if the pseudo-active timer has expired, operations inFIG.5are complete. Otherwise, operations continue to501for receiving any additional packets at the cloud provider gateway.

Variations

The flowcharts are provided to aid in understanding the illustrations and are not to be used to limit scope of the claims. The flowcharts depict example operations that can vary within the scope of the claims. Additional operations may be performed; fewer operations may be performed; the operations may be performed in parallel; and the operations may be performed in a different order. For example, the operations depicted in blocks507,509,513,515, and517can be performed in parallel or concurrently. Any operations for receiving and processing traffic at firewalls can occur concurrently across sessions/flows. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by program code. The program code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable machine or apparatus.

As will be appreciated, aspects of the disclosure may be embodied as a system, method or program code/instructions stored in one or more machine-readable media. Accordingly, aspects may take the form of hardware, software (including firmware, resident software, micro-code, etc.), or a combination of software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” The functionality presented as individual modules/units in the example illustrations can be organized differently in accordance with any one of platform (operating system and/or hardware), application ecosystem, interfaces, programmer preferences, programming language, administrator preferences, etc.

Any combination of one or more machine-readable medium(s) may be utilized. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable storage medium may be, for example, but not limited to, a system, apparatus, or device, that employs any one of or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technology to store program code. More specific examples (a non-exhaustive list) of the machine-readable storage medium would include the following: a portable computer diskette, a hard disk, a random-access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable storage medium is not a machine-readable signal medium.

A machine-readable signal medium may include a propagated data signal with machine-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A machine-readable signal medium may be any machine-readable medium that is not a machine-readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a machine-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The program code/instructions may also be stored in a machine-readable medium that can direct a machine to function in a particular manner, such that the instructions stored in the machine-readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

FIG.6depicts an example computer system with a firewall switchover event controller, and a firewall network controller in a high availability configuration that supports pseudo-active firewall states. The computer system includes a processor601(possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The computer system includes memory607. The memory607may be system memory or any one or more of the above already described possible realizations of machine-readable media. The computer system also includes a bus603and a network interface605. The computer system also includes a firewall switchover event controller613and a firewall network controller615. The firewall network controller615routes network traffic in a network including ingress and egress traffic at firewalls managed by the firewall switchover event controller613. The firewall switchover event controller613performs a firewall switchover event wherein an active firewall enters a pseudo-active state, a passive firewall enters an active state, and after a pseudo-active timer expires and a binding is updated to direct traffic to the now active firewall, the pseudo-active firewall enters a passive state. This procedure can be modified by the firewall switchover event controller613to handle active network sessions at the pseudo-active firewall as described variously above. Moreover, although depicted as components of an example computer system, any of the components613and615can be components for distinct and, in some embodiments, multiple computer systems. Any one of the previously described functionalities may be partially (or entirely) implemented in hardware and/or on the processor601. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor601, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated inFIG.6(e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor601and the network interface605are coupled to the bus603. Although illustrated as being coupled to the bus603, the memory607may be coupled to the processor601.

While the aspects of the disclosure are described with reference to various implementations and exploitations, it will be understood that these aspects are illustrative and that the scope of the claims is not limited to them. In general, techniques for performing a firewall switchover event using a pseudo-active/active configuration of firewalls in a cloud as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.

Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the disclosure. In general, structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure.

Use of the phrase “at least one of” preceding a list with the conjunction “and” should not be treated as an exclusive list and should not be construed as a list of categories with one item from each category, unless specifically stated otherwise. A clause that recites “at least one of A, B, and C” can be infringed with only one of the listed items, multiple of the listed items, and one or more of the items in the list and another item not listed.