Does "Connectivity Assist" bypass NEPacketTunnelProvider DNS interception on iOS 27?

Question

Created 1d

Replies 2

Boosts 0

Participants 3

We have a NEPacketTunnelProvider extension that intercepts and modifies DNS responses for specific hostnames as part of its normal operation.

On iOS 27, we are seeing this interception being intermittently bypassed. Our extension still receives the DNS query, builds a response, and returns it promptly, but the client occasionally proceeds using a different address, presumably the actual DNS resolution result.

This behavior does not reproduce on iOS 26 or earlier.

The timing in our logs appears to correlate with the new Connectivity Assist feature (Settings → Wi-Fi), which Apple describes as using cellular data alongside Wi-Fi to improve reliability. Our suspicion is that Connectivity Assist may be performing DNS resolution over a cellular path in parallel, outside the tunnel, causing that resolution path to bypass our provider entirely.

We have ruled out response timing and response format issues on our side. Varying the speed and format of our responses does not affect the outcome, suggesting that the behavior is occurring at a layer above the tunnel provider.

We have the following questions:

Does Connectivity Assist perform DNS resolution on a network path that can bypass an active NEPacketTunnelProvider?

Is there any API, entitlement, or supported mechanism to disable Connectivity Assist for an app, or to ensure that all DNS resolution is routed through the active tunnel, similar to previous Wi-Fi Assist opt-out capabilities?

Would a NEDNSProxyProvider-based DNS proxy be affected in the same way, or does it operate at a layer that Connectivity Assist cannot bypass?

Any guidance, references to relevant documentation, WWDC session content, or confirmation of the expected behavior would be greatly appreciated.

Answered by DTS Engineer in 903672022

NEPacketTunnelProvider … modifies DNS responses for specific hostnames as part of its normal operation.

To what end?

Most folks who run into problems like this do so because they’re trying to use a packet tunnel provider for something that isn’t VPN. That’s not something we support, for the sorts of reasons you’re seeing here. See TN3120 Expected use cases for Network Extension packet tunnel providers.

Would a NEDNSProxyProvider-based DNS proxy be affected in the same way … ?

I don’t know for sure, but I’d be surprised if that were relevant to you because most folks in this situation are using a packet tunnel provider because they don’t want to accept the deployment restrictions imposed by DNS proxy. See TN3134 Network Extension provider deployment.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 1

DTS Engineer OP

Apple

21h

Recommended

NEPacketTunnelProvider … modifies DNS responses for specific hostnames as part of its normal operation.

To what end?

Most folks who run into problems like this do so because they’re trying to use a packet tunnel provider for something that isn’t VPN. That’s not something we support, for the sorts of reasons you’re seeing here. See TN3120 Expected use cases for Network Extension packet tunnel providers.

Would a NEDNSProxyProvider-based DNS proxy be affected in the same way … ?

I don’t know for sure, but I’d be surprised if that were relevant to you because most folks in this situation are using a packet tunnel provider because they don’t want to accept the deployment restrictions imposed by DNS proxy. See TN3134 Network Extension provider deployment.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 2

twardakm2 OP

16h

We observe the same problem with NEPacketTunnelProvider. In our case we use it to block specific DNS from being resolved.

I tested different DNS servers, they respond in a different manner for a blocked domain, e.g.

NXDOMAIN
REFUSED
0.0.0.0
127.0.0.1

I noticed in cases (1-3), the system falls back to resolving the domain using cellular network (when Connectivity Assist is enabled). In case 4 it doesn't, but it's not something we want to do on the server side.

I reported Feedback to using Feedback Asistant: FB24536764. For me the current behavior, breaks the promise that the documentation makes:

https://developer.apple.com/documentation/networkextension/nednssettings/matchdomains?language=objc

If matchDomains contains the empty string it becomes the default domain. This is how a split-tunnel configuration can direct all DNS queries first to the VPN DNS servers before the primary DNS servers.

And

https://developer.apple.com/documentation/networkextension/nednssettings/allowfailover

I know for a fact that the system falls back to using Cellular connectivity, because I collected system logs and I see this clearly:

1 - original request correctly returns NoSuchRecord:
2026-08-27 08:12:50.898425+0200 0xf8d8     Default     0x0                  924    0    com.apple.WebKit.Networking: (Network) [com.apple.network:connection] [C265.1.1.1 Hostname#967e768c:443 failed resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good)] event: resolver:receive_dns @0.017s, error DNS Error: NoSuchRecord
2 - fallback DNS request starts
2026-08-27 08:12:50.898436+0200 0xf8d8     Default     0x0                  924    0    com.apple.WebKit.Networking: (Network) [com.apple.network:connection] [C265.1 Hostname#967e768c:443 in_progress fallback (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, fallback: {interface: pdp_ip0, agent: 108BFE0A-39C9-4F76-87A7-56A66107F5B3, opportunistic, generation: 589}, LQM: good)] event: fallback:start_fallback @0.017s
3 - fallback DNS requests returns correct domain:
2026-08-27 08:12:50.962099+0200 0xf8af     Default     0x0                  924    0    com.apple.WebKit.Networking: (Network) [com.apple.network:connection] [C265.1.2.1 Hostname#967e768c:443 in_progress resolver (satisfied (Path is satisfied), interface: pdp_ip0[lte], scoped, ipv4, dns, uses cell, LQM: minimal)] event: resolver:receive_dns @0.081s
4 - fallback DNS requests finishes
2026-08-27 08:12:51.165473+0200 0xf8af     Default     0x0                  924    0    com.apple.WebKit.Networking: (Network) [com.apple.network:connection] [C265.1 Hostname#967e768c:443 ready fallback (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, fallback: {interface: pdp_ip0, agent: 108BFE0A-39C9-4F76-87A7-56A66107F5B3, opportunistic, generation: 589}, LQM: good)] event: fallback:finish_fallback @0.284s

Also, I collected tcpdump from my iPhone and I see DNS request coming from my cellular IP address to a different DNS server from the one I have set.

So yeah, looks like Connectivity Assist could use some improvement before the final release.