Wireless Guest users traffic in ISE

[siddhesh.parab@orange.com1]

Hello All,

Need your help on below queries

We have 2 ISE nodes in HA (Running ADM/MnT & PSN)

1. which DNS server (Private or public) we should use in ISE for guest users ?? ------> As per my understanding if we use public DNS then our private IPs of ISE will be opned on internet and many security concern. and if we use private DNS then is there any security breach ??

2.If my primary ISE server goes down then will my secondary ISE server sends redirect url to guest users with secondary ISE IP ??---------------> we will create forword & reverse lookup entry, in which we will mention both ISE ips against guest FQDN.  

Thanks in advanced 

[Colby LeMaire]

1.  Use public DNS and include an entry for each of your PSN's.  Like visitor1.orange.com and visitor2.orange.com.

2.  WLC will always go to the first Radius server in the list.  If that one is not responding, then it will failover to the next Radius server.  Which is why you would need two DNS entries.  Each server would also need to have a certificate for the guest portal issued by a third-party so that the guest users don't get certificate warnings.  You would also need to ensure that your firewall allows the guest subnet access to the PSN's IP addresses on your guest portal TCP port (i.e. 8443).

[siddhesh.parab@orange.com1]

Hello Colby,

Thanks for your comment.

1. If we use public DNS then is there any risk associated with it ??  becoz our privates IPs are exposed over public infra.

My plan is to add both PSN ips in private DNS (eg. guest.company.com : 10.0.0.8  & guest.company.com : 10.0.0.10)

Same FQDN with both PSN IPs.

Please suggest 

Thanks in advanced.  

[Colby LeMaire]

Private IP's are not routable over the Internet.  And you cannot get a third-party certificate for a private IP because the third-party will want to verify that you own the IP space.  You need a third-party certificate for the guest portal since you don't have control over the machines that would be connecting and they would not have your own CA certificates in their trusted store.  You don't want certificate warnings to pop up for your guest users.  It isn't a good look for any organization.

[Arne Bier]

Hi siddhesh.parab@orange.com1 

I don't agree with @Colby LeMaire comment about using public DNS for an ISE Guest Portal. It requires registration of two DNS records that are then made available worldwide through the magic of the internet. What for? Why waste money and IP addresses when the guest service is possibly only at one location ? Or in the case of an anchor controller you may have multiple locations, but a single guest VLAN. Then you're looking at NAT'ing a public IP address back to your public IP (ISE) and involving firewalls and a lot of pain.

Here is my simpler suggestion. Use a separate DNS server (Microsoft or Linux based) and have it do conditional forwarding. It's a very simple concept. It has the following rules

resolve guest1.mycompany.com  --> RFC1918 address (e.g. 10.1.1.1)

resolve guest2.mycompany.com  --> RFC1918 address (e.g. 10.1.1.2)

forward everything else to 1.1.1.3 (Cloudflare with Malware protection etc.) -or 8.8.8.8 or Umbrella - knock yourself out.

The above strategy prevents a hacker from resolving any of your internal DNS entries. No public DNS entries required, no firewalls, and best of all ... no NAT.

regarding your second question. The answer has nothing to do with how DNS works .. sorry @Colby LeMaire - the trick is to use two Authorization results, each of which contains a static FQDN - one per PSN. And in your Policy Set you perform an Authorization test to see which PSN is currently processing the MAB request (by using the ISE Hostname condition) - depending on which host is processing the MAB request, you return the appropriate URL to the client. The client does a DNS lookup (to your fancy new DNS conditional forwarder mentioned above) and then the client builds the TCP connection to the correct PSN's web server.

[paul]

Just to add to this thread. Colby's setup is pretty standard and I probably have done it on 50+ customers.  Many of my customers simply put their private IPs in the public DNS space to avoid having to add another DNS server to the mix.  The setup is simple and there is no NATTing required.  Public DNS records:

guest1.mycompany.com -> 10.1.1.1

guest2.mycompany.com -> 10.1.1.2

You are typically paying to host a domain not pay for each record in the domain.  So mycompany.com is already a publicly hosted domain that we are simply adding records to.

As a side note, a setup I have been doing often now is bring those two DNS names above into a DMZ load balancer to provide an extra layer of security:

