Firewall Network (FireNet) Advanced Configuration
Firewall Network (FireNet) advanced configuration applies to both AWS TGW-based FireNet and Aviatrix Transit FireNet.
This advanced configuration is found here:
-
In the Aviatrix Controller, navigate to Firewall Network > List > FireNet.
-
Select a FireNet in the list and click Details.
Traffic Inspection
You can enable and disable traffic inspection. When traffic inspection is disabled, FireNet Gateway loops back all packets.
Egress Through Firewall
By default, FireNet inspects traffic between North South (on-prem and VPC/VNet) and East West (VPC/VNet to VPC/VNet). To enable Egress traffic (Internet bound) inspection, scroll down to Egress through Firewall and click Enable.
|
Any GCP instance (including Controller-created gateways) that needs to participate in egress control (FQDN, SNAT, and FW egress) have to be tagged as "avx-snat-noip". The GCP network tag "avx-snat-noip" can be associated during GCE creation or by editing an existing instance. |
Egress Static CIDRs
You can allow egress to a subset of your IP address space from your on-prem data center to the Internet with Aviatrix Egress FireNet. Static CIDR egress is supported on Aviatrix Transit and AWS Transit Gateways (TGW). Up to 20 subnets are supported.
Enter the static CIDRs in the field and click Change. This changes the egress static CIDR attribute for the selected FireNet to the value you entered.
Network List Excluded From East-West Inspection
By default, FireNet inspects all East-West (VPC/VNet to VPC/VNet) traffic but you may have an instance in the VPC/VNet that you do not want to be inspected, for example, the Aviatrix Controller deployed in the Shared Service VPC/VNet to be excluded from inspection while Shared Service VPC/VNet traffic is inspected. This improves the Controller reachability by not subjecting the Controller access to unintentional firewall policy errors.
In the Network List Excluded From East-West Inspection field, add the CIDRS to exclude from firewall inspection.
|
Firewall Forwarding
The FireNet solution supports two hashing types:
-
Two-tuple (Source IP/Destination IP)
-
Five-tuple (Source IP/Source Port/Destination IP/Destination Port/Protocol Type)
By default, AWS TGW-based FireNet and Aviatrix Transit FireNet use 5-tuple hashing algorithm (source IP, source port, destination IP, destination port and protocol type) to load balance the traffic across different firewall. However, you can select the two-tuple (source IP and destination IP) hashing algorithm to map traffic to the available firewalls.
Keep Alive via Firewall Lan Interface
For AWS, LAN or Management interface can be used for firewall health check and failure detection.
By default, Aviatrix Controller check the firewall’s health by pinging the firewall’s management IP address. Starting 6.0, firewall instance’s health can also be checked by pinging its LAN interface from the connecting Aviatrix FireNet Gateway. This is an alternative approach which improves firewall failure detection time and detection accuracy.
The mechanism is that the FireNet Gateway pings the firewall instance’s LAN interface every 5 seconds with a ping time out of 20ms. If the first ping times out, it immediately pings again. Two consecutive ping failures indicates the firewall is in down state and it is detached from the FireNet Gateway pool. The ping functions continues and it detects the firewall instance has come up by successful pings, it is attached back to the FireNet Gateway pool.
With LAN interface pinging, the firewall instance fail over time is reduced.
The following details describe how to enable ping on the firewall instance LAN interface.
Enabling ICMP on Firewall Devices
Palo Alto Network
-
Go to Network > Network Profiles > Interface Mgmt and create profile to allow ping.
-
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.
-
Commit changes.
Check Point
Go to SmartConsole > Global Properties > Firewall > Accept ICMP requests.
Verifying LAN Side ICMP Health Check
In this example, AWS and Check Point used to demonstrate the functionality as shown below:
Go to Check Point logs and Monitoring section, notice that the ICMP health check is initiated every 5 seconds from the Aviatrix Transit FireNet Gateways. The 5 second setting is the default and cannot be changed.
Checking Firewall Health in Azure and GCP
Enabling Transit FireNet for Azure or GCp automatically creates Load Balancers in those CSPs. HTTPS in these Load Balancers performs the firewall health check (not ping). You must disable ping in the interface management profile of your Azure or GCP firewalls.
In Azure:
-
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.
In GCP:
-
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.