ii) VPN Capabilities Achieved
In general, we have a VPN on-demand service that mostly meets our requirements, though either I've not understood the iPhone's on-demand rule-processing capabilities or they're failing in major ways. In addition, the initiation of on-demand VPN connections is extremely "flakey," often requiring multiple failed connection attempts before one is finally completed. This appears to be due to iOS issues, likely related to the on-demand rule processing issues. Once connections are made, the VPN-connected device behaves very well, with our setup.
As of 2014-Mar-18, here's where we stand relative to the stated VPN Requirements:
- multiple concurrent VPN connections from iPhones are supported – administration should be a non-issue, once configured, and, except for the current "flakeyness," the User shouldn't have to do anything with the VPN
the User can both turn off/on any of the configured VPN connections and/or disable/enable a VPN's "on-demand" behavior, if required
(via Settings → VPN)
- we have both IPSec and OpenVPN on-demand configurations working but only the OpenVPN configuration is acceptable for use as the "set it and forget it" on-demand VPN strategy
both IPSec and OpenVPN VPN connections route all the iPhone's traffic through our network – however:
- an OpenVPN VPN connection via our WiFi works – though, as would be expected, it inefficiently doubles the device's traffic through our network (i.e., because it's configured to do so)
- an IPSec VPN connection via our WiFi does not work – though this may be a solvable issue, because the on-demand rules don't turn off the VPN when connected to our WiFi, the on-demand IPSec configuration is unacceptable for use as the "set it and forget it" on-demand VPN strategy (i.e., because it breaks when transitioning from cellular data to our WiFi)
- VPN connected iPhones have access to our internal network(s), subject to the router/firewall configuration – this means their traffic is also traffic/packet-shaped (helping performance) and get the benefit of our "bad guy" filtering along with some tracker-blocking and ad-filtering
- VPN connections are driven by certificates and the User is not required to enter a password to create a VPN connection
- VPNs are configured to use self-signed certificates – by creating a unique client/user certificate for each device, you can also easily shut down only that device's access if required, though this does significantly increase the administration/setup effort
- Significant Issue: although the on-demand rules normally ensure that a new VPN connection is not made when the device is connected to our WiFi network (primarily because that rule seems to always be ignored), the on-demand rule that is designed to turn off any existing VPN connection when connected to our WiFi also has no effect – the result being that when transitioning from cellular data to our WiFi network (either by turning WiFi back on or by entering our WiFi's proximity), the existing VPN connection is not turned off
- Caveat: testing of connections to other WiFi networks is not yet complete so we have incomplete data on whether a VPN connection to our network is automatically created when the device is connected to WiFi network that's not ours
- Has Issues: when a device is connected to the cellular data network, the VPN connection to our network is automatically created – however, the initial connection is very problematic when transitioning from WiFi to cellular and often takes multiple failures, which can cause the web page/application to fail, before finally making a successful connection (this appears to be due to flakey on-demand rule processing and actually got worse with the iOS 7.0.4 release – but the iOS 7.1 beta 5 seems to fix the issues when transitioning from WiFi to cellular)
- in our configuration, if required, OpenVPN connection attempts will first try a selection of 4 different UDP ports and, if a connection still has not been made, will attempt to connect via TCP port 443 – while it's unlikely that anyone would be blocking such connections to TCP port 443, we only want to run OpenVPN via TCP as a last resort because of the issues surrounding retransmitted packets
- Significant Issue: our on-demand rules are configured to query a web page on our site to help ensure that our site can support a VPN connection at that point in time and that page does an analysis of its ability to successfully support the VPN and replies accordingly – though the rules don't work at all like we expect from reading the documentation (e.g., the web-page probe that's supposed to be issued when on a WiFi connection is never issued)
In spite of the issues, the net result (pun intended) is that we are currently using the OpenVPN on-demand configuration as we believe the increased security outweighs the annoying issues.
Return to the VPN article's overview page.