This document covers the API integration between the Nile Access Service and Palo Alto Networks (PAN) Next Generation Firewalls (NGFW) to provide secure campus networks through dynamic and granular segmentation. The Nile Service Block (NSB) inside the Nile Access Service communicates with PAN‑OS® through XML API calls to provide the NGFW with mappings of client IP addresses to their dot1x user identity and group. The dynamic exchanges enable organizations to apply granular segmentation policies based on the organization security strategies.



The screenshots below provide examples of the Enforcement Policy and associated Profiles necessary to display the ‘Filter-ID’ attribute returned by ClearPass. It is based on the Active Directory ‘memberOf’ attribute:

The screenshots below provide examples of the Enforcement Policy and associated Profiles necessary to display the ‘Filter-ID’ attribute returned by ClearPass. It is based on the Active Directory ‘memberOf’ attribute: Enforcement Policy

To create an administrator account, there are 2 steps that must be followed:



Tags are identifiers that can be used to create Dynamic Address Groups. PAN‑OS® utilizes those groups to form tag-based security policies.

For the API integration to work, Tags and Dynamic Address Groups are required. .The Staff and Student Group seen below illustrate how to create Tags. The Tags will be mapped with the user group information sent by the NSB. Subsequently, those two tags are used to configure two PAN-OS® dynamic Address Groups: Staff-role and Student-role.





This guide assumes that the Nile NSB is connected to the Palo Alto Networks firewall through two ports that are both assigned to a newly created security zone called NSB.



To illustrate an example usage of security policies based on the Dynamic Address Groups created in the previous section, two security policies are created to allow all traffic matching the ‘Staff’ Tag, and deny access to the ‘wargaming.net’ and ‘traceroute’ for traffic matching the ‘Student’ Tag:

Since the NSB connects to the PAN firewall through two Equal Cost Multi-Path (ECMP) interfaces, it is recommended to configure a loopback IP address that the NSB can use to connect to the firewall, no matter which interface the XML API traffic flows through.

For illustration purposes, the following loopback setting is shown below:



The following screenshots shows an example on how to accomplish that on the Nile Portal:

DHCP - Set the DHCP Server and Subnets for the user groups.

Authentication - Set RADIUS server parameters.

Segments – Map the DHCP server and authentication method to the user segment

Wireless – Set up the SSID and attach user segment(s)

Now Validate the integration. The validation steps below show what to look for when validating asuccessful dot1x authentication, returning the correct user group/tag through the ‘Filter-id’ attribute from ClearPass Policy Manager.

Validate that the RADIUS server has assigned the appropriate role with the correct “FilterId’. The example below demonstrates ClearPass assigned the correct role to ‘staff1’ through the returned attribute ‘Filter-Id’ with the value ‘staff1’:

A second validation for the user ‘staff1’ is shown below:

Validate that the RADIUS server has assigned the appropriate role with the correct “FilterId’. The example below demonstrates ClearPass assigned the correct role to ‘student1’ through the returned attribute ‘Filter-Id’ with the value ‘Student’:

A second validation for the user ‘student1’ is shown below:

Inside the PAN management dashboard, validate that there is correct mapping between IP and User-ID. The image below demonstrates the correct mapping between the users ‘student1’ and ‘staff1’ to their respective IP addresses 172.16.14.14 and 172.16.14.15:

Inside the PAN management dashboard, validate that there is correct mapping between IP addresses and tags. The image below demonstrates the correct mapping betweenIP addresses to their respective tags:



Inside the PAN management dashboard, validate that traffic logs are available with the right flow. The image below demonstrates that security policies created did enforce as intended. The traffic log shows that ‘wargaming.net’ and ‘traceroute’ were denied for the user ‘student1’ with IP address 172.16.14.14, when it was allowed for user ‘staff1’ with IP address 172.16.14.15:



NOTE