Messages

Great, these screenshots help a lot.

Good news: your laptop is using the firewall's DNS only (192.168.20.1 on the wired link, wlan0 has no DNS scope). The 127.0.0.53 you saw earlier is just the laptop's local stub. Firefox DoH is off, so the browser follows the system DNS. IPv6 addresses in a DNS answer are normal: the DNS knows about them even if your network doesn't use IPv6.

A small command fix: with dig the server needs an @: dig @192.168.20.1 example.com. Without it, dig also looked up "192.168.20.1" as a name, which gives the NXDOMAIN you saw. Harmless.

DHCP: your PERSONAL20, XBOXS10 and GUEST30 ranges look right. The MGNT99 row has a start address of 192.168.99.10 and no end. That is exactly your laptop's static IP. Either delete that row (you use static IPs there) or set the range to 192.168.99.100–192.168.99.200 so DHCP can never offer .10.

What is still open: where the firewall's own DNS queries go. Please run dnsleaktest again (the extended test) and post the table with the ISP column readable, blurring only the IP column. If the ISP names are your own provider, the firewall's queries leave through the WAN. If they are Quad9 or the operators that serve it, it's fine.

And for the Xbox: please do the test with 1.1.1.1 set manually on the Xbox first (DNS vs tunnel MTU), as described before.

Sergio

Good progress, and thanks for all the screenshots.

1. About 127.0.0.53. That is not your firewall: it is the local DNS stub of your Linux laptop (systemd-resolved). It forwards to whichever DNS servers your connections give it. To ask the firewall directly, run: nslookup example.com 192.168.20.1 (and resolvectl status to see which servers each connection uses).

2. The leak test showing ISP-like servers. If the laptop is also connected via Wi-Fi to your ISP router, systemd-resolved can send queries to that router's DNS. Disconnect Wi-Fi (or any other connection), then run dnsleaktest again. Also check that your browser isn't using its own DNS (e.g. Firefox "DNS over HTTPS"). And check in Services > Dnsmasq DNS & DHCP that PERSONAL20 hands out 192.168.20.1 as the DNS server.

3. Proton gateway "active". That is fine. "(active)" only marks the default gateway, which is WAN. Your VLAN rules force traffic through Proton, as shown by "Proton End point" on the IP test. Only the firewall's own traffic uses WAN.

4. Xbox. One thing at a time: set the Xbox DNS manually to 1.1.1.1 (as on your phone). If the homepage and Game Pass load, the problem is DNS: check Services > Unbound DNS > Blocklists (disable them) and try disabling DNSSEC for a test. If it still doesn't load, it may be the tunnel MTU: on Interfaces > WgProtonVPN set MSS to 1380 and test again.

Please take a config backup before each change, and tell us the result of each step.

Sergio

Yes, there is a way to change them all at once, and the recommended way is a policy, not per-rule changes.

1. Policy (Services > Intrusion Detection > Administration > Policy tab)
– Add a policy, select the rulesets you want to act on (e.g. the ET ones you use), and set Action = Drop (and "New action" = Drop if your version asks for it).
– Policies are applied on top of the rules and survive ruleset updates, so you don't have to touch every rule.
– You can narrow it down by rule metadata (e.g. only "emerging-malware"), which is a good way to start with a small group of rules instead of everything.

2. Rules tab (alternative)
– In the Rules tab you can filter the list, select all the filtered rows with the checkbox in the header and use the buttons for the selected rules (Alert/Drop, if your version has them). This works for one-off changes, but a policy is easier to maintain.

3. Before enabling IPS mode
– IPS mode needs a network card driver that supports netmap. Disable hardware offloading (CRC, TSO, LRO) in Interfaces > Settings.
– Set IPS mode on the physical interface, not on a VLAN (check the docs: docs.opnsense.org/manual/ips.html).
– Don't switch all rules to Drop on day one: a dropped legitimate connection is hard to diagnose. Start with a few rule categories, watch the Alerts tab for a few days and widen later. Keep a config backup so you can go back.

Sergio

Yes, that is the right page, and that is the right rule: destination "This Firewall", port domain (53), no gateway. The order is fine too.

Proton: if the what's-my-IP site shows the Proton endpoint, your traffic goes through the tunnel, so that part works. It doesn't test DNS, though.

