--- title: "Check Point NFV" canonical: "https://docs.aryaka.com/space/KNOW/1300234395/Check%20Point%20NFV" format: markdown --- The Aryaka Network Access Point (ANAP) is a physical device that can host a virtual firewall (also known as a network function virtualization (NFV) 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 Check Point CloudGuard Edge NFV hosted on a single ANAP (standalone mode) or a pair of ANAPs (high availability mode). Terminology This document uses the following terms and acronyms. 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.  Multi-Domain Security Management (MDSM)—Check Point's centralized management solution for large-scale, distributed environments with multiple discrete network segments, each with different security requirements. Each domain has its own security policies, network objects, and other related configuration settings.  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). Smart Management Console (SMC)—Check Point's manage UI for managing and monitoring the virtual firewall and other NFVs. Security Management Server (SMS)—Check Point server product used to manage multiple firewalls—including, but not limited to—the two firewalls in a high availability (HA) implementation. 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 Check Point VNF on an ANAP: Aryaka SmartSecure VNF license. Check Point firewall platform subscription (this can be obtained by the customer or Aryaka). Check Point MFS offering (if you are using Aryaka managed firewall service). ANAP hardware model ANAP-2600 or 3000 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 Check Point VNF solution: ANAP device—Physical hardware device that hosts the Check Point 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 firewall policies as per the customer’s security requirements (Check Point MFS only). 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. Provides the Check Point VM license and VM Image as part of the Aryaka MFS service. Additional MFS offerings: Day 1 configuration, logistics, and support. Firewall configuration using the MDSM/SMC central management server systems. Firewall operation. Provides MDSM configuration using the MDSM/SMC interface. Troubleshooting for firewall or MDSM functionality at  support@aryaka.com . Customer’s VNF responsibilities Greenfield configuration (Day 0). Brownfield configuration migration for an existing network and any legacy components. Configuration of security, NAT, interfaces, basic firewall setup, and so on. Firewall migration from an existing vendor to Check Point. Customers that need support with managing any aspect of the NFV as part of the Managed Firewall Service can contact  sales@aryaka.com . MFS responsibilities The following table list the Aryaka and customer responsibilities for customers implementing a Check Point VNF solution if they also contracted the managed firewall service (MFS). VNF Feature Aryaka Customer Image upload   VNF license   Firewall Configuration Migration from previous vendor to Check Point   Initial basic configuration (Day 0)   MDSM/SMC Configuration     Domain and templates     ANAP configuration   VNF troubleshooting   ANAP troubleshooting   Supported NFV VM models  There are two supported Check Point CGEdge models based on the number of CPUs on the host device: CGEdge – 2 CPU CGEdge – 4 CPU Equal Cost Multiple Path (ECMP) functionality is not currently supported for either Check Point CGEdge model. Aryaka-qualified Check Point OS versions Customers are expected to use one of the following Aryaka-specific images that are available on the Check Point download portal: R77.20 R80.20.15 (preferred in general and required for HA implementations) Firewall management options The Check Point virtual firewall can be managed by the following tools and methods: Local GUI—Simplest and easiest way to configure the firewall locally using the UI. For HA implementations, both firewalls must configured using the UI. SMS—Centrally managed server that can be used to manage the firewall configuration. MDSM—Management server which lets a managed service provider (like Aryaka) create multiple domains for each customer and maintain configuration and policies that are specific to each domain. Note: Each domain is considered a single customer with logical separation and managed on the internet (for example, IaaS, cloud, on-premises sites or Aryaka sites). Check Point 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 Dual ISP firewall configuration This section describes additional configuration considerations for customers using two ISPs and a standalone Check Point VNF VM.  The firewall must be configured to use the following routes: The WAN1 interface's next hop must be 169.254.3.1/32 The WAN2 interface's next hop must be 169.254.3.2/32 When configured as described, the Aryaka Agent uses these IPs and the address resolution protocol (ARP) to connect to the firewall IP. This is a Check Point requirement. VNF configuration requirements Consider these requirements while configuring your Check Point 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 must enter the ANAP through its physical LAN port, but needs to be directly forwarded to the firewall VM LAN interface without 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 Check Point must be configured in at least the three following 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. Check Point VNF to ANAP interface mapping This section describes the physical (ANAP) to virtual VNF interface mapping details. Note that even though the Check Point firewall supports up to 11 interfaces, the Aryaka Agent currently supports only five, plus the management interface over WAN port. It is expected that you use these five data interfaces as shown in the following table. Check Point Interface ANAP Physical/Virtual Mapping Purpose LAN1 LAN Incoming data interface (firewall LAN) LAN2 vpn0 VPN traffic routed to the Aryaka network backbone LAN3 WAN1 (M1 - Physical) Traffic routing to M1 LAN4 WAN2 (M2 - Physical) Traffic routing to M2 DMZ WAN/S1/S2 Firewall DMZ WAN SYNC Management Connectivity Check Point firewall interface details This section describes the various Check Point 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. Check Point VNF routing considerations This section describes additional routing considerations for your Check Point firewall. Routing between the LAN and the firewall The Check Point 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 the ANAP's Aryaka Agent, the following 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 firewall 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 then needs to be placed in the datapath. The next section describes the packet flow after the VM is placed into the datapath. 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 Check Point VNF is in the datapath The following graphic depicts the ANAP's internal architecture when the Check Point VM is inserted in the datapath. The sections that follow describe the traffic flow throughout the network. 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 LAN interface IP. 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, it is forwarded to the ANAP's 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. Note: 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. In this topic Related topics Manage virtual machines Check Point ClusterXL Administration Guide  ( checkpoint.com ) Check Point high availability (HA) deployment Check Point ClusterXL is a software-based solution for configuring, deploying, and managing a security firewall cluster and performing load sharing. A ClusterXL security cluster contains multiple, identical firewalls that  enable HA within the Check Point cluster. Check Point requires a synchronization link between the firewalls in cluster. This link is used to pass HA state information and connection details to the other firewalls in the cluster using the Cluster Control Protocol (CCP). Check Point allows users to define the interfaces of a firewall that can participate in cluster. When an interface is part of a cluster, it must have a cluster IP or virtual IP (VIP). The physical interface IP always remains associated to the configured firewall and the VIP moves to the cluster's active firewall. A Check Point HA firewall can be in the following states: Active—Firewall which is processing network traffic. Only one firewall in an HA deployment can be active. Standby—Firewall is not processing any network traffic but is ready to become active if the currently active firewall goes down for any reason. Down—Firewall is not in a state to become active. Prerequisites for a high availability deployment You must satisfy the following requirements to configure Check Point HA 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 of the firewalls in the cluster must have the same operation system version including hotfixes. Both of the systems in the cluster must have identical CPUs because ClusterXL relies on internal timers and calculations to determine internal timeouts based on hardware clock ticks.  Both firewalls must have Multi Virtual System Capability either enabled or disabled. When enabled, each firewall requires its own Multiple Virtual System license. 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. HA deployment requires a public IP for each of the following: ANAP's M1/M2 interface Gateway of M1/M2 interface Firewall's WAN interface Check Point HA interface details  The following table lists Aryaka-specific Check Point firewall interfaces relative to the cluster, and their corresponding IP details. Firewall interface Purpose Cluster Interface IP Cluster IP details (VIP) LAN1 LAN Yes Private IP Private IP in the same subnet as the interface IP LAN2 VPN (traffic routed to Aryaka POP) Yes Private IP Private IP in the same subnet as the interface IP LAN3 WAN1 Yes Private IP Public IP that is used for internet access LAN4 WAN2 Yes Private IP Public IP that is used for internet access LAN10 HA (for SYNC purposes) No Any IP N/A DMZ DMZ Yes Private IP Private IP in the same subnet as the interface IP WAN Management Connectivity No Any IP N/A ANAP internal architecture with Check Point HA The following graphic depicts the ANAP's internal architecture for a Check Point 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. This port is LAN10 on Check Point and used for HA synchronization. SYNC port on the physical ANAPs are repurposed to be used for management connectivity by the firewall UI. VM health check on HA ANAPs When enabled, the ANAP's Aryaka Agent monitors the reachability of the VM by pinging the IP address configured on the VPN0 (LAN2) 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.  ICMP should be permitted for the firewall's VPN interface. The Aryaka Agent sources the ping with the gateway address of the firewall's VPN interface. 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 Check Point. 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—Unless you purchased the managed firewall service (MFS), it is the 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).