Solved

External CWP with mac-auth and CWP bypass. Users still have to open CWP even though user profile is allowall.


I am trying to setup an external captive portal but with mac-auth. I have a user profile for users that have already registered (allowall) and set this in 'apply different user profile for different groups based on Filter-ID'.

When the user does the mac-auth, I see it with the allowall profile, but I still get redirected to the captive portal.

User profile application sequence is set to mac-auth > CWP > SSID.

Has anyone else setup something like this before.

icon

Best answer by nlowe 11 December 2018, 13:59

Hi all,

 

I think you just need to configure the fallback-to-ecwp command via supplemental CLI.

 

I double checked HiveOS 6.5r10 and this is supported there.

 

You will need to find the name of the security-object by reviewing the show run output.

 

show cmds | include fallback-to-ecwp

 

security-object <string> security additional-auth-method mac-based-auth fallback-to-ecwp

 

show version

 

Aerohive Networks, Inc.

Copyright (c) 2006-2018

 

Version: HiveOS 6.5r10 build-205308

Build time: Wed Aug 8 10:22:25 UTC 2018

Build cookie: 1808080322-205308

Platform: HiveAP330

Bootloader ver: v1.0.3.4d

TPM ver: v1.2.35.8

Uptime: 13 weeks, 3 days, 13 hours, 44 minutes, 32 seconds

 

Thanks,

 

Nick

View original

20 replies

From what I can tell you have this set up correctly, I think we'd need a support case to start digging in to why this isn't working for you. Would you be able to open a support case for this issue? If you haven't purchased support, please email me at communityhelp@aerohive.com (please reference this thread) and we can explore some options.

Hi Sam,

Thanks for responding to this. I don't have a support contract for this as I am just using a single AP for testing at this stage.

I was supporting aerohive a lot for customers in my previous job and this is something I tested at the time. There were many other limitations at the time also.
Whilst things seem to have improved, which is good, this particular thing still eludes me.

As far as I can tell also the setup is good. When I remove the CWP config and just have purely Filter-ID based assignment with mac-auth it works well.

