Security

I am having issues with some MAC's and the captive portal.  The computer comes up on the network, but they are not able to pull up the captive portal.  Has anyone seen this issue?

Search the forums for "OCSP"

This is a known issue in Lion 10.7.2.

See this thread for more info (The topic of the thread may sound unrelated but it is relevant... please read the replies of Bruce Stewart in that page):

https://discussions.apple.com/thread/3384801?start=0&tstart=0

If you turn off OCSP certificate checks when using a captive portal it will start working. This setting is in the preference window of the Keychain Utility.

Here is more background info and a possible fix in the controller of you don’t want client turning this off.

Online Certificate Status Protocol (OCSP) - is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 2560 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Configuring a certification authority (CA) to support OCSP responder services includes the following steps:

1. Configure certificate templates and issuance properties for OCSP Response Signing certificates.
2. Configure enrollment permissions for any computers that will be hosting Online Responders.
3. If this is a Windows Server 2003–based CA, enable the OCSP extension in issued certificates.
4. Add the location of the Online Responder or OCSP responder to the authority information access extension on the CA.
5. Enable the OCSP Response Signing certificate template for the CA.

The certificate template used to issue an OCSP Response Signing certificate must contain an extension titled "OCSP No Revocation Checking" and the OCSP Signing application policy. Permissions must also be configured to allow the computer that will host the Online Responder to enroll for this certificate.

See this TechNet article for instructions on setting up an OCSP responder under Windows Server. Note that the Enterprise version of Windows Server is required for OCSP responder - the standard version of the server does not have it.

[edit]AOS Version

Support for OCSP in the controller was delivered as part of ArubaOS 6.1.

[edit]Captive Portal, Firefox, and OCSP

You could be running into an issue where browsers like Firefox attempt to contact an OCSP server, to see if the captive portal certificate is valid and has not been revoked. The OCSP server for that domain is a property of the certificate that you load, and is found in the AIA field of the certificate. Firefox will attempt to contact that server over HTTP or HTTPS to determine if the certificate has been revoked. Because captive portal rules have been configured to capture and redirect HTTP/HTTPS, the check will fail and Firefox will never load the page.

If you turn off OCSP in Firefox (Tools -> Options -> Advanced ->Encryption / Certificates -> Verification) and it works, that means that OCSP is your issue. If you cannot do this for all your clients, you can open up traffic to the OCSP server in your logon role:

For AOS 6.0 and below: Code:

netdestination godaddy

  host 72.167.18.237

  host 72.167.239.239

  host 72.167.239.238

  host 72.167.239.237

  host 72.167.239.236

!

ip access-list session godaddy-crl

  user   alias godaddy svc-http permit

  user   alias godaddy svc-https permit 

!

user-role guest-logon

captive-portal "guest-cp_prof"

session-acl logon-control

session-acl godaddy-crl

session-acl captiveportal

!

Of course, you would use the ip addresses from the DNS name in the OSCP portion of the certificate. http://www.networkworld.com/details/7174.html

Using AOS 6.1 and later, the Walled Garden feature can accomplish the same thing using DNS names. The following example assumes that the OCSP URL embedded in the certificate is http://ocsp.usertrust.com:

Code:

netdestination ocsp.usertrust.com

  name ocsp.usertrust.com

!

aaa authentication captive-portal default

  white-list ocsp.usertrust.com

Another alternative is to not use SSL certificates that contain OCSP URLs. This varies by issuing CAs.

Just a side note:

I tried disabling OCSP checking on my MacBook Air at our site, and that did not resolve this issue. I did have to add both the OCSP and CRL address for our certificate provider (Geotrust) to allow OCSP and CRL prior to CP login.

Even if the OCSP disable worked, it would not work on iOS devices, which suffer from the same issue.

I have a mac 10.6.8 on my desk and I enabled the checking in firefox and am now seeing the same error that I am getting on the 10.7 clients.  I will do some testing and get back to you.

Regards

Our guest access is open and 10.7.x can never connect using the built in browser.  Is this something in the Aruba controller or the client that has to be turned off?

---

@jcameron wrote:

Our guest access is open and 10.7.x can never connect using the built in browser.  Is this something in the Aruba controller or the client that has to be turned off?

---

This is the OCSP and CRL issue. You will need to find out the IP addresses of your certificate provider's OCSP and CRL pages. Then you need to add in those addresses as allowed communication in the default CP role (pre CP auth) that you are using.

Just search the forums for OCSP if you need more help on this topic.

But we are not using any certs on the guest wireless.

So for the Guest Wireless, when the login page does pop up, it is HTTP:// and not HTTPS://  ???

If you run the following command, replacing "default" with the name of your CP Profile, you should see the bold line as "Enabled" instead of "Disabled" if you are not using HTTPS:

(Aruba3200) #show aaa authentication captive-portal default

Captive Portal Authentication Profile "default"
-----------------------------------------------
Parameter Value
--------- -----
Default Role guest
Default Guest Role guest
Server Group default
Redirect Pause 10 sec
User Login Enabled
Guest Login Disabled
Logout popup window Enabled
Use HTTP for authentication Disabled
Logon wait minimum wait 5 sec
Logon wait maximum wait 10 sec
logon wait CPU utilization threshold 60 %
Max Authentication failures 0
Show FQDN Disabled
Use CHAP (non-standard) Disabled
Login page /auth/index.html
Welcome page /auth/welcome.html
Show Welcome Page Yes
Add switch IP address in the redirection URL Disabled
Adding user vlan in redirection URL Disabled
Add a controller interface in the redirection URL N/A
Allow only one active user session Disabled
White List N/A
Black List N/A
Show the acceptable use policy page Disabled

