Phone VPN to Home: Making the Firewall Your Internet Exit

Connecting a phone to the home tunnel and opening a LAN file share proves the tunnel works. It does not prove the phone's internet requests leave through the house. The difference between those two outcomes is a forwarding policy plus a route, not another checkbox on the phone. It is also the difference most people assume they have already configured.

Three decisions produce the egress path: what the phone sends into the tunnel, where the home gateway forwards it, and what happens when the tunnel is not there. Each has a failure mode that looks like the others from the phone's screen.

Two hops, two policies

The outer connection ends at the home VPN listener. The inner packet is a separate object that has to be forwarded somewhere, and forwarding is a different firewall decision from accepting the tunnel in the first place.

phone app -> encrypted tunnel -> home listener
          -> decrypted packet -> forward policy -> home uplink -> destination

On a typical home router these live in different rule sets. Accepting the tunnel is input policy on the VPN interface; sending the phone's traffic out to the internet is forward policy plus whatever source translation the uplink needs. A router that accepts the tunnel and forwards nothing produces a phone that shows connected and loads no pages.

If the VPN service runs on a separate machine inside the house, add a hop. The router now sees traffic arriving from that machine, so its rules apply to the server's address rather than to the phone's tunnel address, and source translation can make every phone look like one host.

The listener is not the filter

Decide where enforcement happens while the information you need still exists. On the router, the phone's tunnel address is visible and can be matched directly. Behind a second translation, it is gone, and rules written for the phone's address silently match nothing.

This is the usual reason a policy works for the laptop and not for the phone. The laptop connects to the router directly, the phone connects to a server that forwards through the router, and only the first path preserves the address the rule expects. The rule is not wrong; it is matching a value that no longer exists at that point.

Write the path down with the source address as it appears at each enforcement point. That single diagram resolves most of these cases before any rule is edited.

What the phone must actually send

A phone that only receives a route to the home subnet sends only that subnet's traffic into the tunnel. Everything else leaves over the mobile network, which is why the file share works and the internet requests never reach the house.

Full-tunnel coverage is a client-side routing decision, and it has to be set with the platform's supported mechanism rather than assumed from the profile being installed. Once it is set, the route back to the VPN server itself must stay outside the tunnel, or the client cannot maintain its own transport.

DNS deserves its own decision, because it is the part most likely to diverge from the rest of the traffic. A resolver address in the profile is a suggestion that clients handle differently, and an application with its own encrypted resolver can take a completely separate path. If the home policy depends on queries reaching a particular resolver, enforce it where the traffic actually passes, or accept that some queries will not. A query that bypasses your resolver never reaches a rule written for it.

IPv6 belongs in the same paragraph as DNS, not in an appendix. An IPv4 full tunnel says nothing about AAAA traffic, and a phone on a dual-stack mobile network will happily use the native path for it. Choose carriage or blocking explicitly.

What the firewall can and cannot see

The gateway can act on what its enforcement point exposes: addresses, ports, protocol, interface, and the metadata of the connection. A forwarded HTTPS request does not hand over the page body or the password merely because it crosses the home tunnel.

That limit is worth stating because the phrase "route it through the firewall" implies more inspection than a home router performs. A destination rule, a DNS policy and an application-layer proxy are three different controls with three different deployment costs.

Do not assume that a feature configured for home-LAN clients applies to the VPN interface. Zone membership is a configuration choice, and a VPN interface that is not in the right zone inherits none of the rules you tested from the couch.

Decide the disconnected state

When the tunnel is unavailable, the phone either falls back to the mobile network or refuses to send the traffic. Both are reasonable, and only one of them matches what most people believe they configured.

Fallback is convenient and leaks by definition: the moment the tunnel drops is the moment requests leave over the carrier path. Blocking is stronger and makes the phone dependent on the house being reachable, which is a real availability cost for someone travelling. Neither behaviour is a bug; both are products, and you are choosing between them whether or not you say so.

Test the choice rather than assuming it. Stop the home service, then try one request from the phone's browser and one from an app that runs in the background. Reconnecting later does not undo the requests that already left.

Finish with two controlled checks from the phone itself: one allowed operation that should traverse the house, and one denial the home policy is supposed to enforce. Confirm the gateway logged the flow you expected, in the address family you expected, after a reconnect. A phone showing Connected is the beginning of that verification, never the end of it.