Checking the Health of Your Firewall

Firewalls play a critical role in securing cloud network environments by inspecting and controlling traffic between resources. This document explains how Aviatrix monitors the health of firewall instances across different cloud providers, detailing the mechanisms used to detect failures and ensure high availability. You will learn about the keepalive health checks, their configuration, and how Aviatrix adapts its monitoring approach for AWS, OCI, Azure, and GCP to maintain robust data plane protection and seamless failover.

Understanding Firewall Keep Alive Checks

Aviatrix Transit FireNet uses two types of health checks to monitor firewall status: the LAN keepalive health check and the API health check. Both health checks operate independently and in parallel when Vendor Integration is enabled. LAN keepalive healthchecks remain mandatory for proper functionality, even if API integration is active.

LAN keepalive health checks:

  • Are enabled by default, and only applicable for AWS and OCI.

  • Determine whether the firewall related to an Aviatrix Transit FireNet is ready to receive traffic.

API health checks check the instance status using CSP APIs and Vendor API when Palo Alto vendor integration is enabled. Both of these health checks are primarily for instance status display and do not contribute to failover functionality. Load Balancers are used in Azure and GCP to probe the health of firewalls, which is essential for failover.

Further information on the health check functionality and how the keepalives work across CSPs for Transit FireNet is described below.

If using Controller 7.1 and earlier, the LAN keepalive function must be enabled to have a smooth upgrade to Controller 7.2. It is not possible to roll back to using the firewall management interface for keepalive in Controller 7.2 and later.

In Controller 7.1 and higher, the option to enable or disable ‘Keep Alive via Firewall LAN Interface’ has been removed from the user interface. The LAN keepalive is always enabled by default and cannot be disabled.

AWS and OCI Health Check

LAN keepalive health checks are mandatory, enabled by default, and only applicable for AWS and OCI. To check firewall health in Azure and GCP, see below.

For AWS and OCI, each keepalive cycle includes the following:

  1. The Aviatrix gateway sends the LAN keepalive to the firewall LAN interface.

  2. The ICMP ping is sent first with a timeout of 150ms.

  3. If ICMP fails, a TCP ping on port 443 is sent immediately with a timeout of 300ms.

  4. These checks are performed every five seconds.

  5. Two consecutive failed cycles (i.e., both ICMP and TCP fail twice) trigger firewall failover. The minimum time to declare a firewall down is approximately ten seconds (two five second intervals).

ICMP and TCP pings are sent back-to-back within a cycle, not spaced five seconds apart. A new cycle begins five seconds after the previous cycle completes.

If using AWS Gateway Load Balancer (GWLB), health is checked by the GWLB via the AWS API for target group health (for display purposes only). The GWLB is responsible for failover.

API Checks

  • Vendor API only for PAN/Panorama when firewall integration is enabled: Used to check management plane readiness.

  • If vendor API probe fails, firewall status in the UI shows “inaccessible.”

  • Route push (e.g., new CIDRs) may fail if the firewall is inaccessible.

Azure Health Check

Adding FireNet to a Transit gateway in Azure automatically creates a Load Balancer in the Azure cloud console. HTTPS in these Load Balancers performs the firewall health check (not ping).

  • The Azure Load Balancer (LB) probe (TCP/443) is the only failover mechanism.

  • The Aviatrix Controller/gateway does not perform LAN keepalive checks in Azure.

  • Failover is handled natively by the Azure LB health probes.

API Checks

  • CSP API: Aviatrix Controller queries Azure API every 60s for VM instance status (display only, such as up/down status).

  • Vendor API only for PAN/Panorama: If enabled, the Aviatrix Controller probes via vendor API.

  • If the vendor API fails, status shows “inaccessible.”

You can check the health probe status under Monitor > Metrics. See this article for more information.

The State column on the Gateway page in the Aviatrix Controller only reflects if the firewall is up or not. It does not reflect if the firewall is responding to health checks. You must check the health of the firewall in the Azure portal.

GCP Health Check

Adding FireNet to a Transit gateway in GCP automatically creates a Load Balancer in the GCP cloud console. HTTPS in these Load Balancers performs the firewall health check (not ping).

  • The GCP Internal Load Balancer (ILB) health probe (TCP/443 or ICMP) is the only failover mechanism.

  • The Aviatrix Controller/gateway does not perform LAN keepalive checks in GCP.

  • Failover is handled natively by the GCP ILB health probes.

You can check the health status of the backend under Network services > Load balancing > Load balancer details. See this article for more information.

The State column on the Gateway page in the Aviatrix Controller reflects the health status of the firewall from the GCP load balancer.

API Checks

  • CSP API: Aviatrix Controller queries GCP backend health every 60s (display only).

  • Vendor API only for PAN/Panorama: If enabled, the Aviatrix Controller probes via vendor API.

  • If vendor API fails, status shows “inaccessible.”

Comparison Table

The following table provides a side-by-side comparison of firewall health check and failover mechanisms across major cloud providers.

Cloud Failover Trigger CSP API Check (Display Only) Vendor API Check (Display Only) Notes

AWS

LAN keepalive (ICMP/TCP 443)

When using GWLB

Yes (if enabled)

Only LAN keepalive triggers failover

Azure

LB probe

Yes

Yes (if enabled)

Only LB probe triggers failover

GCP

LB probe

Yes

Yes (if enabled)

Only LB probe triggers failover

OCI

LAN keepalive (ICMP/TCP 443)

N/A

Yes (if enabled)

Only LAN keepalive triggers failover

Failover is only triggered by LAN keepalive in AWS and OCI, or CSP-native LB probes in Azure and GCP.

CSP API and Vendor API are only used for management plane status/display.

Enabling Ping for LAN-Based Health Checks

To ensure accurate LAN-based health monitoring, firewalls must be configured to allow ICMP (ping) traffic on their LAN interfaces. The following subsections provide step-by-step instructions for enabling ping on supported firewall platforms, including Palo Alto VM-Series, Fortinet FortiGate, and Check Point firewalls. Proper configuration is essential for Aviatrix to perform reliable keepalive checks and maintain high availability.

Enabling Ping on VM-Series Firewall

  1. In the Palo Alto UI, go to Network > Network Profiles > Interface Mgmt and create profile to allow ping.

    pan_network_profile

  1. Go to Network > Interfaces, select Ethernet 1/2, go to the Advanced tab > Management Profile and select the profile just created in the step above.

    pan_lan_attach

  1. Commit changes.

Enabling Ping on Check Point and Fortinet

For Check Point CloudGuard and Fortinet FortiGate, CoPilot uses AWS API to check instance health.

In the Fortinet FortiGate UI, navigate to Network > Interfaces > Edit Interface and select the PING checkbox.

fortigate example ping

In the Check Point UI, navigate to SmartConsole > Global Properties > Firewall > Accept ICMP Requests.

cp ping enable one
cp ping enable two

CoPilot can also check firewall instance health on its LAN interface.