--- title: "Virtual network firewall" canonical: "https://docs.aryaka.com/space/KNOW/1299808728/Virtual%20network%20firewall" format: markdown --- The Aryaka SmartSecure Virtual Network Firewall (VNF) runs on an Aryaka-provided ANAP device instead of proprietary vendor hardware. The ANAP includes the Aryaka Agent, which is a software instance that can host a third-party virtual machine (VM) that emulates a firewall. This document describes the architecture, traffic flow, deployment, and operation of a virtual firewall on the Aryaka ANAP located at your site.  Supported firewall vendors Vendor Models Aryaka Qualified Operating Systems Check Point CloudGuard Edge with two CPU configurations: 2 CPU 4 CPU R80.20.40 R80.20.60 (Recommended) Palo Alto Networks VM-50 VM-100 VM-300 PAN OS 9.1.x PAN OS 10.1.x (Recommended) Note:  Only inline upgrade is supported. Instantiate the VM using 9.1.x and then upgrade to 10.1.x. If you want to run any other version of a firewall operating system, contact  support@aryaka.com . Terminology ANAP—Physical device provided by Aryaka, which has the Aryaka Agent running on it. Aryaka Agent ( see also: Host)—The Aryaka software instance running on the ANAP that hosts the VM. The VM interfaces with the Aryaka Agent to route traffic, attain optimization benefits, and so on. Datapath— Active state of the firewall in the network that consumes and processes network traffic flowing between the LAN network and Aryaka Agent. Firewall ( see also: Virtual Machine)—Entity that emulates a system that is hosted on the ANAP. In the context of this document, the VM emulates a firewall. Host ( see also: Aryaka Agent)—The Aryaka software instance running on the ANAP that hosts the VM. The VM interfaces with the Aryaka Agent to route traffic, attain optimization benefits, and so on. Virtual Machine ( see also:  VM, Firewall)—Entity that emulates a system that is hosted on the ANAP. In the context of this document, the VM emulates a firewall. Prerequisites You must satisfy the following requirements to configure a VM on an ANAP: Aryaka SmartSecure VNF license Firewall vendor’s platform subscription ANAP operating in edge routed mode (ERM) Separate public IPs for the ANAP and the VM (as per the table in next section) VM image in raw or qcow2 format Public IP requirements The following table shows the minimum IP requirements for an ISP: Vendor Standalone Deployment HA Deployment Palo Alto Networks Requires three public IPs: ANAP's M1/M2 interface M1/M2 interface gateway Firewall's WAN interface Requires three public IPs: ANAP's M1/M2 interface M1/M2 interface gateway Firewall's WAN interface For HA deployments, the public IP must be configured as an interface IP on the WAN interface of the firewall, and the IP is active on the active firewall. Check Point Requires three* public IPs: ANAP's M1/M2 interface M1/M2 interface gateway Firewall's WAN interface * Aryaka expects you to use the ANAP's M1/M2 interface gateway address as the gateway and for the firewall interface. If these addresses are in different subnets, a fourth dedicated IP must be used as the WAN gateway in the same subnet as the firewall's WAN interface. Requires three public IPs: ANAP's M1/M2 interface M1/M2 interface gateway Firewall's WAN interface Except for the management and HA interface of the firewall, all other interfaces should be deployed in cluster mode . Cluster mode allows each HA firewall to have its own interface IP. Virtual IP (VIP) must be configured and applied to the active firewall. What Aryaka provides for the VM Aryaka provides the following for a hosted VM: ANAP device with the required resources to run the VM.  MyAryaka functionality: Ability to provision the VM. Ability to place the VM in the datapath. Controls to start, stop, and restart the VM. Ability to display system and network statistics for the VM. What the customer provides for the VM Your organization is expected to provide the following for an Aryaka-hosted VM: VM license—You must obtain and manage the firewall license. VM image—You must obtain an image from the vendor and upload it to the ANAP using MyAryaka. VM image upgrades—You must obtain and upload any desired updates and patches to the VM image. Firewall configuration—You are responsible for the configuration of the virtual firewall. If you want Aryaka to manage obtaining and uploading the VM image and updates, and configuring the VM (that is, everything except obtaining the license) you can subscribe to Aryaka's Managed Firewall Services (MFS). For details and pricing, contact sales@aryaka.com . SmartSecure VNF firewall architecture The following graphic shows the major components and relationships of the VNF firewall architecture. Note the following in the graphic: The ANAP is deployed in ERM mode with two ISPs terminating on M1 and M2 interfaces of the ANAP. The virtual firewall is logically present between the site’s LAN network and the Aryaka Agent running on the ANAP. M1 and M2 interfaces have their own public IPs which are owned by the Aryaka Agent. The Aryaka Agent continues to use the M1 and M2 interfaces for tunnels to the Aryaka POP and remote ANAPs. When the firewall is placed in the datapath, the LAN interface of the ANAP is owned by the firewall. The firewall should have its own public IP range which it uses for its WAN-facing interfaces and NAT. This public IP range is bypassed by the Aryaka Agent on the ANAP so it does not NAT any traffic for the defined public IP range that is being used by the firewall. VM interfaces The VNF model supports the following interfaces that can be configured for the firewall: LAN—The firewall's LAN is connected to the physical LAN interface of the ANAP. This logical connectivity between the two interfaces is achieved using a MacVTap driver. DMZ—The firewall's DMZ is connected to the any one of the following interfaces of the ANAP using a MacVTap driver: WAN S1 (available only on the ANAP-3000 model and above) S2 (available only on the ANAP-3000 model and above) VPN—Interface is responsible for carrying site-to-site traffic over one of the following Aryaka managed network paths: VPN Path Aryaka VPN Path Internet Note:  Any traffic that lands on the VPN interface is connected to the VNET0 interface of the kernel-based virtual machine (KVM), which then forwards the traffic to the Aryaka Agent on the ANAP. WAN1—This VM interface is directly associated with the ANAP's M1 interface. Internet-bound traffic leaving the WAN1 interface is sent to the VNET1 interface of KVM, which is then sent to the ANAP’s M1 interface. WAN2—This VM interface is directly associated with the ANAP's M2 interface. Internet-bound traffic leaving the WAN2 traffic is sent to the VNET2 interface of KVM, which is then sent to the ANAP’s M2 interface. Management—Similar to LAN interface, the management interface of the VM firewall is directly connected to the SYNC interface of the ANAP using MacVTap. We recommend using this interface for the initial firewall configuration. HA—This VM interface can be associated with any physical port on the ANAP. We recommend that you use the WAN port. Routing SmartSecure VNF offers the following routing types: Routing between the LAN and the firewall—Based on the capability of the firewall, you can either use static or dynamic routing on the LAN side of the network. This routing is transparent to the Aryaka Agent on the ANAP and Aryaka does not need to know what type of routing is being done on the LAN side of the firewall. Routing between the firewall and Aryaka Agent—The following routing methods are supported: Static RIP BGP Note:   For RIP and BGP routing, the Aryaka Agent expects the peering to be configured between the VPN0 interface and its gateway. This IP information for VNET0 must be provided while configuring the VM. Datapath When a VM is configured and started, it is not added to the datapath automatically. Adding the VM to the datapath is a separate operation from starting it. Initially, LAN traffic is routed to the Aryaka Agent and then to the Aryaka Private Core or to the internet. After the VM is started, and the firewall configuration is completed, it needs to be placed in the datapath. This section describes placing a VM into the datapath and how that impacts the packet flow. For an ANAP deployed at a live site, placing a VM in the datapath requires the following actions: The LAN interface moves from the Aryaka Agent to the VM. As a result, the Aryaka Agent must be assigned a new IP. If BGP peering if configured between the Aryaka Agent and the LAN device, it must be moved between the Aryaka Agent and the firewall. The firewall might need BGP peering with the LAN device. NAT configurations done on the Aryaka Agent must be migrated to the firewall. If cloud security connectors are being used, their configuration needs to move to the firewall. Review any perimeter policies, interior policies, and other advanced configurations to determine if they need to be migrated to the firewall. High Availability (HA) Prerequisites You must satisfy the following requirements before configuring a pair of VMs in HA mode.  ANAP HA (VARP) must be enabled. Unlike standalone deployment, in HA, the Aryaka Agent requires an IP (SYS IP) on the LAN interface of both the participating ANAPs. This IP is used for HA communication between the ANAPs. ANAP's LAN interface and firewall's LAN interface IPs must be in the same subnet. Both HA firewalls must be the same model. Both HA firewalls must be running on the same OS version. HA preemption, which makes a device active based on the firewall's priority configuration, must be disabled on the firewall. A unique license is required for each firewall. (Palo Alto Networks only) Management connectivity of the firewall through dedicate management port must be configured. As depicted in the topology diagram in the next section, the firewall's management interface is connected to the SYNC port of the ANAP. (Check Point only)—Certain interfaces should be deployed in cluster mode. Details of the interfaces are discussed in the vendor-specific HA topology concerns in the next section. HA-specific topology The following graphic illustrates a typical HA firewall topology with two ANAPs and two ISPs. A description of the components and their relationships follows. Note the following in the graphic: A pair of VMs are required to implement HA. Each VM is hosted on an ANAP: ANAP 1 is active, and ANAP 2 is in standby. Each ANAPs WAN port is used for firewall's HA link. WAN ports of both ANAPs are connected to each other. Unlike standalone deployments, the Aryaka Agent's LAN interface IP has an IP configured on the LAN interface of the ANAP. This IP is used for HA communication between the Aryaka Agents on the two ANAPs. This HA communication between the ANAPs does not pass through the firewall. Aryaka Agent includes the required security policies to accept only the peer Aryaka Agent's HA messages on this IP.  Active/Passive is the only supported mode for the firewalls. Therefore, only one firewall is ever active and  managing the traffic. The standby firewall has its configuration synchronized with the active firewall, but is in a passive state. In an event of failure, the passive firewall gets transitioned to an active state. This failover transition can be triggered by system, network, or link failure. Note the following vendor-specific HA topology concerns: Palo Alto Networks—Similar to a standalone deployment, the interface IPs are configured on the firewall. The active firewall owns the IP. Check Point—The HA firewalls are deployed in cluster mode. In cluster mode, each firewall interface gets a physical interface IP that stays on that particular firewall. Additionally, the interfaces that are participating in cluster get a cluster IP , also known as a virtual IP (VIP). The VIP stays on the active firewall. Firewall interfaces that can be deployed in a cluster: LAN1, LAN2, LAN3, LAN4, and LAN5. Note that the LAN3 and LAN4 interfaces are used for WAN purposes and must have a private IP configured. The VIP can be a public IP. Firewall interfaces that can not be deployed in a cluster: MGMT and LAN10. HA firewall links The following table lists the HA links that a deployed HA firewall can have. Vendor Link type and purpose Firewall interface ANAP port Check Point SYNC—Used for HA communication between the two HA firewalls.  LAN10 WAN Palo Alto Networks Control Link (HA1)—Used to exchange hellos, heartbeats, sync configuration, and HA state information between the two HA firewalls. Management interface SYNC Data Link (HA2)—Used to sync sessions, forwarding tables, IPSec security associations, and ARP tables between the two HA firewalls. Except for the HA2 keepalive, data flow on the HA2 link is always unidirectional. It flows from the active firewall to the standby firewall. Ethernet1/12 WAN HA backup links are currently not supported. Failover This section describes the two types of failover in a HA deployment: ANAP failover and firewall failover. It also includes a number of sample failover scenarios.  ANAP failover The ANAP uses Aryaka's proprietary protocol's hello messages between the two peers. By default, the Aryaka Agent waits for 30 seconds before triggering a failover. When a VNF is deployed, the Aryaka Agent relies on path monitoring to monitor the VM and trigger a failover. Path monitoring is similar to VM health check (discussed later in this topic), where Aryaka Agent monitors the reachability of firewall's VPN interface using ICMP or ARP (default). If the Aryaka Agent detects failure while path monitoring, it triggers a failover by relinquishing its state. To use path monitoring with ICMP instead of the default ARP, you must allow ICMP on the VPN Interface. VM health check and path monitoring cannot be used together. Aryaka Agent initiates path monitoring only when the VM is placed in the datapath. Firewall failover You can configure the firewall to trigger the failover by enabling the default path probing and monitoring capabilities.The firewall must also monitor the ANAP IP (the firewall's VPN0 gateway address). Firewall interfaces monitoring and link monitoring cannot be enabled. If the ANAP interfaces go down, there is no way for the VM interface to know about it. Firewall path monitoring must be enabled after placing the VM in the datapath, otherwise it leads to unwanted failover between the firewall peers. Failover examples Consider the following two ANAPs: ANAP 1—Both the Aryaka Agent and firewall are active. ANAP 2—Both the Aryaka Agent and firewall are in standby. Case 1 On ANAP 1, the firewall fails due to an internal failure. This triggers a failover between the firewalls and firewall on ANAP 2 becomes active. This causes the firewall to withdraw the IP from ANAP 1. At the same time, path monitoring by the Aryaka Agent on ANAP 1 fails. This causes the Aryaka Agent to also failover its services to ANAP 2. Case 2 On ANAP 1, the Aryaka Agent fails. This causes the VARP hello messages to fail and the Aryaka Agent on ANAP 2 to become active. This causes the RSE-configured ANAP IP (VNET0 IP) to be withdrawn and the firewall's path monitoring to fail on ANAP 1. This results in the firewall also failing over its services to ANAP 2. Packet path when a VM is in the datapath The following graphic shows the major components and associated packet flow in the hosted VM firewall architecture for the following scenarios: Traffic from the LAN to the Aryaka Private Core Traffic from the LAN to the internet These two flows are detailed in the sections that follow. Traffic from the LAN to the Aryaka Private Core A client on the LAN network or the distribution switch is configured to have its default gateway as the firewall's LAN interface IP. After a packet reaches the LAN interface of the firewall, it is processed by the firewall's policy and routing engine. If the destination is a remote site’s network, which is expected to be routed through a VPN path operated by Aryaka, the traffic is routed using the VPN Zone to the VNET0's interface. If a static route is used, configure the firewall to route this traffic to VNET0's IP. This IP is referred to as the ANAP IP in the MyAryaka portal and the firewall's VPN Zone interface IP is called the ANAP Gateway IP . Dynamic routing including RIP or BGP also can be deployed to route traffic. After the packet reaches VNET0, it is forwarded to the Aryaka Agent for additional processing. Based on the routing table maintained by the Aryaka Agent, traffic is forwarded to one of the networks paths operated by the Aryaka Agent. Traffic from the LAN to the internet The firewall can have one or two WAN interfaces, which are represented as WAN1 and WAN2 in the previous graphic. Traffic from the LAN reaches the firewall.  Packets destined to the internet are routed by the firewall. In general, the internet traffic uses the default route, which can be configured as follows: Next hop as interface—For any destination, the firewall has the WAN1/WAN2 interface set as the next hop. In this case, VNET1/VNET2 performs a proxy ARP for the gateway addresses of the WAN1/WAN2 interface and the internet-destined packets land on the respective physical interfaces of the ANAP. Next hop as IP—Requires that the IP must be a WAN1/WAN2 gateway address. VNET1/VNET2 performs a proxy ARP for these gateway addresses and the internet-destined packets land on the respective physical interfaces of ANAP. Note:   In both of these cases, the WAN1/WAN2 interface gateway information has to be shared with Aryaka. The return traffic from internet to the LAN is handled the same way as the forward path, only in the reverse direction. VM health check VM health check monitoring can only be enabled for standalone deployments—it is not supported for HA implementations.  When enabled, the Aryaka Agent monitors the reachability of the VM by pinging the IP address configured on the firewall's VPN0 interface. If the VM is not responding, the Aryaka Agent assumes that the VM is powered down and has not gone through a graceful shutdown. It attempts to restart the VM up to five times before stopping. If the VM has gone through graceful shutdown, the Aryaka Agent does not try to restart the VM. Note that this health check requires that ICMP is allowed for the VPN interface of the firewall. The Aryaka Agent sources the ping with the gateway address of VPN interface of the firewall. Additional considerations Only the documented data interfaces and the management interface are supported. Sub-interfaces are supported only on the LAN and DMZ interfaces of the firewall. Only one VPN Zone is supported. After the firewall is in the datapath, NAT is expected to be handled by the firewall. Configuring and operating the VM See the Manage virtual machines topic for details about configuring and operating VMs from the MyAryaka portal. Interface mapping This section describes the interfaces that are available for each firewall vendor. Palo Alto Networks Even though the Palo Alto Networks firewalls support up to 24 interfaces, the Aryaka Agent currently supports only six. Only use the data interfaces as shown in the following table. Interface Purpose ethernet1/1 LAN ethernet1/2 VPN (traffic routed to Aryaka Agent for its processing) ethernet1/3 WAN1 ethernet1/4 WAN2 ethernet1/5 DMZ ethernet1/12 HA2 (Data Channel) In addition to these six data interfaces, the management interface over management plane is also supported to provide management connectivity. Check Point Even though the Check Point firewalls support up to 11 interfaces, the Aryaka Agent currently supports only five. Only use the data interfaces as shown in the following table. Interface Purpose LAN1 LAN LAN2 VPN (traffic routed to Aryaka Agent for its processing) LAN3 WAN1 LAN4 WAN2 DMZ DMZ LAN10 SYNC (HA) In addition to these five data interfaces, the management interface over the WAN port is also supported to provide management connectivity. Firewall features that require additional consideration This section describes additional considerations that must be made for features included by each firewall vendor if you choose to enable them. Palo Alto Networks DPDK—Before enabling the Data Plane Development Kit (DPDK), contact Aryaka support to ensure the Aryaka Agent software version on your ANAP supports this functionality. ECMP—To enable the Equal Cost Multiple Path (ECMP) functionality when the WAN gateways are in a different subnet than the firewall's WAN interface IPs, configure the firewall as follows: Add a static route with the Destination as WAN Gateway IP , the Interface as WAN Interface (ethernet1/3) and Next Hop as none .  If the secondary WAN interface (ethernet1/4) is configured, add a similar static route with the Interface as WAN Interface (ethernet1/4) instead.  Check Point ECMP—We recommend disabling the Equal Cost Multiple Path (ECMP) functionality. Routes—In standalone deployments with dual ISPs for internet, specify the following firewall routes: For the WAN1 interface, the next hop should be 169.254.3.1/32 For the WAN2 interface, the next hop should be 169.254.3.2/32 In this topic Related topics Manage virtual machines ANAP VNF Performance Matrix - Check Point and Palo Alto VM Firewalls (PDF)