Wireless Access

Hello!

Here is the issue I am faced with:

Strictly with IE9, Captive Portal generates cert error and takes about 60-90 seconds to load. Works perfectly fine with Mozilla. If we fire up the CP with Firefox, it works, then switch to IE9, CP works instantly.

I need to learn how to solve this problem as it is crucial for this customer.

I have already gone and created a Pre-Auth role, and added the following permit rules as I was told this might solve the problem:

Basically this is all the rules in the Pre-Auth role:

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
   any host 149.5.128.169 svc-http  permit
   any host 149.5.128.169 svc-https  permit

Still no luck, seems that nothing has changed. And yes, I moved the dropdown box on my Guest role to ensure that it chooses the right Pre-Auth Role...

Do I need to add additional rules here? Why can't I just get Captive Portal instantly like with IE9? Your fast response is much appreciated.

Hello Jeremy,

welcome to the forum!

First I just want to say that post belongs under  a different board like either "Authentication and Access Control" or "Guest Access".

Then to the technical part.

I assume you have installed a valid public SSL webcertificate on the controller and activated this as Captive Portal Certificate.

Based on the ip-adresses you list I'm assuming this is a Comodo based certificate and in the end use ocsp.comodoca.com to verify the revocation status of the certificates. There is another thread on that here - search for comodo ocsp.

Just to make sure you've done the basics right I'm listing it here.

I would suggest that you create a Destination, create an policy ACL that permits HTTP/HTTPS towards this alias, and then add that to the top of the rule-list for the initial role of your AAA profile (like default profile has logon as initial role).

netdestination "OCSP"
 network 91.209.196.0 255.255.255.0
 network 91.199.212.0 255.255.255.0
 network 178.255.80.0 255.255.255.0
 network 149.5.128.0 255.255.255.0
!

 -> This adds the possible networks Comodo says they use

 -> In GUI you will find this under Stateful Firewall / Destination

ip access-list session "OCSP_ACL"
 alias "user" alias "OCSP" "svc-http" permit
 alias "user" alias "OCSP" "svc-https" permit
!

-> In GUI you will find this in Acces Control/Policies

user-role "logon"
 access-list session "OCSP_ACL" position 1
!

 -> Note! OCSP_ACL have to be in addition to the already existing access lists on the "logon" (or whatever role you use) role like logon-control and captiveportal

 -> In GUI you will find this in Acces Control, edit the Role, and add Firewall Policies

If you have already done this as I've listed the path for OCSP should be open, and no reason why Aruba should be the culprit. 

What error message does IE9 give once it loads? Just a warning that it can't verify the certificate or something else?

Have you tried with another PC or device like iPad? If so - how did that go?

Firefox use it's own Certificate Manager so it might be that Firefox already has the Root certificate in it's trusted root while IE9 doesn't. Tho - with Usertrust or Comodo that seems a bit odd since this should be in trusted root in all Microsoft based units.

Thanks for the response. I wanted to mention, there is no controller. This is Aruba Instant, which is why I posted it in the Instant forum. Sorry about that!

Do I still need to upload a web ssl cert? We normally do this with controller-based installs, but I haven't done this with Instant.

JeremyL,

This is a recently-discovered issue with IE9 and the Captive Portal on Instant.  We are currently working on a fix.

cjoseph,

Thanks for your reply. I have a customer who needs to go live with this project this week, which involves hundreds of students on IE9 laptops trying to connect to the wireless. Is there anything I can do in the meantime with Instant to make this work?

Do you have a Bug ID? I need to get this fixed but Aruba TAC needs a Bug ID...

jsolb,

The only reason I tried adding those IP addresses to a permit rule on the initial logon role is that is what my local SE told me to. I haven't uploaded any custom certificate as it is a low-security deployment. This is Instant, not controller-based. I am not familiar with Comodo.