How to test DNS (from the laptop on PERSONAL20):

Open a terminal or command prompt and run nslookup example.com. The line "Server:" should show 192.168.20.1 (your firewall). If it shows something else, the laptop is not using your firewall's DNS.
Open dnsleaktest.com and run the extended test. It should show Quad9 servers, not your ISP's.
In OPNsense: Services > Unbound DNS > Log File, or Reporting > Unbound DNS. You should see your queries there.

DNSSEC, far gateway, DNS over TLS:
– DNSSEC enabled is fine; Unbound will validate the answers.
– "Far gateway" belongs to System > Gateways. As far as I know, it is normally needed for WireGuard tunnels where the gateway address is outside the tunnel subnet. Since traffic goes out through Proton, it is working.
– Your DNS over TLS entries look correct: 9.9.9.9 and 149.112.112.112, port 853, Verify CN dns.quad9.net.

Next: copy the DNS rule to XBOXS10 and GUEST30, and to MGNT99 if you want DNS from the management network. Then test the kill switch by disabling the WireGuard instance briefly: pages from the VLANs should stop loading.

Sergio

Thanks, these screenshots answer most of my questions.

Confirmed:
– VLAN tags 10/20/30/99 match your switch. Good.
– Your PERSONAL20 "via Proton" rule has gateway Proton_Gway and sets the local tag NO_WAN_EGRESS, so your kill switch is built correctly. We'll test it at the end.
– Domain (53) is the right port for the test rule, and Gateway = None is right.

A correction from me: I told you to add "Localhost" in Unbound. I see now that this list has no such entry, so please ignore that. Keep the four VLANs selected, and no, don't add LAN (it has no IPv4 address).

One thing to check: on the new DNS rule, Destination must be "This Firewall" and Source "PERSONAL20 net". The dropdown covered those fields in your screenshot. If Destination is "any" with Gateway None, DNS queries could leave outside the tunnel without the kill switch tag. Please post a screenshot of the Source and Destination part of that rule.

Order: if it works below the block rule, leave it there. I can't tell why it failed above it; if you want to find out, post a screenshot of the rule list after moving it.

Next steps: if DNS works on PERSONAL20, copy the same rule to XBOXS10 and GUEST30. Then test the kill switch: disable the WireGuard instance for a moment (VPN > WireGuard), try to load a page from PERSONAL20 (it should fail), and enable it again.

Sergio

Thanks for the extra screenshots, they help a lot. The upload quality is low, so please correct me if I misread something.

A correction first: I earlier said your KSWITCHENGAGE rule looked like an inbound block. Now I see it is a floating rule on WAN, direction Out, Block, matching the local tag NO_WAN_EGRESS. That is a proper kill switch design. For it to work, your "via Proton" rules on the VLANs must set that tag ("Set local tag" in the rule, Internal tagging section). Can you check one of them and post a screenshot of that section?

Where I think things went wrong (one thing at a time):

DNS for the VLANs. I don't see any rule that allows DNS (TCP/UDP port 53) from XBOXS10, PERSONAL20 and GUEST30 to "This Firewall". MGNT99 only allows https to the firewall. If your clients get the firewall as DNS server via DHCP, their queries are dropped. As a first test, add on PERSONAL20 only: Pass, TCP/UDP, source PERSONAL20 net, destination "This Firewall", port 53, above the other rules. Then test DNS from a device on that VLAN. If it works, copy the rule to the other VLANs.
Unbound and 127.0.0.1. Under Services > Unbound DNS > General, Network Interfaces shows only GUEST30, MGNT99, PERSONAL20, XBOXS10. "Localhost" is not selected. That may be where 127.0.0.1 got lost: the firewall itself cannot use Unbound without it. Please don't change it yet, we'll come back to it after step 1.
VLAN IDs. On the switch you use VLAN 10, 20, 30, 99, and the port settings look consistent. In OPNsense the devices are named vlan01, vlan02, vlan03, vlan09. Please check under Interfaces > Devices > VLAN that the VLAN tags are really 10, 20, 30, 99 and the parent interface is the one connected to switch port 1.
Updates. Traffic from the firewall itself is not tagged NO_WAN_EGRESS, so the kill switch should not block it. But your system DNS servers are set to use the Proton gateway, so lookups (and update checks) go through the tunnel. If the tunnel is down, updates will fail. That is your choice: keep it if you want everything in the VPN, or leave the gateway empty for one DNS server if you want updates to work without the tunnel.

