This section explains the steps to configure NSX Advanced Load Balancer to load balance RADIUS traffic to Cisco Identity Services Engine (ISE). NSX Advanced Load Balancer uses L4 DataScripts to achieve persistence using various RADIUS attributes and load balance DHCP profiling traffic to the same server as RADIUS.
Knowledge of Cisco ISE and its configuration is required before configuring NSX Advanced Load Balancer to load balance RADIUS traffic to Cisco ISE.
An active/standby SE group with IP routing enabled is required to support the preservation of client IP for the RADIUS virtual service.
As shown in the topology, NSX Advanced Load Balancer is logically in line between the user’s network and the ISE Policy Service nodes (PSN). All traffic to ISE PSNs flow via NSX Advanced Load Balancer load balancers (Service Engines), as well as return traffic from ISE PSNs to users.
An NSX Advanced Load Balancer VIP is configured as a RADIUS server on the network access device (NAD). Once NSX Advanced Load Balancer receives the RADIUS authentication traffic from the users, it is load balanced to one of the ISE PSNs using configured load balancing algorithms. A persistence entry is created using DataScripts which parses the RADIUS requests and creates an entry based on the configured RADIUS attributes. Any subsequent RADIUS authentication traffic or DHCP profile traffic from the same client will be sent to the same server using the persistence entry.
Change of Authorization Source NAT Support
The Cisco-ISE will send a Change of Authorization (CoA) request with the following details:
The source IP of the individual PSN originating the CoA
The destination IP of the NAD
The destination port, UDP 1700 (by default)
The NAD expects the source IP to be that of the configured RADIUS server; in this case, it is the NSX Advanced Load Balancer VIP.
The NAT policy has been configured on NSX Advanced Load Balancer to NAT the source IP of the server to the VIP if the destination port of the packet is UDP 1700.
Follow the below-mentioned steps to configure NSX Advanced Load Balancer for RADIUS load balancing:
Configure DataScript to parse RADIUS and DHCP packets and persistence using required fields.
Configure the health monitor for RADIUS. The SE IP needs to be configured as NAD on the ISE with the same credentials on the ISE and NSX Advanced Load Balancer.
Configure the virtual service and pool.
Attach DataScript to the virtual service.
Configure NAT for CoA and attach to required Service Engine group.
Configuring DataScript to Parse RADIUS/DHCP Traffic
The functionality of the DataScript is explained using a sample DataScript. The DataScript can be modified as per the user's requirements. Refer to the Layer 4 DataScripts for more details on the DataScript function.
The DataScript details are provided in RADIUS-DHCP-HTTPS.
RADIUS requests are parsed, and NAS-IP-ADDRESS, CALLING-STATION-ID, and NAS-PORT-TYPE attributes are noted. If NAS-PORT-TYPE is 19 (wireless clients), then the aging time for the entries is set to 3600. For all other client types (wired/virtual), the aging time is 28800. If a CALLING-STATION-ID is populated in the RADIUS request, then that is used for persistence. If the request does not contain a CALLING-STATION-ID, NAS-IP-ADDRESS is used for persistence.
DHCP packets are parsed and the host populated client-identifier is noted, if any. Client-identifier is expected to be the host MAC address. If the client-identifier is populated, then it will match the persistence entry created for RADIUS using
calling-station-id and will send the DHCP packet to the same PSN as RADIUS. If the client-identifier is not present in the DHCP packet, it will be forwarded using the configured load balancing algorithms to one of the three ISE PSNs.
DataScript also creates persistence entry using
framed-ip-address, if present, in RADIUS accounting packets. Any subsequent HTTPS request from the same client to the VIP will be sent to the same PSN using the source IP of the packet, by matching the
Configuring RADIUS Health Monitoring
Navigate toto configure a RADIUS health monitor to monitor the status of ISE.
Specify the name for the health monitor.
Specify the description for the name given for the health monitor.
Specify the interval frequency in seconds to send health checks to a server.
Specify the receive timeout frequency in seconds to receive a valid response from the server within the receive timeout window. This timeout must be less than the send interval.
Select Type as 'RADIUS' from the drop-down list.
Specify the number of continuous successful health checks before the server is marked up.
Specify the number of continuously failed health checks before the server is marked down.
This field describes the object's replication scope. Check this box to replicate the object across the federation.
If this field is unchecked, then the object is only visible within the Controller cluster and its associated Service Engines.
A single pool needs to be configured for all protocols. The pool members will be ISE-PSN. The default server port should be 1812.
Attach the RADIUS health monitor created to the pool.
In the Advanced tab of the pool, select Disable Port Translation.
Configuring Virtual Service
Configure a virtual service to accept all required RADIUS traffic and DHCP traffic. Also, accept HTTPS traffic and SNMP if required.Note:
The application profile selected should be System-L4-Application with the Preserve Client IP option enabled.
The network profile selected should be System-UDP-Fast-Path.
Configure all required ports for RADIUS and DHCP. For DHCP, use System-UDP-Per-Pkt by overriding the TCP/UDP profile. Use UDP per packet profile as the ISE does not respond to the DHCP packets. If HTTPS is configured, it should be overridden to use the System-TCP-Proxy profile.
Attach the pool configured earlier and click Save.
Configuring and Attaching DataScript to the Virtual Service
The following are the steps to configure and attach the DataScript to the virtual service:
Click the Create button to create a new DataScript.
Scroll down to the VS Datascript Evt L4 Request Event Script section.
The script parses requests from the client towards the server; hence, it is a request event script.
Attach the script to this event.
In the Pools section, select the pool configured for RADIUS and DHCP.
Save the DataScript.
Select required protocol parsers. Select Default-DHCP and Default-Radius in this DataScript.
Attach the DataScript to the VS. Navigate to Save DataScript.and select the configured DataScript. Click
NAT rules are configured as a policy called nat policy via the NSX Advanced Load Balancer CLI and are attached to the Service Engine group. NAT rules are per-VRF. NAT rules match criteria can be from source/dest IP/ranges or source/dest port/ranges.
The action for NAT in the ISE use case is to set the source IP as the virtual service VIP for CoA packets. The ISE sends the CoA packets to UDP port 1700 (by default) to ensure there are match criteria. The nat_ip is the IP, that the source IP of the matched traffic will be translated to. In this case, it is the NSX Advanced Load Balancer VIP of the RADIUS virtual service.
Refer to Configuring NAT on NSX Advanced Load Balancer Service Engine for more details on NAT configuration. It is recommended to use a separate Service Engine group for RADIUS load balancing.
NAT will work only if IP routing is enabled on the SE group, hence all the limitations that are applicable to enable IP routing will apply here. SEs must be in legacy active/standby. Refer to Default Gateway (IP Routing on NSX Advanced Load Balancer SE) for more details.
For RADIUS load balancing with ISE, it is recommended to preserve the client IP, since the ISE sends CoA to the NAD IP which is obtained from the IP header and not the IP from the RADIUS header. If the client IP is not preserved, the ISE will see SE as NAD and CoA will fail. Refer to Preserve Client IP for more details.
NAT will work only for UDP traffic as of release 18.2.5. It will not work for any other traffic (ICMP/TCP).
Forwarding for Non-load Balanced Traffic
Since NSX Advanced Load Balancer SEs are configured with IP routing enabled, any traffic that does not require load balancing and is destined directly to/from the ISE PSN IPs will be routed by the SE from/to network hosts.