Matt? Quinn? Any thoughts on this? When I setup the NWUdpSession for LTE, for the source address, I get the IP address of 192.0.0.1. Always. On any phone I try this with. Whereas, with Verizon, we get a random IP for LTE, like 100.105.38.96. On Android, we don't bind to a local IP address, we bind to a transport type, e.g. Wi-Fi or LTE. I am wondering if there is a similar option in iOS.

(Update) From what I am reading, the issue is likely because T-Mobile requires ipv6 only support. When I setup the tunnel, I do provide both v4 and v6 endpoints, but when setting up the individual links, I can only specify a single local IP address (v4 or v6). Can someone explain how to setup a NWUdpSession that supports both v4 and v6, or it that is even the right thing to do? Tunnel: tunSettings.ipv4Settings = NEIPv4Settings(addresses: [ip4Address], subnetMasks: ["255.255.255.0"]) tunSettings.ipv4Settings?.includedRoutes = [NEIPv4Route.default()] tunSettings.ipv6Settings = NEIPv6Settings(addresses: [ip6Address], networkPrefixLengths: [124 as NSNumber]) tunSettings.ipv6Settings?.includedRoutes = [NEIPv6Route.default()] Links: let src = NWHostEndpoint(hostname: link.ipv4!, port: String(link.port)) link.udpSession = self.createUDPSession(to: dest, from: src)

