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:
Code Block
Connection 2: encountered error(1:53)
Connection 3: encountered error(1:53)
Connection 1: encountered error(1:53)


Code Block
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) 


Replies

If you are using a local DNS server that cannot be accessed due to all traffic going through the tunnel then this would explain why calls to getaddrinfo are failing.

The logs in the console look like traffic is still trying to go over an interface that is not utun or ipsec related though. I'm wondering if you are getting this because of a routing change for the VPN's virtual interface and this traffic is not respecting that change. If you remove and includeAllNetworks and restart the VPN, does this resolve the errors in the log below? Not that this is a solution to your problem, I'm just trying to work through why this traffic is going around the tunnel interfaces if you instructed it not to.


No mDNSKeepalive 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)


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Removing 'includeAllNetworks' and restarting the VPN resolve all the errors. There are no logs like 'host unreachable error for DNS server'.
Setting 'includeAllNetworks' and restarting the VPN will print those logs.
I'm not using local DNS server, I'm just calling to getaddrinfo which suppose to query public DNS servers.
More details:
The problem is that I can't connect at all: In order to connect I need to get responses from getaddrinfo, but as I said getaddrinfo fails. I also tried to use lib curl which also failed.
I've set the includeAllNetworks and I tried to connect - my extension uses some C code to establish the connection using BSD sockets and "low" level code. I'm not using high level functions like 'createUDPSessionThroughTunnelToEndpoint' at the extension.

Since I can't connect I don't have the tunnel - I'm creating the tunnel only after I found the server's IP, so how can the traffic go only via a tunnel which isn't exists yet?



P.S - sry for the delay.
Another comment:
I didn't call the completionHandler of the startTunnel at the extension, so I would expect that traffic would still pass outside the tunnel, until the tunnel is established.
Do you have any custom NEDNSSettings that are attached to your NEPacketTunnelNetworkSettings? This is the first place that I would look to see why your getaddrinfo calls are failing.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
No, no custom NEDNSSettings.
I think the basic question is why the traffic got blocked before there's even a tunnel?
And in addition, It sounds reasonable that traffic coming from the extension should not be blocked.
Is it possible that I must use createUDPSessionThroughTunnel at the extension for this case?
Yeah it sounds like you are stuck in a limbo state when restarting the tunnel preventing your network connections for properly being executed. I suspect you will not have any luck with createUDPSessionThroughTunnel either if you are restarting the tunnel. If you completely disconnect the tunnel do you still see this behavior? If so, as a test do you still see this behavior even if you remove the Network Configuration for your VPN profile? After removing the configuration you should be able to run your getaddrinfo and lib curl calls at least, correct?


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
It's not even restarting the tunnel I it was existed before, it's also for creating it for the first time. Even if I simulate a new user - just creating a profile with includeAllNetworks = true, and start the VPN for the first time, I have the above problem.

Doing the same thing but with includeAllNetworks = false, and there's no problem at all.
Removing the profile also works.

It's just this flag which causes the problem - all the traffic at the extension gets blocked, even if it's the first time I'm trying to create the tunnel.
Interesting. The bottom line is that it sounds like traffic is escaping the tunnel some how with includeAllNetworks = true and is therefore being dropped. At this point I think it would be good to open a DTS incident so I can take a closer look at what is happening.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Done -  Follow-up: 741742681
Thanks!
Acknowledged. Thank you.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Thanks! And if it helps - I can send the Console logs.
I'm Trying To Achive This Particular Behavior, Can U Share Ur Sample Code To Figure Out How U Did It ?
@DreamLordOneiros I didn't try it yet but maybe the reason it's not working for me is that at the Extension I'm not using Extension native API (like createUDPSession() for example), and I'm using BSD sockets/openSSL instead.