Wireless Access

I have setup a captive portal per the 6.1 user guide for using pefng option. My wireless client will pull an ip address from the controller via the ssid. I am not getting the portal page, nor am I able to ping the controller from my client. Antyhing I can look for in any logs to see what is the issue? Note I configured this manually from the 6.1 user guide.

The first thing you should check is what role your user is in. You can do that with a "show user" or clicking on Clients on the dashboard or on the Monitor page. Then check that user role for your captive portal configuration. It should look something like this 

!
user-role logon
captive-portal "CaptivePortal-cp_prof"
access-list session logon-control
access-list session captiveportal
access-list session vpnlogon
access-list session v6-logon-control
access-list session captiveportal6
!

I am guessing the client is getting the IP address that you think they should, right?

Jenga

yes they are getting the correct ip address

I think you are using the captive portal on ArubaOS with the PEFNG license, if so see the Guest access with ArubaOS App note at,

http://www.arubanetworks.com/pdf/technology/AOS_GuestAcccess-AppNote.pdf.

Make sure your setup has a DNS server, DNS is essential for captive portal to work.

Regards,

Sathya

I do have dns setup. I am from my internal ssid which right now is wide open, able to get to internet. I will go back over this doc and see how I go. Thanks. I

Please check that you are not hitting a known issue where the browser is not allowed to validate the captive-portal certificate. The symptoms are: user receives an IP-address, when pointing your browser to a web-site you see a redirect (the browser shows in the status-bar connecting to securelogin.arubanetworks.com), after about a minute the session times out.

Some background:

What happens is that the captive portal is protected with a SSL certificate, by default this is a built-in certificate in the controller for securelogin.arubanetworks.com. Since recently, this certificate has a so-called 'OCSP' reference. This OCSP reference allows the browser to on-line validate the certificate. Some recent browsers and operating systems do no longer allow SSL-connections when the certificate contains an OCSP server, but the server cannot be contacted to validate the certificate. It will just terminate the connection, without a useful error message.

So what is needed, is that you allow traffic to the OCSP servers of your certificate provider in te logon-role. The OCSP servers can be found when you click on the certificate 'lock' in you browser, and view the details.

When you use the default certificate, which is not really recommended; better use your own domain-name and certificated for the captive portal, the ocsp server from ArubaOS 6.1 is: ocsp.comodoca.com. You need to allow this traffic, even when the user is still unauthenticated by the captive portal.

There are two ways to fix this for the built-in certificate (modify IP and hostnames when you use another certificate with a different CA):

Option 1) QUICK: Permit on IP-basis traffic to ocsp.comodoca.com. Paste the following lines in your config:

ip access-list session logon-control
 any host 91.209.196.169 svc-http  permit
 any host 91.209.196.169 svc-https  permit
 any host 91.199.212.169 svc-http  permit
 any host 91.199.212.169 svc-https  permit
 any host 178.255.83.1 svc-http  permit
 any host 178.255.83.1 svc-https  permit
  

Be warned that the IP-adresses are subject to change without any prior notification. This is in control of the Comodo CA. Check the IP-adressess with nslookup:

C:\Windows\System32>nslookup ocsp.comodoca.com
Non-authoritative answer:

Name: ocsp.comodoca.com
Addresses: 91.209.196.169
178.255.83.1
199.66.201.169

Option 2) PREFERRED: Use the Walled Garden feature, introduced in ArubaOS 6.1. This allows access based on the domain name:

netdestination ocsp.usertrust.com
  name ocsp.usertrust.com
!
aaa authentication captive-portal default
  white-list ocsp.usertrust.com

Make sure that you change 'default' in the before-last line to the captive-portal that you created. When you used the WLAN wizard to create the captive portal, the captive-portal name will be your SSID-name, followed by -cp_prof. If your SSID is Guest, the generated captive-portal profile will be called: Guest-cp_prof. 

Please check the certificate that you are using, because this procedure only applies directly to a Comodo provided certificate, which is the default built-in certificate.

Has anyone else got Mozilla complaining about aus2.mozilla.org SSL sertificate when trying to log into Captive Portal? It seems that atleast some mozilla browsers try to check https://aus[x].mozilla.org before letting https browsing. In this case Captive Portal tries to redirect it to logon page thus causing error warning about man-in-the-middle attack and user gets nowhere. 

---

@obi wrote:

Has anyone else got Mozilla complaining about aus2.mozilla.org SSL sertificate when trying to log into Captive Portal? It seems that atleast some mozilla browsers try to check https://aus[x].mozilla.org before letting https browsing. In this case Captive Portal tries to redirect it to logon page thus causing error warning about man-in-the-middle attack and user gets nowhere. 

---

That is the URL that the browser uses to check for software updates.

So should it go like this?

netdestination aus2.mozilla.org
name aus2.mozilla.org
!
aaa authentication captive-portal "DiipaDaapa_Guest-cp_prof"
   redirect-pause 2
   no user-logon
   guest-logon
   login-page "/upload/custom/DiipaDaapa..."
   white-list "aus2.mozilla.org"
!

 Users still get the same error

did you configure a dns server, domain and name resolution for your controlller?

config t

ip domain lookup
ip domain-name test.com
!
ip name-server 8.8.8.8
ip name-server 4.2.2.2

did you configure a dns server, domain and name resolution for your controlller?
 
config t
ip domain lookup
ip domain-name test.com
!
ip name-server 8.8.8.8
ip name-server 4.2.2.2

No I didnt have these. I added them, but problem persist. Though CLI said that I may have to reboot controller to make these settings effect. DNS resolving from cli worked. 

Thanks for all the responses. I have 2 controllers and am going to take my other one and config it up. It is still on 6.1.2.5 and I was seeing some things missing in the one I was working on at 6.1.2.6. I will post back on what I find.

Ok got it all working now. Once I did the factory reset on the controller and reconfigured all from scratch, all is good.