cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1118
Views
0
Helpful
5
Replies

ISE Guest Anchor WLC using Public DNS

UN Minustah
Level 1
Level 1

Hi guys,

I have a similar setup with a guest anchor wlc.

Based on this thread, it seems like the recommended design is to allow tcp/8443 to the psn from the dmz guest vlan.

howon you mentioned the guest user needs access to the guest portal and possibly DNS.

In my scenario, the guest clients are assigned public DNS servers, which don't allow them to resolve the url of the portal.

Does this mean, the clients should be assigned internal DNS servers?

What design does Cisco recommend?

5 Replies 5

hslai
Cisco Employee
Cisco Employee

First of all, I would suggest you to review ISE Guest Access Deployment Guide

Since it seems you would not want the clients to see the the DNS resolutions of internal hosts, it's best to add the guest portal records in the public DNS. Such portals can have a different domain than the DNS domain of the PSNs. For example,

     demo.local -- internal DNS domain

     psn1.demo.local -- internal FQDN for the PSN

     guest.demoTest.net     -- public FQDN for the portal (this requires the authz profile to use static IP/host)

Screen Shot 2018-07-05 at 7.24.15 AM.png

howon
Cisco Employee
Cisco Employee

Just to add to Hsing-Tsu's answer. If the public DNS server you are using is not owned by your organization, then you will not be able to add domain records that your organization do not own. For instance, if your org owns ABC.COM but the ISE node is registered as ABC.ORG domain which you are not owner of then you will not be able to add any records in to the ABC.ORG domain. Also, you won't be able to add any non conforming top-level-domain such as .local. So using the 'Static IP/Host name/FQDN' mentioned would be the best option here. Just make sure to add any FQDN you enter in the box exists in the portal certificate as SAN so the guest users do not get prompted regarding certificate mis-match.

paul
Level 10
Level 10

As has been said using public DNS is common or the desire to obscure the ISE FQDNs is common.  In addition to doing the override of the FQDN you will need to setup an authorization profile and rule for each PSN doing guest authentication.

For example on a two PSN deployment:

Authorization Profiles for Redirection

Wireless_Guest_Redirect_PSN1- redirects the user to the guest portal an overrides the PSN FQDN with guest1.mycompany.com

Wireless_Guest_Redirect_PSN2- redirects the user to the guest portal an overrides the PSN FQDN with guest2.mycompany.com

Redirection Authorization Rule in Policy Set

If Network Access:ISE hostname contains hostname of PSN1 then apply Wireless_Guest_Redirect_PSN1

If Network Access:ISE hostname contains hostname of PSN2 then apply Wireless_Guest_Redirect_PSN2

Thank you guys, these insights are very useful.

As Howon mentioned, the public DNS servers are not owned by our organization.

Also, we have a setup with two PSNs.

I have the following Authorization Policy (see screenshot)

Guest Flow.PNG

But, when I try to connect with an endpoint, it matches the default rule which denies access.

Is it an overkill for the conditions to match the SSID name AND the PSN Hostname?

It's commonly done to match the SSID name and other conditions. As it's not matching for some reason, please try single conditions first.

If you are unable to figure it out, we might need to engage Cisco TAC to troubleshoot further.