Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About nkarstedt
nkarstedt
Here to help
Member since Apr 23, 2018
Jul 12 2019
Community Record
12
Posts
0
Kudos
1
Solution
Badges
Jul 8 2019
7:46 PM
Correct. When behind an LB, outbound traffic will come from its IP. If you're behind an application configured on the FW/LB, you'll get the same IP from any internet application that will expose your IP (Different from those than can reach your IP FROM the internet). That's the IP that the Meraki cloud will see and must verify as a valid authentication server.
... View more
Jul 8 2019
8:00 AM
I did. Adding the outbound IP address as a RADIUS authentication server solves the problem.
... View more
Jul 17 2018
2:54 PM
I'm having a real issue getting RADIUS Disconnect-Messages working with our solution. I've tested and compared them to a quick test I made in FreeRADIUS, which works fine, but my implementation appears the same, yet does not work. I've attached a PCAP that includes the Access, Accounting, and Disconnect Request messages. I'm not currently getting back the response. I have confirmed that the Disconnect-Request can reach Internet destinations by sending disconnect messages to a computer running wireshark off-network. My RADIUS Server is behind an F5, so it doesn't hold the actual public IP, thus the 10. address. Accounting Start Disconnect Request Please advise! Download the PCAP off Google Drive
... View more
Labels:
- Labels:
-
Code Sample
Apr 26 2018
8:15 AM
Thanks for the reply. Unfortunately, that will not work for our use case as our end users get session timeouts. Group policies do not seem to allow for expirations. Basically a user gets access to lets say 5 device connections on their account. When they first log in, they choose an option: 1 hour, 1 day, etc. Our servers process and send RADIUS accepts that have a timeout that correlates with the amount of time they have remaining on their account (before they would have to log back in and purchase time). Leveraging Group Policies would allow these "bypassed" devices on indefinitely or require us to: - Maintain a list of open sessions connected via Group Policy api. - Process session expirations via Group Policy api. It is very easy for us to make changes on our portals application, but not at all on the services side, which is why I'm extremely hesitant to take this approach. As brought up earlier in this thread, WPA2-E could work but would still require R&D into extending our custom RADIUS implementation to support, though I believe it would be a quicker solution and guarantee access control a bit better.
... View more
Apr 23 2018
2:41 PM
Thanks for the ideas. Since other solutions will require Meraki development work, I think WPA2-E will likely be the cleanest solution for this application. Leaving this thread running so we can hopefully get a fix for the SplashAuthorizationStatus endpoint.
... View more
Apr 23 2018
2:28 PM
@PhilipDAth I hadn't even noticed that option! My only concern for this would be end user confusion. Having an open-access unsecured network with a somewhat similar SSID could result in an increase in support tickets. I may actually have to convince stakeholders that WPA2-E is going to have to be the solution. Although... do you know if MAC-based access control can be combined with Splash Page RADIUS in a logical manner or would a device need to pass MAC-auth in order to even view a splash page. **Edit: Nope.. You'd think you could do an on-connect MAC Auth attempt and place the user in the walled garden if an Access-Deny is presented.
... View more
Apr 23 2018
2:19 PM
Nope, RADIUS accounting is only sent for devices that were authenticated via RADIUS. No data is pushed from Meraki other than RADIUS accounting, (Except sensor polling data which would be useless). Unfortunately, WPA-2E is not an option for us. This is going to have to be handled via API as even RADIUS CoA messages are incapable of "pushing" an unrequested authorization and the devices have no method of requesting RADIUS authentication. Further, access restriction is important as there are various methods of splash authorization including rotating passwords, payments, etc. which expire the user time in system configurable durations. Precision in access revocation would need to be down to the hour to be considered acceptable.
... View more
Apr 23 2018
2:04 PM
We are allowing users to have an "account management" feature to allow them to authorize their incompatible devices. Devices like some rokus, gaming consoles, smart tvs, etc are not capable of using the splash page.
... View more
Apr 23 2018
12:55 PM
Currently, we have a captive portal solution with a RADIUS service that sends both a session timeout and bandwidth caps with its accept messages. The problem is, not all devices that may be on the guest network are compatible with a captive portal solution. To make it easy for our end users, we intend to provide a page that allows users to add certain MAC addresses on their account that should be authenticated upon logging into their account (or on-demand via web interface) End users may roam between networks within the organization and our networks must be combined networks for various reasons. The intent was to leverage the SplashAuthorizationStatus method on the network their primary device was seen at and simply authorize all of the MAC addresses on their account, but that does not seem to be supported on a combined network. We then thought Group Policies may work, but we want the authorization to be temporary and only triggered upon a successful authentication of an account (I.E. a cellphone login on the network, then allow access to a roku with the MAC address on file for 24 hours) The only way we could currently accomplish this would be to have a service go through and reverse each group policy after its intended timeout. Group Policies are intended for dynamic auth without RADIUS, but they do not seem to be a good replacement in their current state. We would very much like these features added to Group Policies & its API and/or the SplashAuthorizationStatus endpoint be upgraded to support combined networks.
... View more
Labels:
- Labels:
-
Captive Portal API
-
Dashboard API
Apr 23 2018
11:29 AM
We need a way to leverage the splashAuthorizationStatus strictly through the API. Our networks are too vast to manually associate all of our hardware in our database with network IDs. Please advise.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 6506 | Jul 8 2019 8:00 AM |
© 2024 Cisco Systems, Inc.
