VPN configuration

Is it possible to configure by code or via Apple configurator a profile with VPN payload, which uses my custom VPN (my implementation for Packet Tunnel Provider),

And will be ondemand or always-on, and will allow traffic from Captive Networking ?

Accepted Reply

Earlier I wrote:

I don’t know if it’s possible to implement similar functionality using a Network Extension provider …

I spent some time looking into this and confirmed that it’s not currently possible for third-party VPN transports to connect up to the Always-On VPN infrastructure (r. 21363342). If you'd like to see that supported in the future, I encourage you to file an enhancement request describing your requirements. While we have seen similar requests before, a fresh bug report will allow you to express your needs in your own terms, and allow iOS engineering to gauge the level of demand.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

Is it possible to configure by code or via Apple configurator a profile with VPN payload, which uses my custom VPN …

Yes. You can find instructions for doing this in the Configuration Profile Reference. Specifically, look at the

VPNSubType
key.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks escimo, but that the problem is that if I want to use my PacketTunnelProvider implementation, the VPNType should be "VPN" (and the subtype should be the bundle id) , but if I want also the captive networks - the VPNType should be "AlwaysOn" (and not "VPN")

Always-on VPN implies a built-in VPN transport, namely IKEv2. I don’t know if it’s possible to implement similar functionality using a Network Extension provider; if you need a definitive answer you should open a DTS tech support incident, which will allow me to spend time researching this.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Got it, Thanks!

I am also keen in undertanding this aspect before moving forward: can you guys let me now if the DTS Tech Support incident has been opened (otherwise, I will do that).

@Quinn: below a short summary of the use case I am investigating and where I believe we are at in the Apple ecosystem. If I overlooked something, feel free to correct me as any insight would be valuable.


For a good slice of the enterprise developers that are looking at these technologies for the first time, the end objective is that of ensuring that the traffic on the device will always be tunnelled to the desired proxy (eg: not relying on the end user to activate / deactivate the tunnel). The particular VPN protocol (or even whether the tunnel is a VPN or an unencrypted tunnel) is often secondary.


At present, the above can be achieved to some extent with a combination of either:

1) An app using NEVPNManager (usually in combination with a configuration profile) with IKEv2 and Always-on VPN enabled. This would still need either a supervised device or a third-party MDM solution to ensure that the user does nor uninstall the profile and / or the app.

2) Alternatively, if the objective is the proxying nature of the tunnel and not necessarily the encyption of a full VPN, the following combined approach should do the trick:

  • As for 1, but using a different type of VPN that does not allow Always-ON (for instance IPsec VPN)
  • ...combined with a proxy setting enforced via the Global HTTP Proxy profile.

If the user had to turn the VPN off the traffic will still be routed to the global proxy specified in the profile, de facto preventing the user from circumnavigating the desired point of control. I think that this would only be an option for supervised devices though, as I am not sure if a Global HTTP Proxy Profile can be enforced by third party MDM solutions.

3) The disadvantage of both 1 and 2 is that we are restricted of using one of the default VPN protocols in order to obtain traffic routing. The Tunnel provider bring the advantage of using a custom VPN, which in turns may mean something as simple as the packet encapsulation provided by the SimpleTunnel implementation.

Furthermore, the documentation states that tunnels created bia the TunnelProvider extension are enterprise-level VPNs, and therefore will have priority over personal-type VPNs such as those created via the NEVPNManager.

It is not clear though (hence this post) if there is any way to enforce the tunnel provider to be always on, eg: to ensure that the user cannot circumvent the traffic tunnelling by simply switching off the VPN in Settings. If that is the case, it would be game-over for enterprise security solutions.

It'd be great to know where we are at the moment but, in any case, a crucial point would be to understand whether that was a design decision (eg: TunnelProviderManager is no meant to be used as a way to enforce traffic rerouting), or the consequence of not having considered this enterprise use-case.

In my case, I'd be happy to know that Apple is open to ship this as an enhancement in iOS11 to validate the techonlogy choice. On the contrary, I'd have to rely on one of the solutions above, which would be a shame as the Tunnel provider seems a more futurable technology to use.


On a side note: the above is focused on looking at a common architecture for MacOS and iOS, with a particular focus on the mobile environment. If we had to consider Mac only, a conceptually viable solution may be that of creating directly a network adapter by means of the BSD socket library. Apart from the hassle, we would be talking of damons and services running as root, the sort of mirabilia that is out of the equation in the iOS environment.

I didn't open a DTS tech support yet

DTS tech support opened: 655794898.

It is a bit of an odd one as it is more of an API investigation / use-case analysys from Apple rather than a bug or code-related support request, but there's a reference to this post and hopefully @Quinn will be the one picking this up so he's aware of the context.


@roee84: did you manage to solve the issue of the traffic routed / natted back to the tunnel you were discussing in https://forums.developer.apple.com/thread/36453? I have a similar post with reference here and I could use a hint from someone who's gone through it before: https://forums.developer.apple.com/thread/69962. Thanks!

It didn't worked well for me at the SimpleTunnel app, but worked just fine at my project

That's quite a surprise..you mean that you never managed to make the traffic route back to the tunnel in SimpleTunnel, but it worked of the box when creating a new project that uses the Packet Tunnel API? Would you be able to elaborate furter on the configuration / setup that you are using? I have seen a variety of people with the same issue but sadly no-one seemed to have post what configuration worked for them.

Yes, it worked for my project.

But can you be more specific with your question?

Absolutely, all the details are listed in https://forums.developer.apple.com/thread/69962 but a shorter overview below.

I am running SimpleTunnel on my iPhone (10.x) and estabilishing a tunnel with tunnel_server running on my Mac (Sierra). The tunnel is created on the virtual interface etun2 and the client is assigned an IP from the default pool defined in config.plist (192.168.2.2): the VPN icon appears on the device. When I open mobile Safari, for instance, and type in www.bbc.co.uk, I can see that the DNS query is sent from the device via the tunnel to utun2, mapped (via nat) to the Mac's WI-FI interface en0 and IP 10.0.0.11, and from there forwarded to my router at IP 10.0.0.1. The router responds with the DNS response with destination IP matching Mac's one 10.0.0.11, but the packet is not routed back from en0 to utun2 and therefore it doesn't reach the iPhone via the tunnel. As a consequence, the client cannot browse the web.

It looks like the nat rules to map the tunnel' virtual network interface (utun2 / 192.168.2.2) to the server's IP address and Wi-FI network interface are working on the way out, but the response packets have no idea that they should be mapped back from nat0 to etun2 and 192.168.2.2.

It is a similar situation to the one depicted in a variety of other posts I've seen you replying to on 11 Feb 2016 (https://forums.developer.apple.com/thread/36453). did you setup a paritculat config.plist and nat rules configuration to achieve routing the responses back to the tunnel, or did you find out there was something intrinsecally bugged with SimpleTunnel's code that you have fixed in your own project?

Oh, as I said - It didn't worked for me with the SimpleTunnel project.

Only when I created another project and used my server it worked.

Is you VPN server still an instance of tunnel_server running on OSX, or has it been re-implemented in another language and/or runs on a different operating system, eg: Linux? Just wondering as this may be more of a netops congiuration issue and therefore it will vary from OS to OS (different nats and mapping restrictions), but I was trying to test it end-to-end using tunnel_server to run it locally on OSX.

Completly different (Linux)

Ok, thanks. That chages it all, but at least I know I still have to find someone who's managed a working tunnel via the sample project.