Is it possible to run both an NEPacketTunnelProvider and an NEDNSProxyProvider simultaneously?

When I tried to run a DNS Proxy while I had a PacketTunnelProvider VPN actively connected, the DNS proxy appeared to start but didnt receive any DNS flows.

If I start the DNS Proxy first, it will receive proxied flows for the DNS queries. But as soon as I connect a PacketTunnelProvider VPN, the DNS queries are no longer sent to the proxy and I see the following syslog output:

Nov 15 15:50:04 iphone nesessionmanager(NetworkExtension)[216] <Notice>: -[NESMSession setStatus:]:753 NESMDNSProxySession[Mobility:8C06EFC5-13C0-4253-97C0-EE588D8CCBA4]: status changed to disconnected, last stop reason Configuration was superceded by another configuration


Is there any way to run both a DNS Proxy Provider Network Extension and a Packet Tunnel Provider Network Extension simultaneously?

Up vote post of chofstaedter Down vote post of chofstaedter
1.3k views
Posted by
chofstaedter
Reply
Add a Comment

Accepted Reply

Is it possible to run both an 

NEPacketTunnelProvider
and an 
NEDNSProxyProvider
simultaneously?

I didn’t know the answer to this, and I figured I should, so I ran this past the R&D folks responsible. The short answer is that 

NEPacketTunnelProvider
and 
NEDNSProxyProvider
should be compatible. The expected behaviour is that DNS queries that are scoped to the VPN interface skip the DNS proxy so that they can be handled by the VPN.

If that’s not working you should definitely file a bug about it. Please make sure to enable VPN logging (per the instructions on our Bug Reporting > Profiles and Logs page) and attach the resulting sysdiagnose.

Also, I’d appreciate you posting your bug number, just for the record.

There is an interesting edge case here, namely that 

NEDNSProxyProvider
is incompatible with Always-On VPN. That was a deliberate policy decision, with the idea being that, in the Always-On VPN case, all network traffic should go through VPN.

When you install an Always-On VPN configuration, the DNS proxy will stop with a message much like the one you’re reporting. However, it’s currently not possible to support Always-On VPN in a third-party VPN transport (r. 21363342), so I know that’s not the issue you’re seeing.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

Is it possible to run both an 

NEPacketTunnelProvider
and an 
NEDNSProxyProvider
simultaneously?

I didn’t know the answer to this, and I figured I should, so I ran this past the R&D folks responsible. The short answer is that 

NEPacketTunnelProvider
and 
NEDNSProxyProvider
should be compatible. The expected behaviour is that DNS queries that are scoped to the VPN interface skip the DNS proxy so that they can be handled by the VPN.

If that’s not working you should definitely file a bug about it. Please make sure to enable VPN logging (per the instructions on our Bug Reporting > Profiles and Logs page) and attach the resulting sysdiagnose.

Also, I’d appreciate you posting your bug number, just for the record.

There is an interesting edge case here, namely that 

NEDNSProxyProvider
is incompatible with Always-On VPN. That was a deliberate policy decision, with the idea being that, in the Always-On VPN case, all network traffic should go through VPN.

When you install an Always-On VPN configuration, the DNS proxy will stop with a message much like the one you’re reporting. However, it’s currently not possible to support Always-On VPN in a third-party VPN transport (r. 21363342), so I know that’s not the issue you’re seeing.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Quinn,


Thanks for the quick response. I believe that I am seeing expected behavior after all and that this is not a bug.


It turns out that the odd message that I cited was due to a development artifact that I had forgotten was in my code. I was running a standalone DnsProxyProvider and a standalone PacketTunnelProvider. Then, I added the DnsProxyProvider sources and entitlements to the PacketTunnerlProvider target (I wanted to see if I could include both providers in the same target). When I ran the updated PacketTunnelProvider target (with the embedded DnsProxyProvider), the old, standalone DnsProxyProvider configuration was closed - and the reason in the log message was quite accurate - the standalone DnsProxyProvider tool _was_ superseded by the DnsProxyProvider that was embedded in the PacketTunnelProvider.


I will say that I was surprised about the expected behavior though. I would have thought that the DnsProxyProvider would have a first chance at DNS queries and, if the DnsProxyProvider forwarded the query to a DNS server via UDP/TCP packet, then the PacketTunnelProvider would get a crack at it. It wasn’t obvious to me that the DnsProxyProvider would be skipped if the query was scoped to the VPN interface.


Thanks again for the quick response and sorry for the false alarm - I believe I am seeing expected behavior after all.


—Chris

Posted by
chofstaedter
Up vote reply of chofstaedter Down vote reply of chofstaedter
Add a Comment