And about ChatGPT: you are right that setups built from partial advice are hard to untangle. Take a backup of config.xml now, and let's go step by step.

Sergio

Great 👍

Port forwarding through a VPN on OPNsense usually fails in one of three places. Let's check them in order, so you can see where the packets stop:

1. Does the traffic arrive at all?
From a machine OUTSIDE your network (e.g. phone on mobile data, not the LAN – NAT reflection would confuse the test), try to reach the AirVPN IP on port 45678. At the same time open Firewall > Log Files > Live View and filter on destination port 45678.
– Nothing shows up: the problem is on the AirVPN side. Check in their client area that the port is TCP, assigned to your account, and forwarded to IPv4.
– It shows up as blocked: go to step 2.
– It shows up as passed: go to step 3.

2. Port forward and firewall rule (Firewall > NAT > Port Forward)
– Interface: the AirVPN WireGuard interface (the one the traffic arrives on, not the Plex VLAN).
– Protocol: TCP. Destination: the interface address of the AirVPN interface (or "any"). Destination port: 45678.
– Redirect target IP: 10.20.30.40, target port: 32400.
– Filter rule association: "Add associated filter rule" (or create the pass rule yourself on the AirVPN interface: TCP, destination 10.20.30.40, port 32400).

3. Replies must go back through the tunnel, not out the WAN
The Plex VLAN has a policy-routing rule with AirVPN_GW, which is good for outgoing traffic. For replies, check that the rule created in step 2 does not have "disable reply-to" set, and that the WireGuard interface has its gateway assigned (System > Gateways). Packet capture (Interfaces > Diagnostics > Packet Capture) on the WireGuard interface and on the Plex VLAN, port 45678 / 32400, shows whether the replies leave through the wrong interface.

Also: outbound NAT for the Plex VLAN through the AirVPN interface must be in place (Firewall > NAT > Outbound), otherwise the Plex server cannot reach the Internet through the tunnel.

If it still fails, please post: (a) a screenshot of your NAT port forward rule, (b) the Live View lines for port 45678, (c) the result of a packet capture on the WireGuard interface.

Sergio

Thanks, the screenshots help. A few observations, but let's do one thing at a time:

You're reaching the GUI on 192.168.99.1 (MGNT99), so you're not locked out anymore, correct? Please back up config.xml now (System > Configuration > Backups) before changing anything else.
Interfaces > Assignments shows no IPv4 on LAN. Is that intentional (LAN only as parent for the VLANs), or did you remove it?
I don't see a rule allowing DNS (TCP/UDP 53) from XBOXS10, PERSONAL20 and GUEST30 to "This Firewall". If your clients use the firewall as DNS server, that traffic is blocked. Which DNS server do those VLANs get from DHCP?
The rule "KSWITCHENGAGE" on WAN looks like an inbound block rule. That is not a kill switch (WAN already blocks inbound). We can do the kill switch last.
About 127.0.0.1: please check System > Settings > General (DNS servers) and Services > Unbound DNS > General > Network Interfaces (Localhost should be selected) and tell me what you see.

Which problem is the most urgent for you right now: no DNS on the VLANs, or no traffic through Proton?

Sergio

Thanks for the details, that helps. I'd fix one thing at a time, and the first one is getting stable access to the web UI again. I suspect it is a firewall/interface issue and not dnsmasq: if it works after "pfctl -d", then "pfctl -e", and stops later, existing connections survive but new ones are blocked.

Please, before changing anything else:
1. Save a backup of config.xml if you can reach the GUI (System > Configuration > Backups).
2. From the PC on switch port 1, tell me which IP the web UI answers on, and screenshot Interfaces > Assignments (IPs of LAN and of each VLAN).
3. Screenshot Firewall > Rules > LAN (and the rule list of the VLAN you use for management).
4. Tell me exactly what you changed when you "removed 127.0.0.1" (which page, which field).

