ISE 3.2 Sponsor Guest Portal and multiple PSNs - Static target

[mhm_ameen]

Hi, 

we have ISE 3.2 with two PSN and we want to have guest redundancy.  we created auth policy and auth profile for 1st PSN and guest portal working perfectly, now in case PSN 1 is down we want PSN2 to handle the traffic, searching old post here for ISE 2.4 there was attribute called "Network Access:ISE Host Name " where you will create two auth policy and auth profile one for each psn. in version 3.2 this attribute not there i tried this attribute "Network Access·NetworkDeviceName" but for sure it's wrong because after add this attribute even PSN 1 guest not working.

note:  we are using Static IP/Host name/FQDN option so for example PSN1 : 10.20.1.110 and PSN2: 10.20.1.111

Network Access:ISE Host Name  

[Ruben Cocheno · Accepted solution]

@mhm_ameen 

For this case, you will need to configure separate authorization policy rules and authorization profiles. Each profile will point to specific PSN using unique FQDNs.  The policy rule can then set condition IF ISE Server = PSN1, then AuthZ Profile = CWA-PSN1, and so on.  The PSN portal certificate would need to have all FQDNs in the certificate SAN or else use wildcard certs to avoid cert warnings on client.  The same FQDN cannot be used by all PSNs as ultimately you require DNS resolution to a real IP address, and this must be deterministic to point to the correct PSN.  However, you could then have something like secure1.public.com, secure2.public.com.

If end goal is to use a specific FQDN, then I would recommend using dynamic URL and interface aliases ('ip host' command on the portal interface) to set the desired FQDN instead of adding complexity through static assignment.

[mhm_ameen]

thx for support, would you please provide exact auth policy to use , i mean exact attribute for what you mentioned " set condition IF ISE Server = PSN1"  i didn't find this condition 

[Greg Gibbs]

The Condition you are looking for is defined in the Authorization Policy.

Example:

You should also use the static FQDN in your AuthZ Profile rather then the IP address. Using the IP address for the redirect will most likely cause the client browser to throw a certificate error.