Hi All,
We began using OpenDNS to do some spam and basic filtering on our network. One of the biggest problems we faced because of this was users feeling they could install VPN Apps to bypass filters. I asked that those who had a VPN delete it and submit a ticket to have the site whitelisted (yes, the filter makes mistakes sometimes!). Of course some of the stuborn ones refused to delete it so I created this policy that looks for VPNs and wanted to share just in case anyone else is struggling with the same senario. My first thought was to list all the known VPN apps (which I did and it worked quite well) and search based on that criteria, but I have started to use wildcard (*variable*) matches in there situations and I like it better. Currently I have both running, but I think I have enogh faith in my new group that I can eventually delete it.
I then have a configuration profile that locks down the device based on compliance of this policy. Optionally, I also set up email notifications.
Hope this helps!
Jared
Why don't you make it a company policy that these kinds of software and services are not permitted, and may result in disciplinary HR action ... then you don't have to stop it, only report on it.
@PhilipDAth wrote:Why don't you make it a company policy that these kinds of software and services are not permitted, and may result in disciplinary HR action ... then you don't have to stop it, only report on it.
Try that approach with students... it doesn't work. They've even managed to find a VPN app for iOS and Android that can bypass Meraki hosted auth pages.
I feel I have a good grip on the situation. I provide WiFi via a profile, let’s see how excluding the VPN policy from that profile if they want to continue to test it!
@MRCUR Have you tried a VPN policy like this? Seems to catch pretty much everything . I also locked down installing configuration profiles and setting up manual VPN configurations in settings.
The issue we have with VPN apps being used to bypass Meraki auth pages isn't happening on MDM enrolled devices. So unfortunately this policy won't help with that.
Why don't you configure the auth pages to use "strict" mode, so nothing is allowed to bypass until authenticated?
@PhilipDAth wrote:Why don't you configure the auth pages to use "strict" mode, so nothing is allowed to bypass until authenticated?
I did. The VPN tunnels over port 53 which isn't being blocked in "strict" mode because of DNS traffic. There's a feature request open internally to allow of manual DNS whitelisting to stop this.
@MRCUR are you using an MX unit for your security appliance or something else. Perhaps you need something that is able to identify VPN traffic regardless of what port its using.
Otherwise can you block port 53 for all devices except for your internal DNS servers?
I had our network guy create a separate iPad wireless that I push via a profile. One of our biggest issues is manual VPN configurations. While my policy looks for VPN apps it really falls short for users configuring manual VPNs. While I have creating VPN configurations not allowed as a restriction they can still install an actual ".mobileconfig" containing a VPN payload that will install and work. I will forward this thread to our network guy to see what he thinks. He may toss out some ideas to block it from a network perspective.
@PhilipDAth It is spelled out in the acceptable use policy signed when the iPad was enrolled and assigned to the user. Honestly, the filtering is basically just there to find spam and block the basics.
This is a fresh program so I do not want to over step any boundaries from the user standpoint. The only complaint I know of is that we set the wallpaper daily. The user can keep resetting it, but it will revert back to our JPG we have scoped out. That was not my call and came from administration.
Adding *betternet* to this also helped. I have been testing this out more and that is the only app that can possibly bypass this.