Search results for

includeAllNetworks

150 results found

Post

Replies

Boosts

Views

Activity

Reply to Binding socket to an interface in Network Extension
One thing to note is that createTCPConnectionThroughTunnel(…) does not work when includeAllNetworks is enabled. Well, that’s annoying. IMO that’s eminently bugworthy. I don’t see a bug number on that other thread. Did you file a bug about this? If not, and this is causing you grief, I encourage you do so. And please post your bug number, just for the record. A previous post noted this issue as well see here You’re assuming I look at the threads that Matt is helping out on (-: I’m way too busy for that, alas )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: App & System Services SubTopic: Core OS Tags:
Sep ’22
`NEVPNProtocol.includeAllNetworks` and `NEPacketTunnelProvider.createTCPConnectionThroughTunnel`
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 pr
8
0
1.9k
Aug ’22
Reply to VPN causes CarPlay to not work
Configuring a VPN with includeAllNetworks causes CarPlay / Netflix Cast [to fail] That sounds eminently bugworthy to me. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: App & System Services SubTopic: General Tags:
Aug ’22
Setting includeAllNetworks usually blocks GW connection in the extension, "kernel ALF, old data swfs_pid_entry"?
I'm seeing the connection to the VPN gateway failing in our Network Extension (not a System Extension) most of the time. Sometimes it succeeds. There's no difference in what the application or the extension are doing in the two cases. I can't see a pattern to when it fails, but In the console I see different messages. The only thing I've seen showing up consistently on failures but not successes is the message about the swfs_pid_entry. On failure: vpn_extension Gateway address 10.10.10.10, port 443 kernel ALF, old data swfs_pid_entry <private>, updaterules_msg <private>, updaterules_state <private> vpn_extension connect failed with error 65 (No route to host) kernel connect() - failed necp_set_socket_domain_attributes vpn_extension Connect returncode 65 On success: vpn_extension Gateway address 10.10.10.10, port 443 trustd User has disabled system data installation.
5
0
2.3k
Aug ’22
Reply to Setting includeAllNetworks usually blocks GW connection in the extension, "kernel ALF, old data swfs_pid_entry"?
Still haven't figured out what to set to see the ALF data, but I noticed that there are some messages from netext about the connection that's failing. netext is a Microsoft Defender extension. If includeAllNetworks is on and Microsoft Defender is trying to do something with the traffic to the Gateway I suspect that it would be a problem. Are there any known issues that you can say anything about WRT anti-malware (e.g., Microsoft Defender) & proxy software (e.g., iBoss) interacting with VPN packet tunnels? It'll be tricky for me to find a test system which has none of these installed...
Jul ’22
includeAllNetworks - Can't establish tunnel when includeAllNetworks is set
I've implemented a custom VPN app for macOS (using Packet Tunnel Provider). I set includeAllNetworks at the protocolConfiguration. When this field is set, I can't connect and I can't send traffic even at the extension. Even simple calls at the extension, like getaddrinfo or curl fails. If I'm unsetting this variable (includeAllNetworks = false) then I can connect without a problem. In addition I can see those lines at the Xcode Console: Connection 2: encountered error(1:53) Connection 3: encountered error(1:53) Connection 1: encountered error(1:53) And those lines at the Console: No mDNS_Keepalive for interface en8/IOSkywalkLegacyEthernetInterface kr 0xE00002C0 NetWakeInterface: en8 <private> no WOMP uDNS_CheckCurrentQuestion: host unreachable error for DNS server <private> for question failed to send packet on InterfaceID 0x5 en8/4 to <private>:53 skt 74 error -1 errno 65 (No route to host)
16
0
3.5k
Jul ’22
Reply to `NEVPNProtocol.includeAllNetworks` and `NEPacketTunnelProvider.createTCPConnectionThroughTunnel`
Yeah, this one is odd. I have seen issues where using includeAllNetworks causes issues for networking tasks, e.g., DNS resolution or authentication outside of the VPN server before the tunnel comes up. In this case if your connection to the remote address is truly inside the tunnel then that should not be causing issues here. You mentioned earlier that you were using a WireGaurd base tunnel. If you go back to a vanilla install of NEPacketTunnelProvider, does this work for you?
Jun ’22
Reply to `NEVPNProtocol.includeAllNetworks` and `NEPacketTunnelProvider.createTCPConnectionThroughTunnel`
Hi Matt, thanks so much for your reply. We pass nil as the TLS delegate parameter when calling startTunnelWithOptions, so I don't think that should be an issue. I'd just like to re-state the conditions of the failure mode: .includeAllNetworks set to true in the provider settings leads to connections created with createTCPConnectionThroughTunnel not connecting createTCPConnectionThroughTunnel works normally when .includeAllNetworks is set to false Normal network operations with URLSession.shared work normally in the network extension with .includeAllNetworks set to true Normal network operations on the rest of the system (i.e., outside of the network extension) work normally with .includeAllNetworks set to true You gave the following possibilities as worth investigating (let's set aside #1 and #2 for the moment for the reasons mentioned above): The connection purely timed out. A better path became available and the viability changed, which is a way of describing that the tun
Jun ’22
Reply to `NEVPNProtocol.includeAllNetworks` and `NEPacketTunnelProvider.createTCPConnectionThroughTunnel`
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? When using createTCPConnectionThroughTunnel this API will create a new TCP connection bound to the tunnels interface. So if the address NWEndpoint has a remote address that corresponds to the interface, then all should be good. The includeAllNetworks flag causing an issue here is an interesting wrinkle. Do you have any other providers installed and on the device / machine that you are working with? Also, what do you have the tunnelRemoteAddress set to in NEPacketTunnelNetworkSettings? Is it the destination IP of your VPN server? Lastly, are there any logs that show up in the Console.app of where the TCP connection is getting stuck?
Jun ’22
Reply to `NEVPNProtocol.includeAllNetworks` and `NEPacketTunnelProvider.createTCPConnectionThroughTunnel`
Another update: it looks like if I use URLSession instead of createTCPConnectionThroughTunnel to create a TCP stream, the connection works just fine with .includeAllNetworks set to true, but the connection doesn't go through the tunnel. It would be rather ironic if users switched this setting on expecting a more secure connection, only to have the app be forced to use a part of the API that doesn't tunnel a portion of their networking...
May ’22
Reply to Why binding INADDR_ANY in Network Extension is not allowed other apps to connect it using localhost
You essentially have a few options here. Go full tunnel VPN, to which you could claim all the routes on your system by hand, or go with the includeAllNetworks flag on NETunnelProviderProtocol. Or, you could go with Per-App VPN and claim traffic for specific apps. Having apps connect to a listener so that you can route their traffic through the VPN in not the way to go here.
May ’22
OpenVPNProvider
am using to NETunnelProvider in a openvpn client that is bridged in react-native but no luck there .. the connection to server keep disconnect every time. the Network Extension is configurated. <?xml version=1.0 encoding=UTF-8?> <!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd> <plist version=1.0> <dict> <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> typescript side is getting events from vpnStateObserver connecting ... Object { message: The VPN is in the process of connecting, state: 1, } Object { message: The VPN is in the process of disconnecting, state: 3, } Object { message: The VPN is disconnected, state: 0, } tunel: type = plugin identifier = xxxxxxx
1
0
608
Mar ’22
Reply to Packet Tunnel Provider + split tunnel + Proxy
Anyway to bypass this without changing the proxy settings? I suspect the immediate way to run your traffic through a proxy on the other side of the tunnel, but that may not be an option. Regarding: Isn't it a bug? Hard to say because if the full tunnel case uses something like includeAllNetworks in the NETunnelProviderProtocol then I would say, no this is not a bug. However, if this behavior has changed between versions, then yes, I would open a bug report. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com
Topic: App & System Services SubTopic: Drivers Tags:
Jan ’22