Security

I have read through multiple threads on the subject of OCSP but am not able to resolve the issue I am having.

Symptoms: on my captive portal SSID, apple laptops never get redirected, safari/chrome just sit forever loading/not doing anything.

On windows i can create a problem with firefox by asking it to vaklidate the cert and treat as it invalid if it fails.

Chrome on windows works fine.

Firefox displays an error message: 
The OCSP server experienced an internal error.
(Error code: sec_error_ocsp_server_error)

from my not yet authenticated windows laptop and apple laptops I can ping the ocsp/crl servers:
crl.globalsign.com
ocsp2.globalsign.com

My masters and locals running 6.2.1.2 are configured with a whitelist on the captive portal to allow the connection to the servers and are configured for dns lookups.  The master IP addresses that the captive portal runs on are not internet accessible.

Looknig at the CLI

show datapath session table <myIP>

show datapath session ipv6 table <myIP>

The apple laptop when pinging the CRL server shows the CRL in the table (ipv4)

The apple laptop when opening any webpage does not show the CRL ip address in the table (ipv4 or ipv6),  the link local of the apple laptop shows in the user table but it's global ipv6 address does not.

the windows laptop when pinging the crl shows up in the ipv6 CRL table 

the windows laptop also shows up in the ipv6 CRL table when trying to open the captive portal

netdestination globalsign_crl_ocsp
name ocsp2.globalsign.com
name crl.globalsign.com
!

aaa authentication captive-portal guest
white-list globalsign_crl_ocsp
!

ip domain-name <mydomain>
ip domain lookup
ip name-server <ip>
ip name-server <ip>
ip name-server <ip>

Windows laptop

=================

<winlap-edited>:701:572:37cc:9c97:91de 2400:cb00:2048:1::6ca2:e807 6 56195 80 0 0 0 1 tunnel 15 5 5 666 FNC
<winlap-edited>:701:572:37cc:9c97:91de 2400:cb00:2048:1::6ca2:e807 6 56193 80 0 0 0 1 tunnel 15 5 5 666 FNC
<winlap-edited>:701:572:37cc:9c97:91de 2400:cb00:2048:1::6ca2:e807 6 56191 80 0 0 0 1 tunnel 15 5 5 666 FNC
<winlap-edited>:701:572:37cc:9c97:91de 2400:cb00:2048:1::6ca2:e807 6 56187 80 0 0 0 1 tunnel 15 f 0 0 FNC
<winlap-edited>:701:572:37cc:9c97:91de 2400:cb00:2048:1::6ca2:e807 6 56186 80 0 0 0 1 tunnel 15 f 0 0 FNC
<winlap-edited>:701:572:37cc:9c97:91de 2400:cb00:2048:1::6ca2:e807 6 56184 80 0 0 0 1 tunnel 15 f 0 0 FNC
<winlap-edited>:701:572:37cc:9c97:91de 2400:cb00:2048:1::6ca2:e807 6 56182 80 0 0 0 1 tunnel 15 f 0 0 FNC
<controller>:8eca:402::4 <winlap-edited>:701:572:37cc:9c97:91de 6 8081 56194 0 0 0 0 local 3 1 323 FDC
<controller>:8eca:402::4 <winlap-edited>:701:572:37cc:9c97:91de 6 8081 56201 0 0 0 0 tunnel 15 1 6 2081 S
<controller>:8eca:402::4 <winlap-edited>:701:572:37cc:9c97:91de 6 8081 56192 0 0 0 0 local 2 0 0 FDYC

================

Does anyone have a suggestion on what I can look at?

I been experiencing the same issue , and did the following 

netdestination OCSP-DEST-B
  host 199.7.50.72
  host 199.7.51.72
  host 199.7.52.72
  host 199.7.54.72
  host 199.7.55.72
  host 199.7.57.72
  host 199.7.59.72
  host 199.7.71.72
  host 74.125.226.239
  host 199.7.48.72
  host 91.209.196.169
  host 199.66.201.169
  host 174.133.236.131
  host 174.133.251.251
  host 208.77.208.79
  host 208.77.208.82
  host 208.116.13.251
  host 208.116.18.83
  host 64.150.188.27
  host 64.150.190.19
  host 65.98.24.187
  host 69.175.66.203
  host 69.175.66.219
  name ocsp.thawte.com
  name .courier-push-apple.com.akadns.net
  network 17.172.0.0 255.255.0.0

netdestination APPLE-DEST-B
  name .apple.com

ip access-list session ALLOW-OCSP-ACL-B
  user   alias OCSP-DEST-B svc-https  permit
  user   alias OCSP-DEST-B svc-http  permit
  user   alias APPLE-DEST-B svc-http  permit
  user   alias APPLE-DEST-B svc-https  permit

Add these two access list to the top in your captive portal user-role

I noticed that the Macpro devices for some reason need to reach the 17.172.0.0/24 - using 443 when I opened wiredshark.

See if this helps.

I was able to get it to work on Chrome and Firefox ...Still need to do more testing on Safari since its a bit slow to load the page.

I am running the same AOS code as you

I too ran into a similar issue.   We're running 6.1.3.7.  

I added the a few IPs for thawte / verisign as gathered from a simple query.  I'll need to try the name type Victor pointed out. 

Here is what my netdestination list looks like.  I added the last 5 hosts & it appears as if things are well.  

(master) #show netdestination ocsp-ips
ocsp-ips
--------
Position Type IP addr Mask-Len/Range
-------- ---- ------- --------------
1 host 65.98.24.187 32
2 host 64.150.190.19 32
3 host 64.150.188.27 32
4 host 208.116.18.83 32
5 host 208.116.13.251 32
6 host 208.77.208.82 32
7 host 208.77.208.79 32
8 host 174.133.251.251 32
9 host 174.133.239.131 32
10 host 69.175.66.219 32
11 host 69.175.66.203 32
12 host 205.234.175.175 32
13 host 178.255.83.1 32
14 host 199.7.51.72 32
15 host 199.7.48.72 32
16 host 199.7.59.72 32
17 host 199.7.52.72 32
18 host 199.7.54.72 32
19 host 199.7.57.72 32 
20 host 199.7.55.72 32

My other issues has more to do w/ finding out just how limited the limited-browser window that 'auto-login' uses on Mac OS X 10.8.x.  

We use Cloudpath's XpressConnect to perform 802.1X auto configuration.  I'm finding that the java applet fails to launch from the 'auto-login' window and I am unable to download the wireless profile when following the manual configuration instructions.  However, the entire process works if I launch Safari or any other full fledged browser, so I'm thinking its an Apple issue.  

I'm curious to try an ACL change to allow the machine to reach Apple's status page, and I believe avoiding the 'auto-login' window from poping up, however additional testing needs to be done to find out just how that will impact other iOS devices.  

--Raf

Thanks Victor

A client had the issue with the captive portal with just safari even if the bypass  option was on.

After adding this rules the clients told me that the problem was fixed

Thanks again!

Cheers

Carlos