VLAN with dedicated VPN tunnel, DNS isolation, and kill switch — best practice?
-
Hey :)
I’m working on a more advanced homelab setup and would really appreciate some insight from people who’ve built something similar.
My environment:
- pfSense CE 2.7.2 (with DNS Resolver + pfBlockerNG-devel)
- Proxmox VE 9.0 as Homeserver
- Several VLANs, all segmented through pfSense
- One VLAN should be fully isolated: its own VPN tunnel, its own DNS resolver, and a complete kill switch (if VPN goes down → nothing at all)
Goal:
- Only this specific VLAN should go out through a WireGuard VPN tunnel.
- All other VLANs should use the normal WAN connection.
- If the VPN tunnel fails, the isolated VLAN must lose all connectivity — including DNS, NTP, everything.
- No DNS leaks, no fallback to WAN.
What’s already clear / working:
- VLAN segmentation and isolation (for every VLAN besides the VPN one)
- Policy routing through the VPN gateway
- “Skip Rules When Gateway Is Down” in pfSense = working kill switch (+ Kill States on Gateway)
- DNS redirect on port 53 to pfsense resolver works for VLANs besides VPN VLAN (NAT Forwarding Rules from Pfsense Docs)
Where I’m stuck:
The DNS Resolver (Unbound) on pfSense obviously uses WAN as its outgoing interface, since every other VLAN relies on it.
But I need my VPN VLAN to avoid that otherwise its DNS traffic bypasses the VPN.
I can’t just change Unbound’s outgoing interface to VPN globally, since that would affect all other networks.
pfSense doesn’t support per-VLAN outgoing interfaces for Unbound, so I’m looking for a clean, maintainable workaround.My current ideas:
-
Separate DNS VM inside the VPN (cleanest option?) A small Proxmox VM running unbound or dnsmasq, with its upstream DNS going through the VPN tunnel.
pfSense NAT redirect (port 53) on the VPN VLAN → this VM. If the VPN drops, DNS resolution fails too — perfect kill effect.
→ Seems like the most isolated and deterministic setup. -
Unbound on pfSense with both WAN and VPN as outgoing interfaces. Let pfSense decide dynamically which path to use. Might technically work but feels a bit unpredictable.
-
Redirect DNS directly to the VPN provider’s DNS. Simplest route, but I’d lose pfBlockerNG filtering for that VLAN.
So:
How would you approach this? Are there any known best practices or gotchas? Has anyone here successfully used a dedicated DNS VM inside the VPN for one VLAN? Is there any way to keep pfBlockerNG filtering for that VLAN if its DNS path is outside pfSense’s resolver? Or would you rather keep everything centralized on pfSense and accept some compromise?
I’d love to hear from people who’ve built or tuned setups like this real-world experiences, rule examples, or design feedback are all welcome.
I’m not chasing theory just looking for a reliable, leak-proof way to run one VLAN through a VPN with isolated DNS and a guaranteed kill switch.ChatGPT helped me to format this post.
-
@OsiMosi said in VLAN with dedicated VPN tunnel, DNS isolation, and kill switch — best practice?:
The DNS Resolver (Unbound) on pfSense obviously uses WAN as its outgoing interface, since every other VLAN relies on it.
But I need my VPN VLAN to avoid that otherwise its DNS traffic bypasses the VPN.
I can’t just change Unbound’s outgoing interface to VPN globally, since that would affect all other networks.
pfSense doesn’t support per-VLAN outgoing interfaces for Unbound, so I’m looking for a clean, maintainable workaround.What about :
Use the DNS forwarder to listen on this 'isolated' interface (a LAN or a VLAN).
Select the interface to be used - test also with 'Strict binding' set.
With some luck (you reading the dnsmasq manual) you might find the custom option where you 'force' dnsmasq to use a fixed outgoing interface = the VPN uplink.Use unbound for the other interfaces.
edit : If this works, you've separated DNS usage, so you can use pfBlockerng for your own needs, and have the isolated network 'have it all'.
I'm not tested all this. Neither consulted any AI.
-
@Gertjan said in VLAN with dedicated VPN tunnel, DNS isolation, and kill switch — best practice?:
What about :
Use the DNS forwarder to listen on this 'isolated' interface (a LAN or a VLAN).
Select the interface to be used - test also with 'Strict binding' set.
With some luck (you reading the dnsmasq manual) you might find the custom option where you 'force' dnsmasq to use a fixed outgoing interface = the VPN uplink.Use unbound for the other interfaces.
edit : If this works, you've separated DNS usage, so you can use pfBlockerng for your own needs, and have the isolated network 'have it all'.
I'm not tested all this. Neither consulted any AI.
Your idea sounds simple and interesting! I hadn’t really thought about running the resolver and forwarder side by side without conflicts, and then using the forwarder just for a specific VLAN. I’m currently collecting different approaches in various forums and most people so far have focused on VM-based solutions. I’ll definitely take a closer look at your suggestion. PfBlockerNG can cover both (Resolver and Forwarder) then?
-
@OsiMosi said in VLAN with dedicated VPN tunnel, DNS isolation, and kill switch — best practice?:
PfBlockerNG
... can only interface with unbound. So your private DNS needs are covered/handled by PfBlockerNG, not polluted with the isolated network DNS requests, which are handled by dnsmasq.