The WireGuard kill switch, the DNS over the tunnel and the four VLANs come later, one at a time. The kill switch should be the very last step.

Sergio

Thanks for the feedback, and fair point: manual creation is only a stopgap, not a real solution.

The feature request is now tracked here: https://github.com/opnsense/core/issues/11142
If you can, please add your own use case there (DC/DR pair, same alias name with different content per site, your Source NAT example with "AddOn_IP"). A concrete case from another user helps the developers judge the need.

Hi,

Don't give up yet. The usual way out is to go back to a simple setup and add one thing at a time, checking each step before the next:

1. Start with no VLANs at all: WAN on one port, LAN on another, the PC directly on the LAN port. Make sure you get an IP by DHCP and can browse the internet. For DNS, use only ONE service at the start (Unbound, which is the default) and leave the DHCP/DNS settings as they are out of the box.
2. Only then add the VLANs. On a TP-Link TL-SG108E remember it is not enough to put the port in a VLAN: you usually also need to set the PVID of the port. Keep one port untagged on the default VLAN as a safe way back into the web UI.
3. Only after that add WireGuard. WireGuard itself does not depend on VLANs, it needs a working WAN, a firewall rule that allows its UDP port on WAN, and a rule on the WireGuard interface.

To help you better it would be useful to know:
- What do you want WireGuard for: reaching your home network from outside, or sending your traffic through a VPN provider?
- Is your OPNsense behind the ISP router (double NAT) or directly on the internet?
- How many network ports does the mini PC have, and which one is WAN and which is LAN?
- Which OPNsense version are you running (System > Firmware)?

Also, a backup of config.xml (System > Configuration > Backups) before each big change means you never need to reinstall from scratch.

Sergio

Thanks Franco. Ticket opened: https://github.com/opnsense/core/issues/11142

Hi,

As far as I know there is no per-alias "No XMLRPC Sync" flag today. The "No XMLRPC Sync" option exists on some items (like Virtual IPs), but aliases are synced as one whole section.

A workaround that may fit your DC/DR case:

1. On the master, go to System > High Availability > Settings and untick "Aliases" in the list of items to sync.
2. Create the same alias names on both nodes, with different content on each (for example AddOn_IP).
3. Keep syncing the firewall rules and NAT as before. They only refer to the alias name, so they work on both nodes with the content of each node.

The price is that you must maintain all aliases by hand on both nodes. If you only need a few aliases to differ, you could keep these as local aliases and give them a clear name, so nobody forgets they are not synced.

I have not tested this on the latest version, so please try it first on a test pair. Since this is really a feature request (a per-alias flag), it may also be worth opening an issue on the OPNsense core GitHub repository, where the developers will see it.

Sergio

Hi babagoo, thank you, this information helps a lot.

Again, this is my best guess and not a sure answer, because I have not tested your setup.

What you describe looks like a problem on the Wi-Fi link, not a problem of CARP and not of the router. Your host reaches IPv6, and the router gives IPv6 to other devices, so the router seems fine. Only the firewall in the virtual machine gets an address but cannot go out.

This is typical when a virtual machine is bridged over a Wi-Fi card. A Wi-Fi connection normally accepts only one hardware address, the one of the host. IPv4 often still works because VMware translates it, but IPv6 often fails, because devices cannot find each other on the local link. The firewall can receive an address from the router, but the answers do not come back to the virtual machine. Your update worked over IPv4, and this fits the same picture.

Things to try, in this order:

1. If you can, connect the host with a cable, or use a USB Ethernet adapter, and bridge the virtual machine to that. This is the cleanest test. If IPv6 then works, the cause is the Wi-Fi bridge.

2. To confirm before changing anything: from the firewall, ping the local address of the router, the one that starts with fe80. If it does not answer, the problem is at link level. If it answers but a public IPv6 address does not, then check that the firewall has an IPv6 default gateway and look at the firewall rules.

3. If you must stay on Wi-Fi, for a lab it is fine to use only IPv4 on the WAN of the firewall, and to use IPv4 DNS servers in the system settings.

I do not know the ZTE U50 well, so I cannot say if it has a setting that blocks this. If the cable test does not solve it, tell me what you see and we can think about it again.

Sergio