cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1655
Views
0
Helpful
6
Replies

ISE CWA Wireless FQDN resolution

firestartest
Level 1
Level 1

I can't get my head round how the URL redirect works based on resolving the name in the certificate.

 

Going off my basic diagram I have an ISE (10.1.1.100) with an identity certificate of CN=ise.company.local.  According to Cisco documentation and some of the Cisco Live 2014 guidelines, it suggests using SAN fields and having the alternative names in there.  So I can have SAN=ise.company.local, ise.company.co.uk, guest.company.co.uk and even 10.1.1.100.

 

However recent articles about how public CAs will issue certificates state that they will no longer support SANs with private IP addresses or internal domain names.


So if a wireless guest user tries to connect to the Internet (www.google.co.uk), DNS resolution to a public DNS is done, then the browser tries a HTTP get to x.x.x.x of google then ISE redirects to either FQDN or IP address.  If its the FQDN and the name is ise.company.local the client will have to use DNS to resolve that name which it cant as its using public DNS.  If its the internal IP then certificates being issued now will not allow that so the secure connection warning will appear.

 

If its a public FQDN - how does the client traffic get routed appropriately?  What I mean is for example if we had guest.company.co.uk within a SAN of a public cert then surely we need to have a public address that resolves to that name?  If its a public address, then when the client uses DNS to resolve guest.company.co.uk and gets back 86.1.1.1 (for example) then the client will try to contact that address.  That address doesn't exist internally so the traffic will be forwarded out the firewall to the Internet.

 

I can't quite understand this crucial bit of the redirect.  Can anyone enlighten me please?

6 Replies 6

jj27
Spotlight
Spotlight

Hi,

Typically you would setup what is known as split DNS on your internal DNS servers.  

 

For example, your internal domain DNS zone is ise.company.local, but you own the company.com external domain. You would create a forward lookup zone in Active Directory that matches the hostname for the ISE nodes/alias exactly - so create a zone called "ise.company.com" or "guest.company.com" and then create a new host (A) record, with the hostname blank, and put in the internal IP address of your ISE nodes. Then, configure your wireless clients to use your internal DNS servers to resolve domain names and it will all work nicely.

Make sense?

Yes makes sense if guests are allowed to use internal DNS servers.  But what if the company will not allow internal use of DNS for guests? Is it a case of having to have a dedicated DNS server on the DMZ for guests?

 

Yes, exactly -  a DNS server on the DMZ.  I have implemented that scenario before.  You would still create the zone the same and use the same internal IP addresses, then configure your DMZ firewall rules to allow communication to ISE on the necessary ports.

I am not 100% certain, but you may also be able to utilize DNS re-write on your firewall, if it is an ASA, to translate  your public IP to the internal IP automatically upon request.

So if I can't use internal DNS, customer doesn't want DMZ DNS server, then i'm left with using public DNS?

This means I need to have a proper public FQDN, publicly resolvable IP address and also have that public address reserved for ISE only (although not in use on the Internet firewall).  Then when the client redirects to guest.company.co.uk the public DNS replies with external IP of 86.1.1.1.  The client then tries to contact 86.1.1.1 which would fail as its an external public address, unless we have a firewall that does DNS rewrite which could change 86.1.1.1 into 10.1.1.100.

Have I got this right?  Thanks for replying btw.

bhose
Level 1
Level 1

Hi,

We have an external IP address that NAT's to the ISE server with an external DNS resolution for the ISE server. The cert then just has the external DNS name.

203.5.1.1 (Our Public IP) --> NAT 172.22.1.1

guest.company.com --> 203.5.1.1

In the ISE AuthZ policy we have the redirect to guest.company.com

Hope this helps

Do the guests sit on a private internal network?