I have 2 macbooks with El Capitan. Due to their age no upgrade of the OS is possible.
Now VyprVPN dropped support for EL Capitan thus no bugfixes will be available.
Recently the VyprVPN app stopped working (no connection can get established), so I went through the support pages and noticed the indication of a manual VPN setup with IKEv2 support.
Now fact is that IKEv2 support on these OSs is buggy, every 8 minutes OSX wants to rekey, and the connection breaks.
This issue with IKEv2 is well documented, just google "os x ikev2 failed 8 minutes"

So after contacting support they gave me the hint of checking with openVPN, which actually solves the problem (off course first installing tunnelblick), but I noticed that on the support pages, under Mac there are so many options, and the tunnelblick reference (for a non VPN expert) was confusing.
I only clicked on tunnelblick and OpenVPn because support told me to check openVPN

So actually under EL Capitan, at least for me, tunnelblick and openVPN seems to be the only solution available!But the way of finding this solution was far too complicated and non-intuitive

Requests:
1) For OSX 10.11 and lower remove the IKEv2 hint on support pages, it is misleading and doesn't work in the end. Users might be discouraged when trying that (like me)
2) Instead of the IKEv2 recommendation, the support pages should offer Tunnelblick and OpenVPN more prominently for El Capitan users, perhaps a refrasing would be also smart, mention openVPN before Tunnelblick....
3) the different Mac Options could be reorganized for better intuition, specially offering for 10.11 only the OpenVPN solution (with tunnelblick), I would rewrite the order on this point: first protocol, then the app to be used.

I think it's not a shame to offer the Tunnelblick OpenVPN much more prominent as a fallback solution for older MacOS
It's a bigger shame to have it so hidden that unexperienced users frutratedly stop using your VPN...

It is also recommended to indicate that the main service ooffered is VPN itself, not necessarily the App, at least for older OSs it's completely understandable

Initiative here was to turn on & off VyprVPN as fast as possible so that it requires less attention when it comes to switching. It always happens when you are working in a company that has their own LAN network required to visit internal websites, so you have to switch between internal and external.

These are the few minimal requirements I can think of to make such a CLI utility small but complete:

• option to connect to VyprVPN(of course)


• option of disconnect from VyprVPN


• option to specify which server(ip, alias, or hostname like tw1.vpn.goldenfrog.com) to connect to(you have to change sometimes)


• option to auto find next available server location to connect to when current one fails

have a feature request for the VyprVPN client for Mac OS X which I think makes a lot of sense.

Right now it is not possible to use the kill switch feature in combination with the 'Connect on untrusted networks' features, because when you are on a trusted network it doesn't connect to the VPN servers and the kill switch doesn't let you use the internet even though the network is trusted.

I'd like to suggest an option to exclude trusted networks from the kill switch, so that I can have the VyprVPN app running all the time with the kill switch active, but not having to connect to a VPN when being at home.
But when I leave my home and e.g. sit down at Starbucks and my MacBook automatically reconnects to its Wifi, because it's already known, then the kill switch blocks all internet traffic until a VPN connection is established.

Right now IPv6 is enabled by default in Mac OS X and VyprVPN doesn't support IPv6 at all, so when a user doesn't disable IPv6 and surfs the internet over a network that provides an IPv6 address for him then he is basically unprotected and his real IP address is not hidden.

Maybe you should add a warning when someone first launches the app which says that IPv6 is enabled and that it is highly recommended to disable IPv6 and offer him a button to do so, because right now you have to use the Terminal.

Or, even better: add IPv6 support for your service, but there is already a ticket for that in the general section.