End-of-Life (EoL)
To meet the security challenges in the software-defined data center, the NSX Manager, ESXi servers and Panorama work harmoniously to automate the deployment of the VM-Series firewall.
1. Register the Palo Alto Networks NGFW service —The first step is to register the Palo Alto Networks NGFW as a service on the NSX Manager. The registration process uses the NetX management plane API to enable bi-directional communication between Panorama and the NSX Manager. Panorama is configured with the IP address and access credentials to initiate a connection and register the Palo Alto Networks NGFW service on the NSX Manager. The service definition includes the URL for accessing the VM-Series base image that is required to deploy the VM-Series NSX edition firewall, the authorization code for retrieving the license and the device group and template to which the VM-Series firewalls will belong. The NSX manager uses this management plane connection to share updates on the changes in the virtual environment with Panorama.
2. Deploy the VM-Series automatically from NSX —The NSX Manager collects the VM-Series base image from the URL specified during registration and installs an instance of the VM-Series firewall on each ESXi host in the ESXi cluster. From a static management IP pool or a DHCP service (that you define on the NSX Manager), a management IP address is assigned to the VM-Series firewall and the Panorama IP address is provided to the firewall. When the firewall boots up, the NetX dataplane integration API connects the VM-Series firewall to the hypervisor so that it can receive traffic from the vSwitch.
3. Establish communication between the VM-Series firewall and Panorama : The VM-Series firewall then initiates a connection to Panorama to obtain its license. Panorama retrieves the license from the update server and pushes it to the firewall. The VM-Series firewall receives the license (VM-1000-HV) and reboots with a valid serial number.
If your Panorama is offline, which means that it does not have direct Internet access to retrieve the licenses and push them to the firewalls, you must manually license each firewall. When Panorama does not have internet access (Offline), you must add the serial number of the firewall to Panorama so that it is registered as a managed device, so that you can push the appropriate template and device group settings from Panorama.
4. Install configuration/policy from Panorama to the VM-Series firewall : The VM-Series firewall reconnects with Panorama and provides its serial number. Panorama now adds the firewall to the device group and template that was defined in the service definition and pushes the configuration and policy rules to the firewall. The VM-Series firewall is now available as a security virtual machine that can be further configured to safely enable applications on the network.
5. Push traffic redirection rules from NSX Firewall : On the Service Composer on the NSX Firewall, create security groups and define network introspection rules that specify the guests from which traffic will be steered to the VM-Series firewall. See Integrated Policy Rules for details.
To ensure that traffic from the guests is steered to the VM-Series firewall, you must have VMware Tools installed on each guest.If VMware Tools is not installed, the NSX Manager does not know the IP address of the guest and therefore, the traffic cannot be steered to the VM-Series firewall. For more information, see Steer Traffic from Guests that are not Running VMware Tools.
6. Receive real-time updates from NSX Manager : The NSX Manager sends real-time updates on the changes in the virtual environment to Panorama. These updates include information on the security groups and IP addresses of guests that are part of the security group from which traffic is redirected to the VM-Series firewall. See Integrated Policy Rules for details.
7. Use dynamic address groups in policy and push dynamic updates from Panorama to the VM-Series firewalls : On Panorama, use the real-time updates on security groups to create dynamic address groups, bind them to security policies and then push these policies to the VM-Series firewalls. Every VM-Series firewall in the device group will have the same set of policies and is now completely marshaled to secure the SDDC. See Policy Enforcement using Dynamic Address Groups for details.
Integrated Policy Rules
The NSX Firewall and the VM-Series firewall work in concert to enforce security; each provides a set of traffic management rules that are applied to the traffic on each ESXi host. The first set of rules is defined on the NSX Firewall; these rules determine traffic from which guests in the cluster are steered to the VM-Series firewall. The second set of rules (Palo Alto Networks next-generation firewall rules) is defined on Panorama and pushed to the VM-Series firewalls. These are security enforcement rules for the traffic that is steered to the Palo Alto Networks NGFW service. These rules determine how the VM-Series firewall must process—that is allow, deny, inspect, and constrain—the application for enabling it safely on your network.
Rules defined on the NSX Firewall —The rules for directing traffic from the guests on each ESXi host are configured on the NSX Manager. The Service Composer on the NSX Manager allows you to define what kind of security protection, such as firewall rules to be applied to the guests in the ESXi cluster. To define the rules on the NSX Firewall, you must first aggregate the guests into security groups, and then create NSX service composer policies to redirect the traffic from these security groups to the Palo Alto Networks NGFW service and/or the NSX Firewall.
The following diagram illustrates how security groups can be composed of guests across different ESXi hosts within a cluster.
For traffic that needs to be inspected and secured by the VM-Series firewall, the NSX service composer policies allow you to redirect the traffic to the Palo Alto Networks NGFW service and corresponding service profile. This traffic is then steered to the VM-Series firewall and is first processed by the VM-Series firewall before it goes to the virtual switch.
Traffic that does not need to be inspected by the VM-Series firewall, for example network data backup or traffic to an internal domain controller, does not need to be redirected to the VM-Series firewall and can be sent to the virtual switch for onward processing.
Rules centrally managed on Panorama and applied by the VM-Series firewall —The next- generation firewall rules are applied by the VM-Series firewall. These rules are centrally defined and managed on Panorama using templates and device groups and pushed to the VM-Series firewalls. The VM-Series firewall then enforces security policy by matching on source or destination IP address—the use of dynamic address groups allows the firewall to populate the members of the groups in real time—and forwards the traffic to the filters on the NSX Firewall.
To understand how the NSX Manager and Panorama stay synchronized with the changes in the SDDC and ensure that the VM-Series firewall consistently enforces policy, see Policy Enforcement using Dynamic Address Groups.
Policy Enforcement using Dynamic Address Groups
Unlike the other versions of the VM-Series firewall, because both virtual wire interfaces (and subinterfaces) belong to the same zone, the NSX edition uses dynamic address groups as the traffic segmentation mechanism. A security policy rule on the VM-Series NSX edition firewall must have the same source and destination zone, therefore to implement different treatment of traffic, you use dynamic address groups as source or destination objects in security policy rules.
Dynamic address groups offer a way to automate the process of referencing source and/or destination addresses within security policies because IP addresses are constantly changing in a data center environment. Unlike static address objects that must be manually updated in configuration and committed whenever there is an address change (addition, deletion, or move), dynamic address groups automatically adapt to changes.
All security groups defined on the NSX Manager are automatically provided as updates to Panorama using the NetX API management plane integration and can be used as filter criteria to create dynamic address groups; the firewall uses the name of the security group (which is a tag) to filter for all the members that belong to a security group. In a ESXi cluster with multiple customers or tenants, the ability to filter security groups for a specific zone (service profile on the NSX Manager) allows you to enforce policy when you have overlapping IP addresses across different security groups in your virtual environment.
If, for example, you have a multi-tier architecture for web applications, on the NSX Manager you create three security groups for the WebFrontEnd servers, Application servers and the Database servers. The NSX Manager updates Panorama with the service profile ID, name of the security group, and the IP address of the guests that are included in each security group.
On Panorama, you can then create three dynamic address groups to match objects that are tagged as Database, Application and WebFrontEnd. Then, in security policy you can use the dynamic address groups as source or destination objects, define the applications that are permitted to traverse these servers, and push the rules to the VM-Series firewalls.
Each time a guest is added or modified in the ESXi cluster or a security group is updated or created, the NSX Manager uses the PAN-OS REST-based XML API to update Panorama with the IP address, and the security group to which the guest belongs. To trace the flow of information, see Dynamic Address Groups—Information Relay from NSX Manager to Panorama.
To ensure that the name of each security group is unique, the vCenter server assigns a Managed Object Reference (MOB) ID to the name you define for the security group. The syntax used to display the name of a security group on Panorama is serviceprofileid-specified_name-securitygroup-number; for example, serviceprofile13-WebFrontEnd-securitygroup-47.
When Panorama receives the API notification, it verifies/updates the IP address of each guest and the security group and the service profile to which that guest belongs. Then, Panorama pushes these real-time updates to all the firewalls that are included in the device group and notifies device groups in the service manager configuration on Panorama.
On each firewall, all policy rules that reference these dynamic address groups are updated at runtime. Because the firewall matches on the security group tag to determine the members of a dynamic address group, you do not need to modify or update the policy when you make changes in the virtual environment. The firewall matches the tags to find the current members of each dynamic address group and applies the security policy to the source/destination IP address that are included in the group.

Recommended For You