1. Load balancer and so SSL termination which may remove the need for public certs on the ISE environment.  Most often the customer's DMZ LBs have wildcard certs on them for SSL termination so we don't even have to buy a new cert.
2. The LBs can do URL inspection to ensure the traffic is guest portal traffic by inspection the portal ID variable.
3. The LBs can do host header inspection to direct the traffic to the correct PSN (guest1 goes to PSN1 and guest2 goes to PSN2).
4. The LBs then reencrypt the portal traffic to the ISE PSNs and not to SSL cert validation meaning you can run whatever cert you want for the portal cert.

[siddhesh.parab@orange.com1]

Hello Paul,

How we can do load balancing for guest without LB ??

[Arne Bier]

Interesting approach - I was always of the opinion that putting RFC1918 addresses into public DNS records was poor form, and I assumed that Colby was referring to using public IPs ... hence the comments about cost and NAT etc.. 

Thanks for clearing that up.

[siddhesh.parab@orange.com1]

Hello Arne,

I have found below document. Are you suggesting the same setup ??

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/117620-configure-ISE-00.html#anc3

If yes then in authorization policy section we need to map static ip and when ISE send redirect url then in url it will send an ip address and not FQDN... and if ISE send an IP address then guest can easily know what is the ip of ISE server... dont you think there is risk in that ??

Please correct me if i am wrong 

[Arne Bier]

Hi Siddesh

I would not advocate putting an IP address into a URL ever. You can't include an IP address in the SAN field for publicly signed certificates. Plus - IP addresses in certificates are not cool - IP addresses can change, and we should be using DNS and not IP addresses - get ready for IPv6 etc. etc. That link is quite old.

Instead, use FQDNs and ensure that your DNS is able to resolve the FQDNs to A Records for the actual IP addresses of the PSNs.

The trick with handling two PSN Guest Portals is as follows:

Create two Authorization Profiles - one for each PSN that is being used to host a Guest Portal.

e.g.

Result 1: CWA_ISE1 - redirect to static FQDN: ise01.mycompany.com

Result 2: CWA_ISE2 - redirect to static FQDN: ise02.mycompany.com

Create an Authorization Rule in your MAB Policy Set that checks the ISE Host Name - depending on the Host Name (the hostname is defined when you build the ISE node - check the Deployment screen or show run on the CLI), you return the appropriate Authorization Result that you created above. This ensures that the client will use the URL of the PSN that is processing the MAB request. 

example below:

[siddhesh.parab@orange.com1 · Accepted solution]

Hello Arne,

Completly agreed with you. just correct me if i am wrong.

in authorization rule, we need to create 2 rule as below. 

authorization rule 01:  Network access : ISE host name :- ISE01  ------> Authorization profile 01 (CWA_ISE1)

authorization rule 02: Network access : ISE host name :- ISE02  ------> Authorization profile 02 (CWA_ISE2) 

means suppose if my 1st ISE server goes down then my WLC/Switch will try to reach to 2nd ISE server.

so 2nd ISE server will hit "authorization rule 02" and send redirect url with fqdn: ise02.mycompany.com and DNS server can resolve it.

Is my understanding is correct ??

[Arne Bier]

Your understanding is correct. The reason we have to build the Policy Sets this way, is because each PSN has the same programming from the Master Admin Node. Imagine if we had to configure the same Policy Sets into each PSN? What a nightmare and fraught with inconsistencies. But on the other hand, one config applied to all PSNs means that we lose individuality (if required), and therefore we need to test which PSN is currently processing the request. BTW, this use case we're discussing applies for two PSN nodes (or two ISE nodes that are running Portals). If you have more than two PSNs then you should consider using a load balancer, and then your Policy Sets will use a common FQDN (e.g. guest.mycompany.com) instead of individual PSN FQDNs. The Load Balancer becomes a central point that sends the MAB to one of the PSNs (load balancing algorithm) and then also maintains a session persistence table to know which PSN needs to handle the client's portal connection. 

I guess you could have a 3 or 4 PSN setup and then configure each RADIUS server into your WLC/Switch

[siddhesh.parab@orange.com1]

Hello Arne,

Could you please confirm if this applies in 1 deployment with two nodes in HA ??

Thank in advanced