The problem from what I can tell is that the CWP is assigned to the ssid rather than the user profile. :-(

I just can't seem to get around the portal being presented despite my user being in the allowall profile.

Also, I don't see anywhere in the radius server profile where to enable RFC3576. Is this enabled by default? I assume it is cause disconnect-message works. Also, what RFC3576 sort of messages are supported? Primarily wondering if we can change a users user-profile dynamically.

Regards

Michael Clarke
+44 7949383792

Perform full config update on AP. The deltas said they were successful for me and I had the same problem.

Nevermind it's doing it on my deployment as well.

I have the same issue on my deployment.

Thanks for your patience while I looked in to this further. If you are using an AP250 on 8.2r4 or AP330 on 6.5r10, the HiveOS does not recognize the command that enables the CWP bypass. If you are using an AP250, I would recommend moving to 8.4r7. Unfortunately that option is not available for the AP330 so those will have to wait for the next HiveOS release to fix this issue.

Hi all,

 

I think you just need to configure the fallback-to-ecwp command via supplemental CLI.

 

I double checked HiveOS 6.5r10 and this is supported there.

 

You will need to find the name of the security-object by reviewing the show run output.

 

show cmds | include fallback-to-ecwp

 

security-object <string> security additional-auth-method mac-based-auth fallback-to-ecwp

 

show version

 

Aerohive Networks, Inc.

Copyright (c) 2006-2018

 

Version: HiveOS 6.5r10 build-205308

Build time: Wed Aug 8 10:22:25 UTC 2018

Build cookie: 1808080322-205308

Platform: HiveAP330

Bootloader ver: v1.0.3.4d

TPM ver: v1.2.35.8

Uptime: 13 weeks, 3 days, 13 hours, 44 minutes, 32 seconds

 

Thanks,

 

Nick

ok, so I tried that and now nothing seems to work. I see the mac.auth going through and it sending back the correct user-profile attribute, but the device gets dissassociated due to a vlan change. This is strange because every possible user-profile for this ssid is set to the same vlan.

 

2018-12-20 11:10:47 info   ah_auth: sta 6cc7:ec0c:d893 is disassociated from 4018:b1ae:b8e8(wifi1.1) in driver

2018-12-20 11:10:47 info   ah_auth: [Auth]: receive driver notification[0x8c04, IWEVEXPIRED] for Sta[6cc7:ec0c:d893] at Hapd[4018:b1ae:b8e8, wifi1.1]

2018-12-20 11:10:47 info   ah_auth: Notify driver to disassoc 6cc7:ec0c:d893 from wifi1.1

2018-12-20 11:10:47 info   ah_auth: Disconnect 6cc7:ec0c:d893 because VLAN change after UPID reassignment

2018-12-20 11:10:46 info   ah_auth: detect station(6cc7:ec0c:d893) os(Android) via DHCP fingerprint

2018-12-20 11:10:45 info   ah_auth: detect station(6cc7:ec0c:d893) os(Android) via DHCP fingerprint

2018-12-20 11:10:45 info   kernel: [qos]: add qos user 6cc7:ec0c:d893 idx 3 uppid 1

2018-12-20 11:10:45 info   kernel: [mesh]: set proxy : 6cc7:ec0c:d893 4018:b1ae:b8c0 wifi1.1 flag 0x1c03

2018-12-20 11:10:45 info   amrp2: set proxy route: 6cc7:ec0c:d893 -> 4018:b1ae:b8c0 ifp wifi1.1 upid 3 flag 0x1c03 monitor(0/0) pkt/sec ok

2018-12-20 11:10:45 info   amrp2: receive event <STA join>: 6cc7:ec0c:d893 (ip 0.0.0.0) associate wifi1.1 upid 3 vlan 13 flag 0x00000001

2018-12-20 11:10:45 info   ah_auth: [Auth]STA(6cc7:ec0c:d893) login to SSID(wifi1.1) by user_name=6cc7ec0cd893

 

I am using an AP121 on HiveOS 6.5r10 build-205308

I think at this point we need to open a support case to dig in to this further with you. I have emailed you directly with details on how to open a case from here so the technician can begin where we have left off.

Aerohive has one of the worst tech supports, the idiots at tech support were recommending me to turn off CWP.

I have similar issue where users would keep on getting CWP. I have also tried adding fallback-to-ecwp  via supplementary cli but it didn't work. I did confirm that aerohive NG is getting correct radius attributes required by user profile to bypass CWP.

I have a case open with them for a month and they still dont have any clue regarding this issue.

 

 

I had an issue with CWP bypass via user profile as well. All of my APs were on 6.X HiveOS.. I have a mix of AP121s, 130s, and 230s.. Well I updated all of my APs that I could to 8.X hiveOS (golden) and the bypass now works via user profile on my AP130s and AP230s..

 

Well guess what? AP121s are not getting HiveOS 8.X and are stuck on 6.X.. so now I have about half my APs as 121s and cannot use that feature until I upgrade them to new APs 130s or 122s. That's about 40 APs. I understand they are a little dated but it's ridiculous to think they cannot get the newest code to do this bypass, it's not like it needs new hardware to do it.

AP-121s are not End of life, they should support all the code upgrades.

Its just aerohive tends to be little different!

According to Aerohive, they are "legacy" APs. Bull!

In response to Irteza, I just joined Aerohive and lead the Customer Success team. I am disappointed that you feel this way. In my first three months at Aerohive, I have met just about everybody in the support team face-to-face and I believe we have a great team that is always willing to help. Even in the best of organizations, things slip through the cracks and I am eager to address your concerns and see how we can turn this experience around.

 

I know you have a case open at this time and will be happy to direct message you with my contact details so we can discuss how we can improve your experience.

 

As to Shane and his comments, there are differences between the 6.x and 8.x code that are based on the wireless chipsets from different manufacturers. We will never run 8.x on the AP121s because the chipset is incompatible with the software.

 

It is true that the AP121s have reached end of sale, but they have many years before they reach end of support. It sounds like the feature you are looking for is unavailable with the hardware in those APs. I am sure you understand as newer models of hardware come out, they have the ability to enable new features that weren't built into the older products. If the feature is important to you, reach out to your SE to discuss what options are available to move forward.

If it was a hardware thing I would understand (CWP bypass). I know it is probably a manpower/focus and a push for people to update their APs, which I guess I understand. But by not patching 6.x with new features that are supported in 8.x leaves a lot of people behind. AP121 was a popular AP, for us we have about 50 out of our 100 APs as AP121s. Some of those were only bought a couple years ago. All we want is support for CWP bypass via user profile on 6.x HiveOS.. also, the ability to support DFS channels would be nice, but THAT I understand can be a hardware issue.

And also, AP 121s are only supported until 2021. 3 more years.

Shane, you are correct there are 3 more years of support for the AP121s, which provides you years of risk management if you maintain them under support.

 

You are correct that when a product reaches the end of sale date, the feature set is typically frozen and maintenance releases are the primary focus to ensure that the APs work as intended when they were sold. This redirects new feature development to the then current selling platforms.

 

This is very typical across the industry as I have led Customer Support and Success teams in other companies and this was an industry practice.

 

As I mentioned in my last post, it would be best to reach out to your SE to identify what options are available going forward to provide common features across your installed base.

There is still no justification on why a product would not get the update to perform basic functionality like CWP bypass. This feature has been there for atleast 5 years I know in wireless. I truly believe our company is not the only one having this issue.

There would be many customers implementing CWP with external radius servers for wireless security.

 

In response to Paul's comments, so far aerohive has not provided any answer, its been a week since they even updated the ticket. Your team must be great , but the level of support we got from great team was terrible.

 

Their inability of identifying the issue and proper communication raises a lot of questions. Tech support either suggested us in removing CWP or asked us to buy new APs. Now why would you remove the CWP? one certainly gets baffled by those responses.

 

In my opinion a product should be support and if an issue has been highlighted that should be addressed. It is very easy to say no and ask for new access point.

While this may be an easy answer from you , but certainly not a easy to implement from user.

Thanks for the input guys. Turns out I was using an AP121 for this testing which would explain why it wasn't working.

Like everyone else, this is disappointing since it is hardly a feature that justifies new hardware (like DFS channels).

Hi guys,

 

I’m trying to get this bypass CWP working on AP121’s running the latest code ( 6.5r12  ).

It’s working on AP230’s I have using the same config, clients in the MAC address bypass rule are bypassing the CWP as expected.

I have configured Supp CLI as described, but the client is being rejected (not associating correctly), I suspect the mac filtering is not working

Can someone confirm this works with AP121’s and the latest config and any help on steps needed would be much appreciated

 

Thanks

Reply