We updated from 5.0.3.3 to 6.1.2

For the Captive portal, I whitelisted oscp.comodo.com which is the issuing authority for the default cert. This made it work on the mac's

Thanks!

I ran into the same issue and added the domain into whietlist. We are good to go now.

I encountered the same problem with MAC OS X 10.8.5   Aruba OS 5.0.4.6.

I resolved the issue shown below:

Controller = Aruba 3400

OS= 5.0.4.6

MAC OS X 10.8.5 12F45, Safari 6.0.5

Default certificate in Aruba 3400 (OS 5.0.4.6) was expired on 11/21/2013.

Therefore, we purchased Verisign Server Certificate, and uploaded the server certificate for Captive Portal.

Yesterday, we experienced a problem.

MAC OS X 10.8.5 12F45, Safari 6.0.5 could not get Captive Portal Login screen.

I researched Airheads and other web, and figure out two requirements to make MAC OS X work for Captive Portal with OS 5.0.4.6.

1. MAC OS X client requires to access us-courier.push-apple.com, cn1.redswoosh.akadns.net, e3191.dscc.akamaiedge.net, and other Apple.com related website PRIOR to the CaptivePortal Login screen.

2. Refer to the Airheads post shown below, purchased server certificate should include intermediate-Trust CA and Root Trust CA, to make MAC OS X work.

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Installing-server-certificate-an...

Actions for 1

I captured a packet trace by selecting MAC OS X laptop by wireless MAC address.

From Controller UI, Monitoring -> Controller -> Clients. Enter the MAC address and click on Search.

Click on the radio button to choose the laptop and click on Packet Capture.

Enter the IP address of target pc (The pc which has Aruba version of Wireshark installed) and match the captured-packet transport UDP Port (Default 5555) with Aruba-Version of Wireshark in the target pc. Click Start to start captured-packet transfer.

On target pc, start Aruba-version of Wireshark with UDP-5555 Interface selected.

(Note: To make above Packet Capture work, you need to add one policy in ap-acl, so that UDP Packet 5555 can go through from AP to Ethernet LAN.

ip access-list session ap-acl
any any svc-gre permit
any any svc-syslog permit
any user svc-snmp permit
user any svc-http permit
user any svc-http-accl permit
user any svc-smb-tcp permit
user any svc-msrpc-tcp permit
user any svc-snmp-trap permit
user any svc-ntp permit
user alias controller svc-ftp permit
any any udp 5555 5556 permit <== Add this policy

What you can see in the Wireshark trace is IEEE 802 and LLC Packets. When LLC Header is attached, Wireshark does not decode IP and TCP Header after the LLC Header. For my case, IP Header (Starts from x'45') is at x'0024' in the packet, and source/destination IP addresses are at x'0030-0033' (Source IP) and x'0034-0037'(Destination IP). For example, if you can read x'0034-0035' as x'0a 0b 0c 0d', the destination IP address is "10.11.12.13".

I created a policy APPLE and added those IP subnets:

ip access-list session APPLE
user network 208.14.0.0 255.255.0.0 svc-http permit
user network 208.73.0.0 255.255.0.0 svc-http permit
user network 208.14.0.0 255.255.0.0 svc-https permit
user network 208.73.0.0 255.255.0.0 svc-https permit
user network 96.17.0.0 255.255.0.0 svc-http permit
user network 96.17.0.0 255.255.0.0 svc-https permit
user network 69.31.0.0 255.255.0.0 svc-http permit
user network 69.31.0.0 255.255.0.0 svc-https permit
user network 23.3.0.0 255.255.0.0 svc-http permit
user network 23.3.0.0 255.255.0.0 svc-https permit
user network 23.195.0.0 255.255.0.0 svc-http permit
user network 23.195.0.0 255.255.0.0 svc-https permit

And apply this APPLE policy in guest-logon as shown below. logon-control assigns DHCP IP Address, thefore I think APPLE policy should be after logon-control and before captiveportal.

user-role guest-logon
captive-portal "default"
session-acl logon-control
session-acl APPLE
session-acl captiveportal

Apply and Save configuration.

Actions for 2

I included Intermediate-CA and Root-Trust CA after the purchased certificate.

The trust structure of the certificate is:

Verisign (Root Trust CA)

verisign class3 Secure Server CA G3 (Intermediate CA)

xxxxx.xxxxx.xxxxxx (Purchased Certificate)

and I placed those three certificate on Wordpad, and saved it with xxxx.cer filename.

-----BEGIN CERTIFICATE-----

<Purchased Certificate>

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

verisign class3 Secure Server CA G3 certificate

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

Verisign certificate

-----END CERTIFICATE-----

On Controller UI screen, Configuration - Management - Certificates, upload certificate shown below:

Certificate name :

Certificate Filename:

Certificate Format PEM

CertificateType ServerCert

After the certificate is uploaded, switch this certificate for CaptivePortal.

With this Action 1 and Action 2, despite of the 5.0.4.6 controller level, Captive portal worked with MAC OS X 10.8.5 12F45 and

Safari 6.0.5.

Where is the whitelist in the gui interface for this?

Hello,

The firewall policy "APPLE" is located at GUI:

Configuration -> Security -> Access Control -> Click on Policies tab (Firewall Policies)

Click on Add to create a new policy APPLE.

The guest-logon policy is located at GUI:

Configuration -> Security -> Access Control -> Click on User Roles tab.

Click Edit for guest-logon, and insert APPLE policy between logon-control and captive portal.

Click Apply on the right bottom of the screen, and click on Save Configuration.