Bridged VPN hotspot: which default route does the phone use?
The Pi's default route is not the phone's gateway. Separate the two decisions, keep the uplink out of the bridge, and test the lease before the tunnel.
The phone on your bridged hotspot gets its address and its gateway from somewhere, and it is not the Pi's default route. Changing the Pi's default changes where the Pi sends its own traffic. The phone keeps using the gateway it was told about, and when that gateway sits on the remote LAN its frames simply cross the bridge. Two consumers, two decisions. Separating them explains most reports of a hotspot with no internet while the Pi itself is fine.
Two devices, two different gateway decisions
The Pi has an IP stack and a default route of its own. The phone has an IP stack and a default route of its own.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
That table is the whole model. The phone's gateway is an address on the remote LAN, and its frames are forwarded at layer 2 toward that router. The Pi's default route concerns the Pi's own outer transport, which has to reach the VPN peer over the travel uplink.
A bridge forwards frames, it does not route packets
A Linux bridge forwards Ethernet frames by destination MAC, and that is all it does between its ports. The phone's frame addressed to the remote router's MAC is switched onto the TAP port and crosses the tunnel without touching the Pi's routing table. That is why a broken Pi default route can leave the phone working, and why a correct one cannot fix a phone that was handed the wrong gateway.
TAP carries Ethernet frames and can be a bridge port. TUN carries IP packets and cannot. If your design substituted one for the other, the bridge is not a bridge and the rest of this does not apply.
Decide who hands out the phone's lease
DHCP option 3 is the router option, and it tells the client which gateway to use for its subnet. When the remote LAN's DHCP server is the only allocator, the phone gets a remote gateway and the design is consistent. When something else on the travel side answers first, the phone gets a local gateway, its internet traffic leaves through the travel uplink, and its remote-LAN traffic has no path at all.
Run one allocator for that broadcast domain, and record what it hands out.
The Pi is a separate case even when it takes an address from the same lease. Decide deliberately whether it should install the routes that lease offers, because an imported remote default can drag the Pi's own VPN transport into the tunnel it is trying to keep alive. With systemd-networkd that decision is UseRoutes= under the DHCP section; with dhclient it is the routers option in the request list.
Keep the uplink outside the bridged LAN
The interface that carries the Pi's outer VPN connection must not become a bridge port. If it does, the encrypted transport is switched into the extended LAN and the tunnel ends up carrying its own outer packets, which fails in a way that looks like packet loss rather than a loop. Keep AP capability and bridge support explicit too. A wireless interface in station mode usually cannot be a bridge port, because the 802.11 header has no room for the second MAC address a bridge needs.
Define the extended broadcast domain, one address plan, and the frame filtering you actually want. Allowing the VPN listener on the Pi does not grant every bridged client access to the Pi's management services. Those are separate rules, and treating them as one is how a hotspot quietly becomes an open door.
Test the four things separately when it breaks
When the phone cannot reach the remote LAN, four observations separate the causes. Run them in this order and stop at the first one that fails.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpStart with the lease: does the phone hold an address and a gateway on the remote subnet? Then look at the bridge, and confirm the AP port and the TAP port are both forwarding. Then read the neighbour table, because an unresolved entry for the remote router means frames leave and nothing answers. Finally watch frames on the bridge while the phone pings, which tells you whether the fault is below IP at all.
Record which device owns each default when you are done. One line of documentation turns local versus remote egress into a deliberate client decision, and the bridge reference is worth keeping next to it.