--- title: "Palo Alto Networks NFV" canonical: "https://docs.aryaka.com/space/KNOW/1299972704/Palo%20Alto%20Networks%20NFV" format: markdown --- The Aryaka Network Access Point (ANAP) is a physical device that can host a virtual firewall (also known as a virtual network function (VNF) or a virtual machine (VM)) for customers implementing security infrastructure in accordance with Aryaka’s SD-WAN capabilities. This document describes the integration and operation of Palo Alto Networks NFV hosted on a single ANAP (standalone mode) or a pair of ANAPs (high availability mode). Terminology ANAP—The physical hardware device provided by Aryaka that includes the Aryaka Agent, which performs SD-WAN optimization. Datapath—An active firewall in the path that processes network traffic and performs routing, This traffic flows from the LAN and processed by the Aryaka Agent to forward it accordingly. Edge routed mode (ERM)—An ANAP deployment mode where the ANAP is deployed as a single- or dual-homed gateway. The ANAP can connect to the POP or to both the POP and the internet. In this topology, the ANAP acts as a firewall and performs NAT. Guest virtual machine (VM)—Third-party vendor's VM hosted on an ANAP designed to implement NFV capabilities in accordance with the ANAP's functionality. Host Aryaka Agent—Used to reference Aryaka VM instances that reside on the ANAP. The guest VM interfaces with the Aryaka Agent to route traffic and perform network optimization. Managed firewall service (MFS)—A service provided by Aryaka that provides firewall configuration, management, and monitoring.  Network function virtualization (NFV)—Architectural concept to virtualize network functions—including routers, firewalls, and load balancers—that have traditionally been installed as software VMs and run on proprietary COTS (commodity off-the-shelf) hardware. NFV and VNF are used interchangeably. Network function virtualization infrastructure (NFVI)—Hardware infrastructure on which the software platform runs network applications (for example: compute, storage, hypervisors, and so on). Virtual network functions (VNF)—Software-based applications that provide one or more network services such as routers, firewalls, and load balances. VNFs use the virtualized infrastructure provided by the NFV infrastructure to connect to the network and provide programmable, scalable network services. NFV and VNF are used interchangeably. VNET0/1/2—Internal interface within the Linux kernel. Prerequisites for a standalone deployment You must satisfy the following requirements to configure a Palo Alto Networks VNF on an ANAP: Aryaka SmartSecure VNF license. Palo Alto Networks firewall platform subscription license. ANAP running in  edge routed mode (ERM) . VM image in raw or qcow2 format. Minimum of three public IPs: One for the ANAP's M1/M2 interface One for the M1/M2 interface gateway One for the firewall’s WAN interface Note:  You must also provide a fourth IP for the firewall’s WAN Interface gateway if you use the ANAP's M1/M2 interface as the gateway address  and as the gateway for the firewall interface, and these two addresses are in different subnets, a dedicated IP that is in the same subnet as the firewall's WAN interface must be used as the WAN gateway. VNF responsibilities The section describes the Aryaka and customer responsibilities for the VNF installation, configuration, maintenance, and operation. Aryaka's VNF responsibilities Aryaka provides the following to customers implementing a Palo Alto Networks VNF solution: ANAP device—Physical hardware device that hosts the Palo Alto Networks virtual firewall. MyAryaka account—Management UI portal to configure, manage, and monitor network functionality and visibility. MyAryaka offers the following VM/VNF-related features: Ability to upload the VNF Image. Configuration of network details including IP/WAN-IP. Configuration of application policies, traffic routing, zones, QoS, and so on. Monitoring of VM system statistics. Traffic statistics on the datapath and external exit points. If VNF issues arise—either traffic-related or with firewall functionality—Aryaka is only responsible for alerts and notifications. Customer’s VNF responsibilities Obtain the Palo Alto Networks licenses for the VM firewall (one for standalone, two for high availability) and the Panorama Central Management Server. Panorama is required in most regional and global deployment scenarios. Obtain the Palo Alto Networks VM image and upload it to MyAryaka before it is placed in datapath. Firewall and Panorama configuration, maintenance, and operation. Day 0/Day 1 configuration, logistics, and support, including the following: Greenfield and brownfield configuration. Migration from an existing third-party vendor to Palo Alto Networks. Configuration of security, NAT, interfaces, and basic firewall setup. Panorama licensing, design, and configuration. Firewall via Panorama also requires configuration for device groups and templates for firewall specifics. Operation the firewall using the Palo Alto Networks VNF Support portal. For troubleshooting related to firewall or Panorama functionality, you must contact Palo Alto Networks TAC support at  https://support.paloaltonetworks.com . Aryaka support cannot help debug the firewall or Panorama functionality. The following table summarizes the VNF responsibilities. VNF Feature Aryaka Customer Image upload   VNF license   Firewall Configuration Migration from previous vendor to Palo Alto Networks   Initial basic configuration   VNF troubleshooting   Panorama Configuration   Device groups and templates   ANAP ANAP configuration   ANAP troubleshooting   Additional NFV implementation considerations This section describes the additional considerations for implementing the Data Plane Development Kit (DPDK) or Equal Cost Multiple Path (ECMP) functionality. DPDK support Contact Aryaka support ( support@aryaka.com ) and request that they enable DPDK on your Aryaka network. Requires minimum PanOS version 9.1.x. ECMP support For the feature must be enabled, you must add a static route if the firewall and the WAN gateways are in a different subnet than the WAN interface IPs of the firewall as follows: Add a static route with the destination being the WAN gateway IP, the interface being the WAN interface (eth1/3), and the next hop being none. If the secondary WAN interface (eth1/4) is configured, add a similar static route for that interface. Supported NFV VM models The following Palo Alto Networks models are supported on the following ANAP models: VM-50—Supported on ANAP 2600 and ANAP 3000. VM-100—Supported on ANAP 3000 and above. VM-300—Supported on ANAP 10000. VM capacity by supported model: Model Sessions Security Rules Dynamic IP Addresses Security Zones IPSec VPN Tunnels SSL VPN Tunnels VM-50 50,000 250 1,000 15 250 250 VM-100 250,000 1,500 2,500 40 1,000 500 VM-300 800,000 10,000 100,000 40 2,000 2,000 VM hardware requirements by supported model : Model Supported  vCPUs Minimum  Memory Minimum  Hard Drive VM-50 2 4.5GB 60GB VM-100 2 6.5GB 60GB VM-300 2 or 4 9GB 60GB For more information on Palo Alto Networks VM models, see the  VM-Series Deployment Guide (at paloaltonetworks.com). Supported NFV VM PanOS versions The following Panorama operating systems are supported: PAN OS 8.1.x PAN OS 9.1.x (recommended for new deployments) PAN OS 10.x Palo Alto Networks standalone architecture overview This section contains a high-Level overview of the ANAP internal architecture with NFV VM in the datapath. Note the following in the graphic:  The ANAP is deployed in edge routed mode with two ISPs terminating on the ANAP's M1 and M2 interfaces. The 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 that connect the POP and the remote ANAPs. The architecture requires three public IPs: ANAP’s M1/M2 Interface ANAP’s M1/M2 gateway Interface VNF (WAN) Interfaces  VNF configuration requirements Consider these requirements while configuring your Palo Alto Networks VNF VM. Logical overview The VNF firewall is deployed between the customer’s LAN switch and ANAP’s physical LAN Interface. This ensures all traffic in and out of the customer’s LAN undergoes firewall inspection. Physical Overview The traffic still has to enter the ANAP through its physical lan port, but needs to be directly forwarded to the firewall VM LAN interface without going through any processing on the ANAP. All LAN-side VLANs and IP addresses must be configured on the firewall LAN interface instead of being on the ANAP. The only exception is a management VLAN and a corresponding IP address that is configured on the ANAP itself. This allows management access to the ANAP through the LAN interface even when the firewall is not running. The IP address configured on the management VLAN interface is the ANAP system IP (sys IP). All security policies, NAT rules for internet and DMZ access, inter-VLAN routing on the LAN side, and so on are configured on the firewall. The ANAP acts as a SD-WAN-capable edge router handling VPN IPSec tunnel setup and management, VPN routing, Internet link management, and so on. The goal is to avoid (to the extent possible) any duplicate configuration of addresses and policies on the firewall and the ANAP. It is expected that a clear separation in functionality between the firewall VM and the ANAP greatly reduces the need for any duplicate configuration. The firewall router must be aware of all remote subnets that are reachable over the Aryaka network. This could either be through static configuration or through a RIP/BGP session with the ANAP. Similarly, the firewall router must be aware of all the local subnets either through static configuration or through a dynamic routing protocol that allows it to route return traffic over the correct VLAN. A default route on the firewall routes all internet traffic to its internet interface. The internet traffic should undergo source network address translation (SNAT) with the private source IP address replaced by a public IP address or an address from a public pool configured on the firewall internet interface. Because the firewall can be configured with site-to-site IPSec tunnels of its own, it needs a different public address to be used for the tunnel end point—it cannot be the one used by the ANAP for its IPSec tunnel to the Aryaka POP. Security zones Palo Alto Networks must be configured in at least the following three security zones: LAN—Trust zone representing the customer’s local network. WAN—Untrust zone representing all connectivity including internet (DIA), VPN Path Aryaka, VPN Path Internet, MPLS, VPN Express, Cloud Connectivity, IaaS, and SaaS. VPN—VPN zone representing the customer’s remote site subnets accessible over the Aryaka core network. Palo Alto Networks VNF to ANAP interface mapping This section describes the physical (ANAP) to virtual VNF interface mapping details. Note that even though the Palo Alto Networks firewall supports up to 24 interfaces, the Aryaka Agent currently supports only five, plus the management interface. It is expected that you use these five data interfaces as shown in the following table. Palo Alto Networks Interface ANAP Physical/Virtual Mapping Purpose ethernet1/1 LAN Incoming data interface (firewall LAN) ethernet1/2 VPN VPN traffic routed to the Aryaka POP ethernet1/3 WAN1 (M1 - Physical) Traffic routing to M1 ethernet1/4 WAN2 (M2 - Physical) Traffic routing to M2 ethernet1/5 DMZ (S1/S2) DMZ ethernet1/11 WAN HA2 (data backup) Management SYNC Management connectivity and HA1 Palo Alto Networks firewall interface details This section describes the various Palo Alto Networks firewall interfaces in detail. LAN The firewall LAN interface connects to the physical LAN interface of the ANAP. The logical connectivity between the two interfaces is achieved using a Linux kernel driver. In a standalone VNF deployment on a standalone ANAP, the ANAP’s physical LAN interface does not require an IP configuration as it is mapped to the VNF’s LAN interface IP configuration. DMZ The firewall DMZ interface can be directly connected to the any one of the following interfaces of the ANAP using a Linux kernel driver configuration: WAN S1 (available only in the ANAP-3000 model) S2 (available only in ANAP-3000 model) VPN   The firewall VPN interface carries site-to-site traffic through one of the following Aryaka managed network paths: VPN Path Aryaka VPN Path Internet A custom path (for example: IaaS or a cloud connector) Any traffic that lands on the VPN interface is connected to the VNET0 interface (the internal Interface within the Linux kernel) of KVM, which then forwards the traffic to the ANAP's Aryaka Agent. WAN1 The firewall WAN1 interface is directly associated with the M1 interface of the ANAP. Internet-bound traffic leaving the WAN1 interface is sent to the VNET1 interface (the internal interface within the Linux kernel) of KVM, which is then sent to the ANAP’s M1 interface. WAN2 The firewall WAN2 interface is directly associated with the M2 interface of the ANAP. Similar to WAN1, the internet-bound traffic leaving the WAN2 traffic is sent to the VNET2 interface (the internal interface within the Linux kernel) of KVM, which is then sent to the ANAP’s M2 interface. Management The firewall management interface is directly connected to the SYNC interface of the ANAP using Linux kernel drivers. When the VM is first started to perform the initial firewall configuration, it is recommended that you access the firewall using this interface. This requires that the ANAP's SYNC interface be connected to the network. Palo Alto Networks VNF routing considerations This section describes additional routing considerations for your Palo Alto Networks firewall. Routing between the LAN and the firewall: The Palo Alto Networks VNF firewall allows you to use static or dynamic routing on the LAN side of the network. This routing is transparent to the ANAP's Aryaka Agent and Aryaka does not need to know what type of routing is being done on the LAN side of the firewall. Routing between firewall and Aryaka Agent: When routing traffic from firewall to Aryaka Agent, these routing methods are supported: Static RIP BGP For RIP and BGP, 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. The LAN traffic is first 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. The next section describes how to place a VM into the datapath and the resulting packet flow. Note that for an ANAP deployment at a live site, placing a VM in the datapath results in the following: The LAN interface moves from the Aryaka Agent to the VM. Therefore, the Aryaka Agent must be given a new IP. The BGP peering—if configured between the Aryaka Agent and LAN device—must be moved to be between the Aryaka Agent and the firewall. The firewall may need BGP peering with the LAN device. NAT configurations performed on the Aryaka Agent must migrate to the firewall. It there are Cloud Security Connectors configured, they may need to move to the firewall. Review any perimeter, interior policies, and other advanced configurations to determine if they need to be migrated to the firewall. Packet flow when the Palo Alto Networks VNF is in the datapath Traffic from the LAN to the Aryaka core A client on the LAN network or the distribution switch is configured to have its default gateway as the firewall's VNET01/2 internal interface within the Linux kernel. When a packet reaches the firewall's LAN interface, 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 interface.  If a static route is used, configure the firewall to route this traffic to VNET0's IP. This IP is referred as the ANAP IP in MyAryaka and the firewall's VPN Zone interface IP is referred to as the ANAP Gateway IP. RIP or BGP dynamic routing can be deployed to route traffic. After the packet reaches VNET0 (the vpn Interface within the Linux kernel), it is forwarded to the Aryaka Agent for further 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 up to two WAN interfaces, which are represented as WAN1 and WAN2 in the previous graphic.  Traffic from the LAN reaches the firewall. If the packet is destined to the internet, the firewall is expected to have a route for it. In general, the internet traffic travels the default route. This default route can be configured as follows: Next hop as interface—For any destination, the firewall has the WAN1/2 interface set as the next hop. In this case, VNET1/2 does a proxy ARP for the gateway addresses of the WAN1/2 interface causing the internet-destined packets to land on the respective physical interfaces of the ANAP. Next hop as IP—This IP must be the WAN1/2 gateway address. VNET1/2 does a proxy ARP for these gateway addresses causing the internet-destined packets to land on the respective physical interfaces of the ANAP. In both of these next hop cases, the WAN1/2 interface gateway information must be shared with support@aryaka.com . The return traffic from the internet to the LAN is handled the same way as the forward path. VM health check on standalone ANAP When enabled, the ANAP's Aryaka Agent monitors the reachability of the VM by pinging the IP address configured on the VPN0 (Ethernet1/2) interface of firewall. If the VM does not respond, the Aryaka Agent assumes that the VM is powered down and has not gone through a graceful shutdown. It tries to restart the VM five times before ignoring it. If the VM has gone through a graceful shutdown, the Aryaka Agent does not try to restart the VM. For the health check to work, ICMP must be permitted for the firewall's VPN interface. The Aryaka Agent sources the ping with the gateway address of the firewall's VPN interface. Palo Alto Networks high availability (HA) deployment  This section describes deploying Palo Alto Networks NFV in a high availability configuration on two ANAPs. Active/Passive is the only supported deployment mode for a Palo Alto Networks firewall. The passive ANAP is the standby that is only used when the active ANAP fails for any reason. The active primary firewall always owns the IP. No virtual IP is required to be configured. Prerequisites for a high availability deployment You must satisfy the following requirements to configure Palo Alto Networks firewalls on HA ANAPs: Virtual ANAP redundancy protocol (VARP) must be enabled between the two physical ANAPs deployed in HA. HA ANAPs require that the LAN interfaces must be configured with SYS IP, which is used as a VRRP health checking mechanism between the active and standby ANAPs. The two ANAP's LAN interface IPs and the firewall's LAN interface IP must be in the same subnet.  Both HA firewalls must be running the same PAN OS version  and must be up to date on the application, URL, and threat databases.   Preemption must be disabled on both firewalls. Both HA firewalls must be on the same hardware model or virtual machine model. Both HA firewalls must have  Multi Virtual System Capability either enabled or disabled. When enabled, each firewall requires its own Multiple Virtual System license. Both HA firewalls must have the same type of interfaces: either dedicated HA links, or a combination of the management port and ports that are set to the interface type HA . You must determine the IP address for the HA1 (control) connection between the HA peers. The HA1 IP address for both peers must be on the same subnet if they are directly connected or are connected to the same switch. For firewalls without dedicated HA ports, you can use the management port for the control connection. Using the management port provides a direct communication link between the management planes on each firewall. However, because the management ports are not be directly connected between the peers, you must have a route across your network that connects these two interfaces. If you use Layer 3 as the transport method for the HA2 (data) connection, you must determine the IP address for the HA2 link. Use Layer 3 only if the HA2 connection must communicate over a routed network. The IP subnet for the HA2 links must not overlap with that of the HA1 links or with any other subnet assigned to the data ports on the firewall. Each firewall requires a unique license—they cannot be shared by the firewalls. You must license both firewalls identically. If both firewalls do not have identical licenses, they cannot synchronize configuration information and maintain the parity required for a seamless failover. ANAP internal architecture with Palo Alto Networks HA The following graphic depicts the ANAP's internal architecture for a Palo Alto Networks HA deployment. The graphic includes wiring details for both the HA ANAP and the HA firewall. Note the following: ANAP wiring is for HA using edge-routed mode. WAN port of each of the physical ANAPs connect to each other as shown.  Because HA-1 is using the Management port on the firewall, physical connectivity is wired through the SYNC port on the physical ANAP and is used for Management connectivity. Palo Alto Networks HA states The following table provides a detailed explanation of the Palo Alto Networks HA states. State Description Active The firewall in an active/passive configuration that is currently in use and processing network traffic.  Passive The standby firewall in an active/passive configuration. The passive firewall is ready to become the active firewall with no disruption to the network should the active firewall fail for any reason. Although the passive firewall does not process data traffic, it does perform the following operations: If the passive link state is set to Auto, the passive firewall runs routing protocols, link monitoring, and path state. Pre-negotiations LACP and LLDP if they are enabled.  Synchronizes flow state, runtime objects, and configuration.  Monitors the status of the active firewall using the Hello protocol.  Non-functional Error state due to a data plane failure or a configuration mismatch, for example only one firewall being configured for packet forwarding, VR sync, or QoS sync.  Suspended The device is disabled and cannot process data traffic. In this state, the firewall still processes HA communication, but does not participate in the HA election process. It can not move to a functional HA state without user intervention.  Initial Transient state of a firewall when it is in the process of joining an HA pair. The firewall remains in this state after boot up until it discovers a peer and negotiation begins. After a timeout, the firewall becomes active if the HA negotiation has not started.  Palo Alto Networks HA links The following links are used to communicate by the two firewalls in a high availability deployment. Link Purpose Firewall Interface ANAP Port Control link (HA1) Used to exchange hellos, heartbeats, sync configuration, and HA state information between firewalls in the HA pair. The HA1 control link should only use the firewall's management interface. Management interface SYNC Data link (HA2) Used to sync sessions, forwarding tables, IPSec security associations, and ARP tables between firewalls in the HA pair. Data flow on the HA2 link is always unidirectional (except for the HA2 keep-alive). It flows from the active firewall to the passive firewall. Ethernet1/11 WAN Backup links Provide redundancy for the HA1 and the HA2 links. In-band ports can be used for backup links for both HA1 and HA2 connections when dedicated backup links are not available. Consider the following guidelines when configuring backup HA links:  The IP addresses of the primary and backup HA links must not overlap each other.  HA backup links must be on a different subnet from the primary HA links.  HA1-backup and HA2-backup ports must be configured on separate physical ports. The HA1-backup link uses port 28770 and 28260.  Palo Alto Networks active/passive mode details During the normal working of Palo Alto Networks firewalls, the active firewall manages all the traffic and the passive (standby) firewall synchronizes all the configurations and other details from the active firewall in case of a failover. Both firewalls share and synchronize the configurations. Only Layer-3 deployment in accordance with ANAP is supported on OAN firewalls. Forwarding tables, IPSec security associations, and ARP tables are also synchronized between active and passive firewalls. The device priority can be controlled using the Device Priority settings in the configuration. The higher priority device wins the elections and become the Active state device. Preemption is a method of forcing one firewall in a HA pair to always forward traffic. Preemption must be disabled as part of Palo Alto Networks NFV HA deployment on ANAPs. HA messaging and failover This section describes the messages sent between firewall to confirm connectivity or signal a failover in a high availability implementation. It also describes ANAP-specific concerns for failover scenarios. Firewall messaging Hello and heartbeat polling confirmation messages:  The firewalls use hello messages and heartbeats to verify that the peer firewall is responsive and operational or to determine that a failover is required. Hello messages are sent from one peer to the other at the user-defined  Hello Interval to verify the state of the firewall. The heartbeat is an ICMP ping to the HA peer over the control link. The peer responds to the ping to establish that the firewalls are connected and responsive. By default, the interval for the heartbeat is 1000 milliseconds. A ping is sent every 1000 milliseconds and if there are three consecutive heartbeat losses, a failover occurs. Link monitoring: Note: We recommend you avoid using this failover mechanism (that is, disable the feature). The reason being, if the ANAP device interfaces go down, the VM interfaces have no built-in mechanism to alert them of the failure, which results in the following mixed-mode scenario: Firewall 1 ( Active ) – ANAP 1 ( Standby) Firewall 2 (Standby ) – ANAP 2 ( Active ) Instead, you can monitor different IPs using path monitoring as described in the next section. Path monitoring:  Monitors the full path through the network to mission-critical IP addresses. ICMP pings are used to verify the reachability of the IP addresses. The default ping interval is 200ms. An IP address is considered unreachable when ten consecutive pings (the default value) fail, and a firewall failure is triggered when any or  all of  the IP addresses monitored become unreachable. By default, when any one of the IP addresses is unreachable, the firewall changes to the non-functional state to indicate a failure of a monitored object. Note: In this path monitoring case, the ANAP monitors the VM’s Ethernet1/2 (VPN) status and updates its role based on the response. The expected response is Enabled  when the VM is in datapath.                 ANAP failover Without VNF, ANAP failover can only be triggered by monitoring VARP hello messages. With VNF and with the firewalls in datapath, in addition to VARP help messages, VM path monitoring can trigger a failover. Aryaka Agent stops path monitoring when the VNF is not in the datapath. Path monitoring failover scenarios The following example scenarios assume the following HA firewall configuration:  ANAP 1 and Palo Alto Networks VNF 1 firewall: Active ANAP 2 and Palo Alto Networks VNF 2 firewall: Standby Scenario 1: With path monitoring enabled, the VNF 1 firewall on ANAP 1 goes down due to an internal failure. This internal failure triggers a failover between the active VNF 1 firewall and the standby VNF 2 firewall on ANAP 2, resulting in ANAP 2 and VNF 2 becoming active. The VNF firewall check fails on VNF 1, resulting in it withdrawing the IP from its VPN interface on ANAP 1. This causes the Aryaka Agent path monitoring on ANAP 1 to fail.  The Aryaka Agent services also failover to ANAP 2.   Scenario 2: With path monitoring enabled, the Aryaka Agent fails on ANAP 1. This failure causes the VARP hello messages to also fail, resulting in the Aryaka Agent on ANAP 2 becoming active. The ANAP IP on the VPN Interface is withdrawn. The path monitoring check fails on the VNF 1 firewall on ANAP 1, resulting in a failover to VNF 2 and resumption of services on ANAP 2 with VNF 2 in the datapath. Restarting HA ANAPs and firewalls Consider the following when you have to restart a failed HA ANAP or firewall: When an active firewall is restarted, it triggers a failover to the passive firewall and there is a service downtime up to five minutes for the passive firewall and ANAP to reboot and become live. To avoid this, we recommended doing a graceful failover before restarting the active firewall. When rebooting the VM, you must disable the Firewall Path Monitoring feature until the passive firewall is placed again in datapath on the ANAP. Security Note:  On the Aryaka’s Agent’s LAN interface IP, the VARP messages sent between the active and standby ANAPs are bypassed by the VNF firewall and must be configured on the agent to be accepted only from the respective IPs.  VM health check in HA deployments When enabled, the ANAP's Aryaka Agent monitors the reachability of the VM by pinging the IP address configured on the firewall's VPN0 (Ethernet1/2) interface. If the VM does not respond, the Aryaka Agent assumes that the VM is powered down and has not gone through a graceful shutdown. It tries to restart the VM five times before ignoring it.  If the VM has gone through a graceful shutdown, the Aryaka Agent does not try to restart the VM. For the health check to work, ICMP must be allowed for the VPN interface of the firewall. The Aryaka Agent will source the ping with the gateway address of VPN interface of the firewall. HA FAQ Q: What happens when both VMs are in an active state (due to heartbeat failures) but not the two ANAPs? The system remains in this state (active/active) until someone manually intervenes or the communication link between both VMs comes back. There may be a data black hole  until the issue is resolved. Because only the active ANAP monitors state of VM, it gets a response for path monitor messages so no ANAP failover occurs. If this is a concern, you can add a path monitor on the standby ANAP to detect the state of the standby VM. Once standby ANAP starts receiving responses from the VM, if the ANAP's role does not change, the ANAP sends an alert. Q: What happens when both ANAPs are in active state (due to heartbeat failures) but not the two VMs? The system remains in this state (active/active) until someone manually intervenes or the communication link between both ANAPs comes back. There may be a data black hole  until the issue is resolved. Migration strategy and timeline This section includes a suggested high-level migration strategy and phased timeline. Aryaka offers the timelines, deliverables, and strategies outlined in this section as a suggestion based on successful migrations in the past. Every migration is different and the planning and strategy will also differ. Again, this is offered as a general procedure to consider while you are planning your migration to Palo Alto Networks NFV. Greenfield and Brownfield Strategies (Phase II)—Is an overview of the suggested steps for deploying a new or preexisting site for an existing or prospective customer. VNF/Management—It is customer's responsibility to establish or obtain selection criteria, licenses, procurement, Professional Services engagement, security design, policy design, documentation, and perform the migration. Aryaka Support engagement begins after the site is wired, configured, and ready to be provisioned (ANAP+Services). In this topic Related topics Manage virtual machines ANAP configuration - Edge Routed Mode VM-Series Deployment Guide ( paloaltonetworks.com ) High Availability (PAN-OS Administrator's Guide paloaltonetworks.com )