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.
Solved! Go to Solution.
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
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
Bootloader ver: v188.8.131.52d
TPM ver: v184.108.40.206
Uptime: 13 weeks, 3 days, 13 hours, 44 minutes, 32 seconds
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 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).
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.
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.