Wireless Access

I recenty inherited managementt of a 3400 mobility controller in my new position here and promptly was hit with the  certificate error Nov. 21. In following the support document, i purchased a certificate, installed and the webUI is working great. The  captive portal however is not.

If I preview a portal the portal works fine, no errors. However when a user tries to access the guest network, the address shown isn't the captive portal address. its as though the portal is spoofing the users intended page (see attached), thus throwing more certificate errors.

Nothing has changed in the system except for installing the cert and telling the captive portal and webui to use it. I have poked around a bit and am wondering if I need to have the captive portal fqdn in the URL instead of the defauly "/upload/..." or if I need to check the box "show fqdn" in the captive portal profile.

Any help is appreciated.

Try to go to a regular http page and see if you have the same issue.

Is that as simple as "Use HTTP for authentication" on  the portal profile? Help mentioned "If you use this option, modify the captiveportal policy to allow HTTP traffic.", but not seeing this option anywhere. Thanks.

---

@RAM Admin wrote:

Is that as simple as "Use HTTP for authentication" on  the portal profile? Help mentioned "If you use this option, modify the captiveportal policy to allow HTTP traffic.", but not seeing this option anywhere. Thanks.

---

No.  Have the user go to a page that is only http like www.nytimes.com and see if the user has the same issue.

Thanks. When the user goes to a non-https site, it redirects to https properly without a certificate warning. Sorry for the delay in responding.

Does the fqdn on the certificate resolve to the ip address of the captive portal unterface on the controller?

Can you clarify the the CP interface? Would this be public facing or private facing? Currently the fqdn wifi.theram.com resolves to the public IP in the DNS. Our AP's span 36 locations across the US. If needed I can update the external DNS to point to internal IP.

Currently it resolves to the public IP of the controller.

On the controller, go to the commandline and type "show ip cp-redirect-address".  That will tell you what ip address on the controller the Captive Portal redirects to when users connect.  That should match the ip address that is resolved through the fqdn.  If this address does not match the fqdn address, that could be why you are getting a mismatch.

You are correct, i am getting its private internal IP. Any way to change that redirect address internally, or since its easiest I can just update the DNS record.

You can update the ip address by:

config t
ip cp-redirect-address <that public ip address>

 But...if your guest users are already reaching the internal address and the captive portal is working, you should update the DNS resolution and see if that fixes things first...

If you change the ip cp-redirect-address and your users somehow cannot route to the public address, it will break the captive portal for all users.  It might be safer to try the DNS route first.

Noted, and doing so. Thanks, will report back.

Reports are still that the user is being presented with a certificate error. I will test changing the IP for the CP and report back. I believe there is a section for allowed sites to visit in the CP when un-authorized so I will make that destination allowed as well.

Interesting, the walled garden on the CP won't let me add the domain or the IP to the whitelist. I keep getting:

Unknown netdestination <ip/domain>

---

@RAM Admin wrote:

Interesting, the walled garden on the CP won't let me add the domain or the IP to the whitelist. I keep getting:

 

Unknown netdestination <ip/domain>

---

You marked this as solved...it isn't, is it?

Okay.

for the single controller, the ip cp-redirect-address is a private address, right?  If you get on your guest network and ping the fqdn on the certificate, does it resolve to that private address?

You should not need to use the whitelist.  The whitelist is for external addresses that you want to permit access to prior to authentication.  The ip cp-redirect-address should be taken care of by the captive portal ACL, and would not need to be whitelisted.

If you need this fixed sooner, rather than later, please open a support case in parallel so that they can get the detailed informatoin about your network that we cannot ask for here.

It did resolve to the internal IP address after I changed the public DNS to point to the internal IP but clients were still getting certificate errors.

It has not been resolved, that was me getting click happy on the reply button, removed.

I went ahead and changed the config to use the external IP address. Added it to a permitted destination on the Access Control list and changed the FQDN to resolve to external. Also set all captive portals to use HTTP instead of HTTPS until the cert can be resolved.

I have a test AP ready for any other tips to try to resolve this. Thank for the continued support.

---

@RAM Admin wrote:

It did resolve to the internal IP address after I changed the public DNS to point to the internal IP but clients were still getting certificate errors.

 

It has not been resolved, that was me getting click happy on the reply button, removed.

 

I went ahead and changed the config to use the external IP address. Added it to a permitted destination on the Access Control list and changed the FQDN to resolve to external. Also set all captive portals to use HTTP instead of HTTPS until the cert can be resolved.

 

I have a test AP ready for any other tips to try to resolve this. Thank for the continued support.

---

This will be difficult to figure out unless we have further technical details about your network.  There is also a limit to the technical questions that we can ask here due to privacy, but those questions are also crucial to solving your issue.  Again, please open a case with TAC if you have not already.

Try other browsers (e.g Firefox) to see if you still see the issue or not.