This is how the console looks when it works (Verizon) default 14:56:05.737875-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing. default 14:56:05.738353-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C4] reporting state preparing default 14:56:05.739279-0600 IWiNS-Tunnel nw_flow_connected [C4 IPv4#6942181e:8091 in_progress channel-flow (satisfied (Path is satisfied), interface: pdp_ip0, scoped, ipv4, ipv6, dns, expensive)] Output protocol connected default 14:56:05.739496-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C4] reporting state ready default 14:56:05.739645-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing. default 14:56:05.739684-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Ready. default 14:56:05.739764-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (IsViable) - LTE. IsViable: true.

Here is a relevant section from the console: default 12:18:46.628081-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 initial path ((null))] event: path:start @0.000s default 12:18:46.628137-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing. default 12:18:46.628679-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 waiting path (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: path:unsatisfied @0.000s, uuid: 80574970-6F25-4388-8936-6809DEF1A02C default 12:18:46.628741-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C618] reporting state waiting default 12:18:46.628978-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 in_progress resolver (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: resolver:start_dns @0.001s default 12:18:46.629035-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing. default 12:18:46.629092-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C618] reporting state preparing default 12:18:46.629247-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Waiting. default 12:18:46.629465-0600 mDNSResponder [R39862] DNSServiceCreateConnection START PID[1594](IWiNS-Tunnel) default 12:18:46.629714-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Waiting. default 12:18:46.629961-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing. default 12:18:46.630305-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 in_progress resolver (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: resolver:receive_dns @0.002s default 12:18:46.630402-0600 mDNSResponder [R39862] DNSServiceCreateConnection STOP PID[1594](IWiNS-Tunnel) default 12:18:46.630884-0600 IWiNS-Tunnel [C618.1 IPv4#5aa006fc:8091 initial path ((null))] event: path:start @0.002s default 12:18:46.631225-0600 IWiNS-Tunnel [C618.1 IPv4#5aa006fc:8091 waiting path (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: path:unsatisfied @0.003s, uuid: 359E2D37-59A9-4025-93E2-7B2D52986999 default 12:18:46.631548-0600 IWiNS-Tunnel [C618.1 IPv4#5aa006fc:8091 failed path (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: null:null @0.003s default 12:18:46.631696-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 failed resolver (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: resolver:children_failed @0.003s default 12:18:46.631773-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C618] reporting state failed error Network is down default 12:18:46.632093-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing. default 12:18:46.632160-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Failed. default 12:18:46.632241-0600 IWiNS-Tunnel iwins->tunnel: *** Failed Link: LTE *** default 12:18:46.632327-0600 IWiNS-Tunnel iwins->tunnel: Stopping KVO observers default 12:18:46.632405-0600 IWiNS-Tunnel [C618 E0D68D17-6E75-4CDC-84F1-74CC16AD1AF0 IPv4#5aa006fc:8091 udp, local: 192.0.0.1:59831] cancel default 12:18:46.632482-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 udp, local: 192.0.0.1:59831] cancelled

We would be interested as well to see the suggested improvements from Apple, as we have the same concerns. Can someone post this?

Solved! When creating a VPN Configuration from within the application, I needed to set the bundleID of the configuration to match the bundleID of the network extension. I now have a skeletal xcode project containing targets for a sample application and a network extension. The primitives for creating a TunnelProviderManager (creating VPN Configurations) and start/stopping the tunnel are embedded in an object that lives in the framework that I created, an SDK of sorts. The guts of the network extension implementation are also in the framework, which contains this class: import NetworkExtension open class PacketTun: NEPacketTunnelProvider { . . . } Then, for the PrincipalClass defined for the NetworkExtension target, I have a class derived from the implementation found in the framework, which has no additional implementation import IWiNS_SDK class PacketTunnelProvider: PacketTun { }

Update: Thinking that this runtime error may not have anything to do with the tunnel code being refactored into an SDK, I tried to recreate the working network extension as a brand new target, with the same settings, and I am seeing the same error. So I think it has to do with how the app is associated with the network extension. I verified that the new network extension's bundleID has a prefix that matches the application bundleID, but I am now wondering if there is something in the application configuration (or code) that needs to be set to specify the name of the network extension.

So close.. (I think!) I have a new network extension, and the target class just inherits from the class that we've been using in our app. Here is the target class: import IWiNS_SDK class PacketTunnelProvider: PacketTun { } PacketTun is now included in our framework (IWiNS_SDK), with the class and relevant functions declared public. All entitlements seem in order. Here is the extension info.plist: <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleDisplayName</key> <string>IWiNS-VpnTunnel-V2</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.networkextension.packet-tunnel</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).PacketTunnelProvider</string> </dict> </dict> </plist> Here is the entitlements file: <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict>   <key>com.apple.developer.networking.networkextension</key>   <array>     <string>packet-tunnel-provider</string>   </array>   <key>com.apple.security.app-sandbox</key>   <true/>   <key>com.apple.security.application-groups</key>   <array>     <string>group.com.cablelabs.vpndemoappgroup</string>   </array>   <key>com.apple.security.network.client</key>   <true/>   <key>com.apple.security.network.server</key>   <true/> </dict> </plist> When the app comes up for the first time, we create a new VPN Configuration, which looks OK in the iOS->Settings->VPN page. But when I try to connect, I get the error in the console: "The VPN app used by the VPN configuration is not installed" Any suggestions? Thank you for your replies. default 13:11:22.260673-0700 IWiNS-ReferenceApp Saving configuration IWiNS with existing signature {length = 20, bytes = 0x9327ba20312d9952f7be79a6903171614d8ac4de} default 13:11:22.279160-0700 IWiNS-ReferenceApp Received a com.apple.neconfigurationchanged notification with token 100 default 13:11:22.279539-0700 IWiNS-ReferenceApp Successfully saved configuration IWiNS default 13:11:37.428236-0700 IWiNS-ReferenceApp Attempting to start VPN default 13:11:37.438298-0700 IWiNS-ReferenceApp Last disconnect error for IWiNS changed from "The VPN app used by the VPN configuration is not installed" to "none" default 13:11:37.441893-0700 IWiNS-ReferenceApp Received configuration update from daemon (initial) default 13:11:37.449975-0700 IWiNS-ReferenceApp Last disconnect error for IWiNS changed from "none" to "The VPN app used by the VPN configuration is not installed"

Yes, sorry - I got tripped up on the terminology. I meant not a universal framework. As far as the code in the extension to pull in the framework, yes I anticipated that - we mostly want to obscure the bulk of the inner workings. And yes, they'll need to deal with entitlements. I'll try to have all most of this taken care of with the sample project for both the extension and the app. Thanks

An iOS cocoa touch framework - static, as in device only (dynamic also works with simulators). I "think" I might have an idea for a solution: Create the "guts" of a packet tunnel extension as a framework, and then create a project for a skeletal extension that includes that framework (as well as the NetworkExtension framework). Then the developer just has to set the extension project's bundleID to have the same prefix as their custom app. All we would need to distribute is the binary framework and a sample project. The goal is to make it easy for a developer to incorporate the functionality of a packet tunnel extension into an existing app, while shielding them from the contents of the extension. If you have suggestions for I workable solution, I'd love to try it. Thanks!