23 Replies
      Latest reply: Jan 16, 2017 8:39 AM by m.digimat RSS
      roee84 Level 1 Level 1 (0 points)

        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 ?

        • Re: VPN configuration
          eskimo Apple Staff Apple Staff (6,660 points)

          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"

            • Re: VPN configuration
              roee84 Level 1 Level 1 (0 points)

              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")

                • Re: VPN configuration
                  eskimo Apple Staff Apple Staff (6,660 points)

                  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"

                    • Re: VPN configuration
                      roee84 Level 1 Level 1 (0 points)

                      Got it, Thanks!

                      • Re: VPN configuration
                        m.digimat Level 1 Level 1 (0 points)

                        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.

                          • Re: VPN configuration
                            roee84 Level 1 Level 1 (0 points)

                            I didn't open a DTS tech support yet

                              • Re: VPN configuration
                                m.digimat Level 1 Level 1 (0 points)

                                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!

                                  • Re: VPN configuration
                                    roee84 Level 1 Level 1 (0 points)

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

                                      • Re: VPN configuration
                                        m.digimat Level 1 Level 1 (0 points)

                                        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.

                                          • Re: VPN configuration
                                            roee84 Level 1 Level 1 (0 points)

                                            Yes, it worked for my project.

                                            But can you be more specific with your question?

                                              • Re: VPN configuration
                                                m.digimat Level 1 Level 1 (0 points)

                                                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?

                                                  • Re: VPN configuration
                                                    roee84 Level 1 Level 1 (0 points)

                                                    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.

                                                      • Re: VPN configuration
                                                        m.digimat Level 1 Level 1 (0 points)

                                                        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.

                                        • Re: VPN configuration
                                          eskimo Apple Staff Apple Staff (6,660 points)

                                          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"

                                            • Re: VPN configuration
                                              roee84 Level 1 Level 1 (0 points)

                                              Good to know, thanks again!

                                              • Re: VPN configuration
                                                m.digimat Level 1 Level 1 (0 points)

                                                Here we go, enhancement request number 29899053 filed, it contains a reference tot his post and the DTS request.

                                                • Re: VPN configuration
                                                  m.digimat Level 1 Level 1 (0 points)

                                                  Actually, I just realised that the support for Alway-On is not just unavailable for custom VPN transports created via PacketTunnelProvider (which is what I originally got from Quinn's reference to third-party VPN transports in the reply to my DTS), but for any VPN setup programmatically via the API ( including the supposingly supported IKEv2 setup via NEVPNManager). Unless I have missed something, the only way to setup an "enforced" VPN tunnel from an app seems to be to get the app to point to the URL  where an IKEv2 VPN configuration profile is host in order to install VPN via a profile. The latter can be set to  "Always-On', which in turn applies to supervised device. This seems a much harsher limitation of the VPN API than I oriiginally thought.

                                                  Is this analysys correct or have I missed a potential combination of NEVPNManager and supervised device configuration that would allow us to enforce a tunnel created programmatically?

                                                    • Re: VPN configuration
                                                      eskimo Apple Staff Apple Staff (6,660 points)

                                                      Given that Always-On VPN requires a supervised device, there’s very little point in providing an API for enabling it because the user of the device is unlikely to have the privileges to enable it.

                                                      Share and Enjoy

                                                      Quinn “The Eskimo!”
                                                      Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                                                      let myEmail = "eskimo" + "1" + "@apple.com"

                                                        • Re: VPN configuration
                                                          m.digimat Level 1 Level 1 (0 points)

                                                          Hey Quinn, I don't agree with the interpretation here.

                                                          In the same ways at the "AlwaysOn" VPN tickbox on the configuration profile states "Supervised Devices Only", so it can be configured ahead but it will only kick in when the profile is installed on uspervised devices, exposing it via the API could follow the same behaviour and allow the developers in conjunction with the device "Supervisor" (usually the IT admind which are our enterprise customers) to create an app that enforces a tunnel on the end user's device.

                                                          With the current limitation, the only solution for a developer is to create an app that downloads and install a configuration profile , which is viable but fairly limiting in terms of dynamically chaning the tunnel configuration...something better achieved with the API approach. This is the same problem described in the OpenVPN for iOS app, where the lack of AlwaysON support in NEVPNManager is identified by the developers as the root cause for the issue raised by the end user:  https://forums.openvpn.net/viewtopic.php?t=20820.

                                                            • Re: VPN configuration
                                                              eskimo Apple Staff Apple Staff (6,660 points)

                                                              I don't agree with the interpretation here.

                                                              Well, the good news here is that I’m not the one you have to convince (-:

                                                              If you want the VPN subsystem to support something that it currently doesn’t, you need to make that argument to VPN Engineering via an enhancement request.

                                                              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"

                                                                • Re: VPN configuration
                                                                  m.digimat Level 1 Level 1 (0 points)

                                                                  Eheh absolutely, the comment was more for the sake of the conversation than anything else . I've  already filed an enhancement requets for PacketTunnelProvider follwing the DTS outcome you may remember, I will udpate that to address the issue as a generic VPN API's limitation.