Post not yet marked as solved
Post marked as unsolved with 5 replies, 404 views
The .includeAllNetworks flag on the NEVPNProtocol object seems suitable for use as a vpn "kill switch." At the very least, the documentation specifies that "if this value is true and the tunnel is unavailable, the system drops all network traffic." Our application has a UI element that allows the user to toggle this setting, for the purposes of ensuring that all of their traffic is sent through the VPN connection.
We're encountering an issue, however: it appears that, with this setting enabled, any NWTCPConnection returned by NEPacketTunnelProvider.createTCPConnectionThroughTunnel will never connect. It stays in the .connecting state and never advances to the .connected state. The documentation for this method states that this method can be used "to create a TCP connection to an endpoint inside the private network."
Does this mean that the remote endpoint being connected to by createTCPConnectionThroughTunnel must reside inside the private network being connected to by the tunnel in order for it to work properly with the .includeAllNetworks setting? Or is the documentation simply suggesting that the TCP connection is tunneled through the private network?
Other web pages seem to be loading just fine while this tunnel is active, it is just the connections returned by this function that seem to be timing out with .includeAllNetworks set to true. If I set it to false, the NWTCPConnection objects returned by this function transition to the .connected state just fine and data can be passed through them with no problems. Is this expected behavior, or is this a possible manifestation of something misconfigured in the VPN profile?
Edit: I tested a bit more and it looks like even local connections over the private network seem to time out; I set up an endpoint within the VPN at 10.1.0.1 and createTCPConnectionThroughTunnel was still unable to connect with .includeAllNetworks set to true.