Security

I have an IAP cluster, using Clearpass as the Radius server. The Captive Portal is on ClearPass Guest.

 

I have 2 services setup for accessing this network: MAC Authentication, and User Authentication with MAC Caching, listed in that order.

 

When a user connect to the Guest network for the first time, they fail MAC Authentication, and are assigned the Captive Portal Profile.

 

At the Captive Portal, you land on the login page, but have a link to go to the self-registration portal. if either a user connects with their AD account at the login, or creates an account to sign in, 2 scenerios occur:

 

1. after selecting login, they receive a DNS error, they cannot reach captiveportal-login.domain.com.

2. They are redirected back to the login page

 

Both scenerios have nothing show up in the Access tracker, outside of their initial MAC Auth failure.

 

The Captive portal profile is set to Clearpass, and the authentication server is set to clearpass and the accounting server is set to Clearpass.

The Guest login page has the correct URL listed for the wildcart cert being used on the IAPs.

 

It's difficult to debug as I'm not seeing the entry in the access tracker.

I'm also able to have the occasional user sign in successfully depending on their device. I just had a user unable to sign in on their laptop, but successfully sign in on their iphone using the same login credentials. MAC authentication works after initial sign in.

 

I've heard a bit about having the pre-auth check enabled in clearpass guest, and have a service associated to it, but lack understanding on what this does.

 

Versions

Clearpass: 6.5.0.71095
IAP: 6.5.0.0-4.3.0.0_56428

AirWave: 4.3.0

 

I'm in deseprate need for help on figuring out this problem. It has been ongoing for a while.

Thank you

 

Did you replace the captive portal certificate in the VC and update the login URL in ClearPass Guest?

Tim, Yes to both. I pushed the cert to all APs in the cluster and the VC. the URL in clearpass guest is correct.

 

*.domain.com is the cert, and url is set to captiveportal-login.domain.com

As an added note, I beleive i've only seen this captive portal issue occur on Windows 10 devices. I don't recall it occuring on anything else.

This just recently started happening or it's been this way from day one ?

One thing you need to consider is opening a TAC and see if a Clearpass upgrade is required since you are running a very early version of 6.5

Get Outlook for iOS

I'm unsure when the issue started, it coudl very well have existed day 1, btu the devices I've tested have consistantly connected, while others have not.

Something that happened just now:
I brought my windows 7 laptop up to a few guests who were unable to sign in from the captive portal. I found my laptop had the same issue. I then came back to my desk and tested again and I signed in successfully. 2 different IAPs on the same cluster.
I rebooted the IAP that was having the problem, and 1 guest could successfully sign in on their laptop, and so was I (I deleted my endpoint first to do the sign in process again), but 2 other guests were still recieving the same issue at the same location. I then had 1 of the guests try to connect on their phone, and they were able to successfully log in, while their comptuer still couldn't.

I've checked the IAPs settings and everything seems to be the same, except the IAP at my desk is set to preffered master (and is the master currently). The same wildcard cert is set as the current CP cert on all IAPs.

It's all very confusing. It could be a version issue since I'm on the early versions for the IAP, Airwave, and Clearpass.

It looks like this issue may be resolved in the instant 6.5.1.0-4.3.1.0 release... but there is a discrepancy in Arubas release notes.

On the 6.5.1.0-4.3.1.0 Notes:
Bug#151119
Symptom: Clients are stuck on the Captive Portal authentication page when they try to use external captive portal over HTTP.The fix ensures that the captive portal authentication is successful. Scenario: This issue was observed on IAPs running Instant 6.5.0.0-4.3.0.0 release and later versions.

On the 6.5.1.0-4.3.1.1 Notes, under issues resolved in previous releases for 6.5.1.0-4.3.1.0:
Bug#151119: 
Symptom: Clients are stuck on the Captive Portal authentication page when they try to use external captive portal over HTTP. The fix ensures that the captive portal authentication is successful.

Scenario: This issue impacted all scenarios where captive portal is used and was observed in all IAPs running a software version prior to Instant 6.5.0.0-4.3.0.0.

One says before  6.5.0, and the other says it effects after 6.5.0
Can anyone confrim which release notes is correct?

The Documentation for the Captive portal Bug has been updated, it effects everything before 6.5.0.0-4.3.0.0. It does not effect 6.5.0.0-4.3.0.0 and later

I've ran some additional tests on multiple IAPs.
I'm able to use TLS authentication and MAC authentication at any IAP in the cluster.

I'm only able to do User authentication with MAC Caching at the virtual controller IAP (and rarely elsewhere). This is the authentication used when signing in at the captive portal.

Self-Registered guest accounts from any access point properly show up in Guest User Repository.
There are Access Tracker entries for MAC authentication at all IAPs, as well as 802.1x EAP-TLS. Only 4 IAPs show User Auth with Mac Caching in Access Tracker, 1 guest user at each, however that's only over a 7 day period, and we generally don't have many guests registering on this portal.

