How I’d build an Android-to-homelab firewall and DNS split before swapping phones
I would not trust a phone migration to expose my whole homelab in one go. I would split Android traffic first, pin DNS to known resolvers, and treat app access as a privilege, not a given.
Objective
My goal is simple. My Android phone keeps working, but it stops seeing anything on the homelab that does not need to be reachable. I want DNS filtering on the phone’s own traffic, clear firewall rules on the edge, and VLAN isolation for anything noisy or sketchy on the local network.
Success for me is boring, which is ideal. The phone resolves the right names, private DNS stays on, smart home app access works only where I allow it, and nothing on the main LAN can poke back at the phone unless I have opened that path on purpose.
Requirements
I start with one rule: the phone gets its own network segment. A separate Wi-Fi SSID mapped to a VLAN is the cleanest way to do that. If the access point cannot tag VLANs, I fix that first or stop pretending the rest will be tidy.
I want three things from the setup. First, DNS filtering that I control. Second, firewall rules that block lateral traffic by default. Third, enough local access for the boring stuff, such as casting, printer discovery, and whatever smart home app still refuses to behave like a normal client.
On the non-functional side, I care about failure modes. If DNS dies, the phone should fail closed, not silently fall back to whatever random resolver it fancies. If the VPN is off, private DNS should still point at a resolver I trust. If I swap phones, the rules should follow the network, not the handset.
Design
I would put the Android phone on its own VLAN, say VLAN 30, and keep the main homelab on another, say VLAN 10. The firewall sits between them and allows only what is needed. Outbound from the phone VLAN goes to the internet, but with DNS forced through a filtering resolver I run or control. Inbound from the main LAN to the phone VLAN stays blocked unless there is a reason to open it.
For Android, I would use Private DNS with DNS-over-TLS. That gives me a fixed resolver path on the handset. If I run my own DNS filter, I point Android at that hostname. If I use a hosted filter, I still pin the setting so the phone does not wander off to public DNS when it feels helpful.
The clean bit is separating name resolution from app reachability. DNS filtering handles domain-level control. Firewall rules handle IP and port control. VLAN isolation keeps chatty devices away from the phone, which matters when a cheap camera starts making assumptions about the rest of the network.
For smart home app access, I would only allow the ports and hosts that the app truly needs. If discovery breaks, I would rather add one targeted rule than open the whole subnet and call it a day. mDNS and broadcast traffic can be bridged selectively if required, but I would keep that narrow.
Implementation
I would build it in this order.
- Create the VLAN and SSID for the phone.
- Set the DHCP scope for that subnet.
- Force DNS from that VLAN to my resolver.
- Block direct access from the phone VLAN to the main LAN.
- Add only the firewall rules needed for app access and admin access.
- Set Android Private DNS to the chosen hostname.
- Test from the phone before moving anything else over.
I would use explicit firewall rules, not vague “allow local” nonsense. If the phone needs to reach Home Assistant on one port, I allow that port. If it needs DNS to one resolver, I allow only that resolver. If it needs NTP, I allow NTP. Everything else stays shut.
I would also stop local DNS leakage. If the router hands out itself as DNS, but forwards elsewhere, that still leaves room for odd behaviour. I prefer the phone VLAN to point straight at the resolver I intend to use, with all other DNS egress blocked at the firewall.
Testing
I test from the handset, not from a desktop pretending to be helpful.
I check that Android reports the expected Private DNS hostname. I confirm name resolution for a domain that should pass and one that should fail. I try to open a host on the main LAN and make sure it is blocked. I open the smart home app and see which calls fail, then I add only the missing rule.
I also test what happens when I disable Wi-Fi and rejoin the SSID. If the phone gets an address, resolves DNS, and still cannot wander into the rest of the homelab, the setup is doing its job. If it can see everything, the firewall rules are too broad and need tightening.
Deployment
I would do the phone swap last. First the VLAN, then DNS, then firewall, then app access, then the handset migration. That keeps the blast radius small.
Before moving SIMs, accounts, and app logins, I would export the current Android settings I care about, such as authenticator backups, Wi-Fi configs, and any app-specific recovery codes. If the old phone is still alive, I keep it unchanged until the new one has been tested on the restricted network.
The rollout stays staged. One SSID. One phone. One resolver. One set of firewall rules. If something breaks, I know which layer did it.
Monitoring & Maintenance
I would log DNS queries and firewall denies for this VLAN. Not because I enjoy staring at logs, but because broken app access and stray lookups are easier to fix when the evidence is there.
I also review the allow list after each app update. Phone apps love changing their habits without asking. If a new domain or port appears, I decide whether it is needed or just more nonsense.
The setup is never finished. I would keep a short note of every exception, every opened port, and every oddity the phone needs. Six months later, that note saves a lot of swearing.
