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

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"

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

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. (Fortunately you @ mentioned me, otherwise I would’ve never seen this.)

Do you know if it's still true that NEDNSProxyProvider is incompatible with Always-On VPN?

This has not changed. When the Always On VPN [1] session activates, it specifically stops any existing sessions with the reason NEProviderStopReasonSuperceded. This includes sessions for normal VPN, Personal VPN, DNS proxy, and content filter.

AFAICT this interaction isn’t documented in the Apple Platform Deployment guide, and I encourage you to file a bug against the doc to improve that.

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"

[1] Hmmm, sometime in the last 9 years Always On VPN lost its hyphen.