the VC IAP is the only one that is able to consistantly work correctly for User Auth on a captive portal.

 

 

Are you using Dynamic Radius Proxy (DRP) on your Instant APS?

If that's the 'Dynamic proxy' setting under the settings in the VC, then no, I don't have RADIUS or TACACS selected. (snip of setting in Airwave shown below)

I am asking, because if you have dynamic proxy set for radius, all of the radius requests will come from the virtual AP ip address and not the individual ip addresses of the APs.  That would mean that you only need one ip address in your radius server.  That could explain why you have problems with some APs and not others...

If I didn't add them correctly to the radius server (clearpass), wouldn't I have problems on my other SSID/Authentication methods?

Still working on this issue.

I'm only able to consistantly authenticate on the captive portal when I'm connected to the IAP hosting the VC. All other IAPs don't have the user Auth service request show up in the access tracker when signin in at the CP. Access Tracker entries still show up for the Mac Auth service check when initially connecting.

I don't have any DRP set on the IAPs. What could cause only the VC to authenticate with user auth, and the other IAPs to not authenticate on the same service? TLS and MAC auth work on all the IAPs, just User Auth on the CP doesn't.

This is https logins yes?

You're using controller-initiated login method?

And you have installed a wildcard ssl-certificate as the Captive Portal certificate on your IAP/VC?

 

When doing a controller-initiated login basically Clearpass presents a web-page with a form that cause the CLIENT to submit the username/password to a certain URL. When doing https you will need this to be URL with FQDN. That FQDN typically has to be DNS resolvable which normally is bound to a single IP - aka your VC in this case.

 

I suggest you either change the flow to be server-initiated or install a ssl-certificate with FQDN on the IAP. 

• With server-initiated login you no longer involve the IAP in the https authentication process, and only need the ssl-certificate on Clearpass - and can use wildcard cert.
• With a FQDN ssl-cert the IAP's will recognise that FQDN as it's own.

 

It is a secure login using HTTPS

*edit* and is controller initiated

The Wildcard cert is installed as the Captive Portal Certificate on all IAPs/VC.

I tried server-initiated login as you suggested, and I do see the login attemtps appear in the access tracker, however they don't work with my User Auth service, as it is a RADIUS service and the requests now come in as WEBAUTH. 
I'm unsure why this difference occurs when server initiated. Are there entirely different requirements?

Could you help explain further why a FQDN cert may work in place of the wildcard cert? Shouldn't they function similarly when setup correctly?

 

Thank you

Either certificate type will work (as long as you're on 4.3+ for Instant where wildcard support was added).

 

If you use a standard certificate, update the Guest form to reflect the CN of the certificate.

 

If you use a wildcard certificate, update the Guest form to be captiveportal-login.<domain-in-cert>.tld

Guest is already using the correct name for the certificate. captiveportal-login.domain.com. Only the master IAP is able to authenticate against clearpass when on the captive portal. All other IAPs in the cluster do not. They just get redirected back to the CP and no entry in the Access tracker or event viewer appear. All IAPs work for my eap-tls SSID.

 

changing to server initiated has all IAPs have requests go through and logged in access tracker, but using webauth instead of radius, which would mean I may need to change the User auth service for it to work it appears. I'd like to understand why this change occurs, and what else this can impact.

Yep, server-initiated login means you will need a webauth service and do Radius CoA to change the use from pre-auth to a authenticated role.

Now, why do all my IAPs hit clearpass when it is set to Server-initiated login, but when set to controller-intiated login only the Master IAP hits clearpass (using master IAP IP, not VC IP)?

 

Something I found, not sure if this is normal behaviour. show users on the IAP my tests client is connected to is empty, but has 21 clients connected.

show captive-portal also seems to be missing information, with the redirects being blank (but are completed in the GUI):

AP01-02CD-245# show captive-portal

:Captive Portal Configuration
Background Color:3407667
Banner Color :3355647
Decoded Texts :
Banner Text :Welcome to Guest Network
Use Policy :Please read terms and conditions before using Guest Network
Terms of Use :This network is not secure, and use is at your own risk
Internal Captive Portal Redirect URL:
Captive Portal Mode:Acknowledged
Custom Logo :
:External Captive Portal Configuration
Server:localhost
Port :80
URL :/
Authentication Text:Authenticated
External Captive Portal Redirect URL:
Server Fail Through:No
Auto White List :Disable

After doing further troubleshooting with TAC, we've identified the issue is with the communication between the IAPs and the virtual controller.

Based on traces on a slave IAP, we found DNS queries coming through from the client device, and an intermittent DNS response by the Slave IAP. Failed and Success responses were found.
After a failed responce, there was a successful response with the right magic-vlan IP as expected.

Howeverthe client did not initiate the TCP handshake in respect to the slave VLAN IP.

Only after the TCP handshake between client and slave will the client initiate SSL handshake to POST the credentials. As the TCP handshake did not occur, it did not begin the SSL handshake.

 

Any insight to torubleshooting further would be appreciated as I wait for further contact from TAC