We've noticed that the onboarding for linux (ubuntu) & MAC OS X devices doesn't go as planned. When those devices are captured in a restricted vlan, where they can only connect to the CP, they get a TLS error; TLS1.0 & TLS1.1 are no longer supported on their browser (firefox/chrome). If they enable TLS1.0 & TLS1.1 they see the SSL error in attach.Now, just to be sure, CP onboarding sends the onboarding page in TLS1.2, as you can see in see second attach.
The weird thing is that users in this restricted vlan say that it doesn't matter which site they are trying to reach, they get this error. Before implementation of NAC, this was not the case, and it is on multiple sites/users...
To be complete I added a screenshot of the restricted vlan and another screenshot with the ACL on the switch.
We've had this on cisco WS-C2960S-48TS-L with IOS 12.2(55)SE10 & a cisco C9300-24T with IOS 16.08.01a
yes, we did.
To be complete; a shortened version of the switch' config in attach.
We narrowed the issue down a bit, but no solution yet.
We use a restricted vlan for the self-registration. In this vlan we use an acces list:
ip access-list extended Onboard_ACLdeny udp any any eq bootpcdeny udp any any eq bootpsremark ClearPass serversdeny tcp any host ipaddress primarydeny tcp any host ipaddress secondarydeny udp any any eq domainpermit ip any any
Afterwards the users go into this same vlanID, but without the ACL, where they do not have such an TLS error.
Now what we can see on the browser, whenever the ACL is in place, we get no cipher keys (attach1). Without the ACL we get -as expected- a whole bunch of cipher keys (attach2)Now this clearly sends us in the right direction, but what can be the root cause of this?
It took some time to get the right persons/equipment on the right places in these times, but we've found the solution.
Thought it would be interesting for someone encountering the same issue.
The TLS errors combined with the cipher keys we saw earlier were indeed a good indication. We use some old equipment, C2960, C3560, etc, with the recommended IOS from CISCO, which is the12.2(55)SE12.
If you check the version and the used cipher keys, you'll get;
Switch Ports Model SW Version SW Image------ ----- ----- ---------- ----------* 1 52 WS-C3560G-48PS 12.2(55)SE12 C3560-IPBASEK9-M
Configuration register is 0xF
switch#sh ip http client secure statusHTTP secure client ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5 rc4-128-shaHTTP secure client trustpoint:
Modern browsers won't use those cipher keys for some time now. If we upgrade to IOS 15.0(2) we see:
Switch Ports Model SW Version SW Image------ ----- ----- ---------- ----------* 1 52 WS-C3560G-48PS 15.0(2)SE11 C3560-IPBASEK9-M
switch#sh ip http client secure statusHTTP secure client ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5rc4-128-sha aes-128-cbc-sha aes-256-cbc-sha dhe-aes-128-cbc-shadhe-aes-256-cbc-sha
Which includes more recent cipher keys.
We can conclude that our switches intercepts the https session for onboarding, and since the cipher key was not supported on the switch, the complete session failed...
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.