Controllerless Networks

I have a IAP guest SSID working with Clearpass Guest however when I enable HTTPS redirection in Clearpass, clients encounter a redirect loop and are unable to authenticate.

I've also tried sending sending clients direct to httpsby changing the captive portal port to 443 however the IAP fails to use SSL for the connection. You cannot enter a fully qualified captive portal URL in IAP unlike the method used in the regular controllers.

Can IAPs support a https captive portal?

thanks

Have you tried port 80 (just as a test) for the redirection?

Have seen similar scenarios in past versions, and port 80 redirect was the workaround.

JF

So with the https requirement disabled in Guest->Configuration->Authentication, and IAP config set to port 80 I do get the logon page.

If I change the captive portal port in IAP to 443 and a redirect loop on the client.

If I leave the captive portal port setting at 80 then clearpass sends a HTTP 302 to redirect to https and I get a redirect loop on the client.

No I haven't tried 4343, is this a port normally associated with clearpass?

4343 is usually the management access port for Aruba products.

Sounds like a config issue with the certs/public cert...or OSCP check from the client.  

So it's the exact same client and clearpass config being used for a captive portal via a 7210 controller - and that works.

When a client is redirected from an Instant VC we encounter the problem.

In the 7210 you specify a https URL directly. In IAP you don't seem to be able to, so Clearpass Guest has been set to do it via

Configuration->Authentication->Require HTTPS for guest access. When this is unticked, captive portal from the IAP works.

A redirect loop kind of makes sense, since the VC is redirecting any http from the client, and then clearpass tries to redirect the client to https, which is then redirected to http via the VC and so on..

Glad you got out of the woods on this one per the guidance above, and some elbow grease.  nice work!

On to the next one? ;)

JF

Well the issue is still there, I've just been describing the problem in a bit more detail. 

Instant should be able to handle redirection by clearpass as per ArubaOS.

I think you'll find it actually does, it's just the configuration that is a bit of a nuance.

What port are you seeing communicate (if you wireshark) or observe the traffic on to/from the CP ?

JF

80 then 443 and back again.

Part of the issue is that it's not clear how to directly define a https captive portal in Instant. If we could solve that part it may work without redirection. Under the captive portal server you can't a URL, just a hostname or IP. If you enter port 443 then it doesn't try to use SSL, just http over 443.

Do you have a pre-auth role defined for this config? IAP uses tiny-proxy to proxy the request to the exteranl CP, in this case Clearpass. In current versions of IAP code, we don't natively support https captive portals so it it is the webserver that is required to redirect the user to the https site. Also, please try and disable auto-whitelist - pending your code version - it is enabled by default and could cause the loop.

In the forth coming 4.0 release of IAP code, this will be modified for better handling of ECP sites using https.

Thanks , we're not using a pre-auth role and this is on code 6.2.1.0-3.4.0.1_39461.

I can confirm auto whitelisting was enabled. With it disabled we are still encountering the 'redirect loop' in the client browser.

There are 2 critical points to the confining, the IAP using tiny proxy does not support HTTPS directly. As mentioned in previous posts,

the auth server must demand (and rediret the client from port 80 to 443) HTTPS.

In clearpass Guest - > authentication -> Require HTTPS for guest access (set to enable).

The pre auth role must explicitly allow the https:

Example Lab config:

wlan external-captive-portal
 server clearpass-1.test.net
 url "/guest/iap_guest_clearpass.php"
 auth-text ""
 auto-whitelist-disable

wlan access-rule preauth
 index 4
 rule 192.168.17.36 255.255.255.255 match tcp 443 443 permit
 rule 192.168.17.36 255.255.255.255 match tcp 80 80 permit
 rule 192.168.17.26 255.255.255.255 match tcp 443 443 permit
 rule 192.168.17.26 255.255.255.255 match tcp 80 80 permit
 rule 192.168.17.37 255.255.255.255 match udp 53 53 permit
 rule 192.168.17.30 255.255.255.255 match udp 53 53 permit
 rule any any match udp 67 68 permit

In this case, the IAP SSID is configured for "network assigned ip", with no vlan.

If this doesn't work, I'd suggest opening a support case, and we'll look into the issue.

Thanks so the the lack of explicit pre-auth role is what was tripping me up.