Client VPN Concerns

[Mr_IT_Guy]

So I spent some time playing with the client VPN today and I have a couple concerns that I wanted to bring up:

• Authentication using Meraki Authentication: Understanding that I can use RADIUS or Active Directory, when using Meraki Authentication for VPN, it is not possible (that I have found) to force strong passwords to the registered users. If you can set strong passwords for Dashboard access in your organization, why can't you do the same for Client VPN? Seems odd.
• Blocking VPN clients: If a user VPNs in, the client shows up either via MAC/IP address. If I block that MAC/IP address, only that particular MAC/IP address is blocked. A user can simply VPN in on a different machine and get in. Sure you can disable them via AD/Radius/Meraki Authentication, but that defeats the whole purpose of blocking the client in dashboard. Additionally in the case of AD, I simply want to stop their VPN ability without taking away their rights in AD. 

Any thoughts?

[EG-OST]

First point, your best option is to call support and ask that question, as you are right there is no setting in the portal that will help you set that up.

For the second point, when you are blocking the user, its for Internet traffic, just as any other user in your local network.

a wired user can bypass the block by using the wireless connection.

If there is a concern about the access for that user, the policy should be to remove the Authorization in the portal / AD.

[PhilipDAth]

With controlling who can VPN in; the easies it option is to use RADIUS (Network Policy Server (NPS) on Windows servers).  With this you can create a create (say "VPNUsers") and only grant them permission to use the VPN if they are a member of that VPN.

[Mr_IT_Guy]

@PhilipDAth, as I said in my post, I understand that I can use RADIUS. The focus of my post was more on the limitation of Meraki Authentication.

@EG-OST, we have a ticket in Meraki already about point #1. At this time, they told us this was a "feature request". Seems pretty straight forward of something that should've been included in the first place in my opinion. As for the second point, I guess my concern is more of how the block feature is presented during the whole Meraki sales pitch. "Look,  you can block this user this easily!". I understand how a user can get around the block.

Bottom line of my post: There's some flaws in the way things are being presented that should be addressed. I love Meraki and the product and just want to make it better.

[Korey]

Hello, just a quick point on the 2nd item you brought up. If you want to block a VPN user within the dashboard why not also deactivate their VPN access at the same time? This would prevent them from logging out and back into the VPN to bypass the policy. 

That would be for a total block which is what I believe you are asking about. To apply a more granular policy then I would move to the RADIUS/NPS policy options @PhilipDAth mentioned. 

[Mr_IT_Guy]

@Korey, RADIUS is the best solution for this situation that has never been questioned. It's the solution I pitched to my friend who inquired about client VPN as she is getting a MX from a webinar to play around with. The issue I'm seeing is that you have these two other options that have glaring holes in them. With Meraki Authentication I can totally block a user all day long but I cannot enforce strong passwords and thus introduce the possibility of a user having cat as their password. With AD authentication, the only way to totally block VPN access it to disable the AD account.

The prompt I'm trying to solve is the following: How can I block a user from VPN access while still allowing them to have domain access onsite? Again, RADIUS is the best solution. My "Let's make Meraki better" part of my brain wants to know how we can fix the other two Client VPN options. Meraki Authentication is easy: let me enforce strong password. But how do we fix AD authentication?

[Korey]

@Mr_IT_Guy, you bring up some valid points. Unfortunately at this time, the MX does not support mapping group policies via Active Directory for users connecting through the Client VPN.

What you can do however is create a firewall rule on the MX blocking the Client VPN subnet from accessing the sensitive internal subnets and/or only allowing specific access. You could apply it at the overall FW page and it would then apply to all VPN clients. OR you could create a Group Policy and then apply it to specific devices. From my testing Group Policies assigned to Client VPN devices are persistent because this is tied to a virtual mac address that has a hash of the username that is logged in. 

Really depends on the level of security you want to put in place. Having an overall FW rule blocking the Client VPN subnet requires no administrative intervention.