We are currently set up with the guest wireless using one of our internal DNS servers. We have an ACL in place to restrict all access from the Guest Wireless other than DNS requests over port 53 to our internal DNS server. Our concern is that even though they don't have access to our internal network, they are able to complete NSlookup requests to our Domain Controller and locate internal IP addresses. The Guest users need to resolve the address to our internal ClearPass Server but once they are authenticated they no longer need to use the internal DNS. Is there a way to allow the Aruba Controller to act as the DNS server for the initial ClearPass Authentication then switch the client over to a public DNS server like 188.8.131.52? Or would it be possible to add a DNS record on the Aruba Controller that can resolve the ClearPass domain name and the clients can use the public DNS server?
Alternatively, if neither of those will work we are planning to install a standalone DNS server that only holds an A record for the ClearPass server then all other requests are forwarded to a public DNS server (184.108.40.206).
How many ClearPass Captive Portal Servers do you have? If you have only one, you can just redirect to that ip address and use a public dns server the whole time.
We have a Publisher/Subscriber setup but they are load balancing an IP so we only have the one ClearPass server. However, we have a publicly signed SSL cert imported for our domain. If they are redirected by IP they will get a certificate error. We need a DNS server to resolve the hostname.domainname.us address so they don't get the cert errors.
You could have solved it by also embedding the ip address into the san of the certificate.
That may or may not work. Take a look at the Certificates 101 Technote here: https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Command/Core_Download/Default.aspx?EntryId=33288
As far as I know, you no longer can issue a signed certificate with embedded IP address (containing a private IP).
I think a cleaner solution is to have an A record for the ClearPass server that is accessible from external public DNS servers..
That is correct, you can not have private IP space as IP in a public certificate. It should be possible for public IPs if these are owned by you, it may not be possible if the IP is owned by the ISP. It's highly uncommon to have IP addresses in a certificate, and also not needed.
With a certificate that has a public host-name as SAN, I have for example cppm.nl.arubalab.com as a public certificate, you can still point to a private IP address, even in public DNS. If you look up cppm.nl.arubalab.com now, you will see that the IP resolves to 192.168.32.16, which is a perfectly valid situation as the certificate is validated during issuing typically against a DNS record or domain owner mail address, and you control the DNS records. Just make sure that you have a CA that can issue certificates with a different validation than connecting to the IP address as that is unreachable for the CA.
When published like this in your external DNS, then you can even use a public DNS service from your provider or the well known other like 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199 or others all the time.
Some people think that you cannot have certificates pointing to private IP spaces, which is a misconception when using a valid public domain name and DNS. You just cannot have them point to a non-public domain name.
Thank you Herman, this is exactly what I needed.
@Herman Robers may I ask you something about a point in your answer?
I´m also dealing with an FQDN which is resolved from a public DNS-Server to a private RFC1918 IP-Address... but a Consulting Engineer told me that it`s illigal and not a typical configuration/solution certainly not in a "productive" Guest Wireless enviroment!
I don´t want to get in any trouble so should I consider to change that concept?
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.