iPhone App Can't Find Local Devices While the VPN Is On
Two gates decide whether an iPhone app can reach a printer or TV over a VPN: the Local Network grant and the tunnel's own routes. Check them in order.
Your printer app shows an empty list, the camera app reports no device found, and the cast button in a video app spins until it gives up. The VPN icon sits in the status bar, the phone has full signal, and Safari loads pages fine, so nothing about the connection looks broken. Then you open the app’s own settings and find nothing to toggle.
I hit exactly this wall with a label printer on a home network: the app had never been granted local network access, and the profile I was testing was a full tunnel that swallowed every packet addressed to 192.168.1.0/24. Two independent gates were shut, and opening one would not have cleared the symptom.
Two gates sit between one app and one printer
Gate one is a privacy decision that belongs to the operating system rather than the app. iOS decides whether an app may send traffic to addresses on the local network, and it asks the user the first time the app tries. Gate two is the route table. A packet aimed at 192.168.1.50 either leaves over Wi-Fi toward the printer, or it enters the tunnel, and that choice is written in the VPN profile.
The two gates fail with different shapes, which is what makes the diagnosis possible. A denied permission kills the app’s own socket call, so the app has nothing to report and falls back to a generic empty state. A routing problem looks like a timeout, because the packets left the phone and died somewhere on the far side. Same blank screen, different repair.
Read the permission state before touching the VPN
Open Settings, then Privacy & Security, then Local Network. Every app that has requested access appears there with a switch. Apple has moved and relabelled pieces of this screen across iOS 14 through iOS 18, so if the entry is not where you expect it, type Local Network into the Settings search field instead of hunting through the tree.
The part that catches people is the one-time prompt. iOS asks when an app first touches the local network, and only then. Tap Don’t Allow and the prompt does not return on the next launch; the switch is the only way back, and it starts off. Reinstalling the app resets the decision, which is why some troubleshooting threads claim that a reinstall fixed discovery. It did, by clearing the denial.
On a supervised or managed iPhone the switch is sometimes greyed out. A privacy preferences payload pushed by MDM can pre-set or lock local network access, and a locked switch that is off means the repair is a policy change rather than a phone change. Apple documents the prompt and the per-app switch here: support.apple.com/en-us/102229.
Check what the tunnel actually routes
A full tunnel takes 0.0.0.0/0 and, with it, every private range. Packets for 10.x, 172.16.0.0/12 and 192.168.x.x travel to the server, which usually drops them or translates them into its own subnet, so the printer is unreachable even after you grant permission. A split tunnel does the opposite, but only for the ranges the profile lists.
IKEv2 profiles built with Apple Configurator or shipped as a .mobileconfig express this as a send-all-traffic setting plus, when split, an explicit list of local networks to exclude. Client apps built on NEPacketTunnelProvider express the same decision through includedRoutes. Neither is visible from the status bar, and both override what the app expects to see.
Here is the read I use. With the VPN connected, open the router’s admin page by its LAN address in Safari. If public sites load while that page times out, your private range is inside the tunnel. If the page loads, local traffic is still leaving over Wi-Fi and the block is somewhere else.
Map the symptom to the gate
Two apps on the same phone can disagree, because permission is granted per app while routes are granted per profile. Compare what fails before changing anything: the pattern usually names the gate on its own.
| What you see | Gate | Next step |
|---|---|---|
| Device list stays empty, Local Network switch is off | Permission | Enable the switch, force-quit the app, reopen it |
| Switch is on, router page times out, public sites load | Routing | Exclude the local range in the profile, or move to a split tunnel |
| Both pass, direct IP works, discovery stays empty | Link-local multicast | Enter the device address by hand, or check profile discovery support |
| Works by IP address, never by name such as printer.local | Name resolution | Fix mDNS reachability or use the numeric address |
| Everything fails with the VPN off, on hotel Wi-Fi | Client isolation | Change network, do not change permissions |
The mDNS row deserves a note. Discovery traffic for Bonjour and most casting protocols is multicast to 224.0.0.251 and ff02::fb with link-local scope, and a routed tunnel does not carry it. That is why a device can answer a direct connection while never appearing in a list.
Test the operation, not the icon
After flipping the Local Network switch, force-quit the app from the app switcher and start it again. A running process can hold the denied state from before the change, and an app that keeps returning an empty list looks identical whether the grant worked or not. Then run one concrete action, such as printing a test page or starting a video, rather than watching for a device list to populate.
Keep the VPN profile fixed across the comparison. If discovery starts working only after you disconnect, you have learned that the tunnel is at fault, not the permission. Change one variable per attempt, otherwise the next run tells you nothing.
Fix it in this order
The sequence below is the one I now follow, because it never leaves a phone in a half-changed state where the next test is unreadable.
- Confirm the app is listed under Privacy & Security, Local Network, and that its switch is on.
- Force-quit and relaunch the app, then retry the real operation once.
- Open the router page by LAN address while connected to prove whether the private range is tunneled.
- If it is tunneled, edit the profile to exclude the local networks, or ask whoever owns the profile to do it.
- If the switch is greyed out, treat the device as managed and route the request to the administrator.
Only one of these usually applies. If none of them changes the result, the remaining suspects are the network itself, such as access point isolation or a client allowlist keyed to Wi-Fi addresses, and the mapping table above points at which one.