CWA design with 2 ISE deployments (Certificates, dns )

[REJR77]

Hello,

I have a question with a 2 ISE nodes setup and Guest portal.

We will use eth1 for guest portal (with private IP).

PSN1: eth1: 192.168.1.10 <=> guestportal1.company.com

PSN2: eth1: 192.168.1.11 <=> guestportal2.company.com

And we will use another fqdn for the guestportal (let's say guestportal.company.com)

Certificate can be: CN=guestportal.company.com with SAN1: guestportal1.company.com and SAN2: guestportal2.company.com

I see in the Authorization Profile that the user will be redirected to

cisco-av-pair = url-redirect=https://ip:port/portal/gateway?sessionId=SessionIdValue&portal=265dc4f0-2e58-11e9-98fb-0050568775a3&action=cwa&type=drw

I understand the "ip" will be replaced by the PSN IP address in charge of the session.

But the user will be redirected to https://192.168.1.10:8443/portal..... and will get a certificate warning (official CA don't allow to sign cert with private IP as far as I know).

As guest won't trust a certificate signed for a private IP address, how can we use fqdn for the guest portal?

I see an option "StaticIP/Hostname/FQDN" in the AuthZ profile, but again if I type : guestportal.company.com I need to resolve to 192.168.1.10 AND 192.168.1.11 and potentially it won't be the ISE that handle the session...

I am a bit lost with this CWA config....

What is the recommanded way to do with the objective that each PSN can potentially handle requests? (without any loadbalancer)

Thank you for clarification :)

[Arne Bier · Accepted solution]

Nice question.

You will need two Authorization Result Profiles - one per PSN

And in each one you specify the FQDN of the PSN that will host the portal page.

In your MAB policy set you will have an Authorization Rule that checks which PSN is currently processing this RADIUS request (ISE Hostname = blah) - and then return the respective Authorization Result for that specific PSN.

Hope that clarifies.

[REJR77]

Hello,

Thank you for the answer.
Nice trick... Use 2 AuthZ Rules. The first one will be used when Session is handled by PSN1 and the second one when PSN2...
So no need to play with "ip alias hostname" in the ISE CLI config?
Regards

[Arne Bier]

It’s the standard practice with two PSN Setup. If you have more PSNs then you need to front them with a load balancer and some clever persistence logic

the alias command is only needed if you have more than one interface on the PSN and you’re not using the host name which is by default associated with gig0 

[Darkmatter]

Apologies to revive this thread, but i've kinda want to accomplish the same.
Is there any documentation available where this been explained clearly, together with all the steps you need to take.

I'm a bit stuck at the creation of the 2 authorization rules. Where or how can i specify in the rule to make the distinction between the 2 different PSN?

[Rob Ingram]

@Darkmatter create one authorisation rule using the condition "Network Access ISE Host Name CONTAINS <PSN 1>" and return the PSN 1 Portal in an authorisation profile.

Create a second authorisation rule using the condition "Network Access ISE Host Name CONTAINS <PSN 2>" and return the PSN 2 Portal in an authorisation profile.

There is an example here, modify to fit your requirements.

[Darkmatter]

Thanks a lot, Rob! This was of great help to get a good overview.

Last question, though: what if you can't use a wildcard certificate? Request a normal cert with both PSN as SAN? How to go about with DNS?

[Rob Ingram]

@Darkmatter as you create two authorisation profiles, define a static FQDN which resolves to the PSN1 FQDN and another authorisation profile for PSN2 FQDN, then use those different authorisation profiles in the authorisation rules. There both PSN's can have a different certificate or the same with multiple SAN entries.

Example:

[Darkmatter]

Last piece of the puzzle is DNS and NAT, how to go about that?

As we want to use a public certificate, the traffic should be NAT'ed to the actual guest portal FQDN's, but it don't directly see how to accomplish this best practice on a 2 node deployment without some kind of load balancer.