Messages

Hi Guys,

I wanna share my experience with FS and why i've decided to abandon them and use flexoptix .
Ive bought 20 SFP+ ethernet from FS because they claimed they were able to recorded a specific vendor. The SFP arrived and didnt worked at all.
They shipped to me a magic box to change the eprom myself... after a lot of troubleshooting with their engineering they were able to make it work but with the eprom as Fiber....
Unfortunately this is not ok for myself and my customer and when we tried to ship it back they didnt accepted.
So... I cant buy from them like that.
Ive changed to flexoptix (https://www.flexoptix.net/en/transceiver) where they shipped to me the transceiver and also their magic box (that was not needed, because the transceiver came programmed and working as ive asked).

With that being said, i would change to another supplier to double check if it will work.

The cable we are using is a 2 fibers LC UPC Duplex to LC UPC Duplex OS2 (link : https://www.fs.com/fr/products/40384.html?attribute=103594&id=3704291)

I checked to make sure the cables are connected properly and not reversed.
There is only one way to connect them to the transceiver.

It's most probably the single mode fiber cable but from our understanding it only depends on the use of your communication.
But we are likely wrong if most of you ask this question.
If that is indeed the problem, what is the explanation?
What did we misunderstand about multi-mode and single-mode cables?

As soon as possible, I'll try using a multi-mode cable to run the test and post an update here.

What Mikrotik switch model is it and does the Mirotik switch also show the correct information about the transceiver?

The switch does show the correct information about the transceiver
The Mikrotik we have is a CRS354-48G-4S+2Q+ (link :https://mikrotik.com/product/crs354_48g_4splus2qplusrm)

Edit : Is it normal for the transceiver displayed on the Mikrotik switch to be the OPNsense transceiver (SFP-10GSR-85) even though the SFP+ module connected to the switch is actually the other one ?

I have read a lot about MikroTik products having issues with certain SFP/SFP+ modules in the past so the first thing I would look at is any recent Firmware Change Logs mentioning any kind of issues and see if they match your situation.

Fortunately, I can't find any logs that point in that direction

Need to ask to the seller with the 10GB module comes together .

https://ebay.us/m/Hrxtgt

Thanks.  I hadn't heard of Silver Peak.  Looking on Ebay, I don't see any mention of 10G ports nor SFP+ ports however.

Hey Mate,

Not sure if that would help you, but i've bought a EC-S (silver peak) on ebay, with interfaces 10gb and reused it with opnsense. Im extremelly happy with opnsense and im using my 3 gateways with wireguard for 1 month and no issues.
Im running all kind of plugins, ids/ips, zenarmor, avocado, papaya and i just have 20% of memory used.

Check on ebay and be happy.

ps: regarding opnsense... i never had any regret after installed it. I cant say the same about pfsense.... maybe skin thing, but i hated it.

Thanks !!

I'm indeed using free version. I was expecting this works under free ...
Anyway, i will ask them a trial.

10 isnt too much, but at the same time, i would like to see it working first.

You need paid subscription (like home which is 10€ a month) for it.

If you have paid subscription, then here are steps I could find.

• Go to Settings -> DNS Enrichment.Toggle on Perform real-time DNS reverse queries for local IP addresses. Under DNS Enrichment for Reports, add the IP address of your local DNS server. Save your changes and restart the Zenarmor engine from the dashboard
• Go to Services -> Unbound DNS -> Overrides in your OPNsense UI.Add Host Overrides for your client devices to map their names to their static IP addresses.
• Go to Services -> Unbound DNS -> Overrides in your OPNsense UI.Add Host Overrides for your client devices to map their names to their static IP addresses.
• Ensure you haven't accidentally masked your IP addresses. In the Zenconsole, check your Privacy Settings and make sure Anonymize local IP address is toggled OFF.
• If you are still seeing IPs or MAC addresses, you may need to clear your reporting database/cache to force a fresh look-up using the new DNS settings.

If that fails, then contact zenarmor support for further guidance.

Anyway, since you didn't mention wether you are using free version or not, I assume you are using free version and that's why it doesn't work

Hello,

I am trying to make Zenarmor display local hostnames instead of only IP addresses in reports/sessions, but I cannot make it work despite multiple tests.

Environment:

* OPNsense latest
* Zenarmor latest
* Multiple VLANs
* Unbound enabled locally on OPNsense
* DHCP leases registration enabled in Unbound
* Static mappings registration enabled in Unbound
* Clients are forced to use OPNsense DNS through DNS hijacking/NAT redirect
* Upstream recursive DNS is an Oracle Cloud Unbound server over WireGuard

Issue:
Zenarmor still shows devices only by IP address (example: 192.168.100.x) instead of local hostnames.

What I already tested:

* Zenarmor DNS server set to:

  * 127.0.0.1
  * OPNsense interface IPs (example 192.168.200.x)
  * Oracle recursive DNS IP
* Restarted/reloaded Zenarmor services
* Cleared firewall states
* Generated fresh traffic/sessions
* Verified local reverse lookups on OPNsense
* Verified DHCP registration options are enabled in Unbound

I also understand the difference between:

* local authoritative DNS knowledge on OPNsense
* recursive upstream DNS on Oracle

However, despite all this, Zenarmor still does not enrich local IPs into hostnames.

Questions:

1. Is there any cache that must be manually cleared in Zenarmor for hostname enrichment?
2. Does Zenarmor require additional settings to read local Unbound lease registrations?
3. Is hostname enrichment limited when Unbound is running in forwarding mode?
4. Is there any known issue with VLAN environments and local hostname enrichment?
5. Is there a recommended way to validate whether Zenarmor is successfully consuming local DNS/PTR information?

Any help or guidance would be appreciated.

Thank you.

Hello Bob,

Thanks again for your help and i can confirm that works.
You just need to avoid overlap the ip address and boom, all working. Amazing.

Thanks

I won't be able to have two connections with proton, once their tunnels always have the same address

Just change the first "2" to a different number (e.g. 10.3.0.2).

Hi Bob,

I will try it here . I was afraid the tunnel ip was somehow tied to a nat on proton side .
Doesn't hurt to try .

Many thanks

I won't be able to have two connections with proton, once their tunnels always have the same address

Just change the first 2 with a different number (e.g. 10.3.0.2).

Thanks for your response .
If the tunnels needs to have different ip addressing , I won't be able to have two connections with proton, once their tunnels always have the same address, except by the public ip of endpoint that changes according to the location .

Pretty sad . I will try with proton and another vpn provider .

Thanks

The Gateway failover is dependent on the state of the Gateway.
Thus this means you need to have 2 GWs, one per tunnel and those need to be unique and per GW needs to be router per Tunnel.

TO achieve that, create a GW, bind it to the specific Tunnel Interface, and do not disable the host routes. This will basically enforce the specific GW only to route and to be accessible via the specific tunnel. This means when the Specific Tunnel will go down so will go down as well the GW cause a static route points over it and the GW monitoring & failover will trigger properly.

Regards,
S.

Hi Bob ,

All the proton configs have the same tunnel address , the only thing that changes beyond the keys, are the endpoints.

Proton tunnels reuse the same local tunnel IP (10.2.0.2), which may contribute to routing/state ambiguity

What do you mean by that.
And my observations are, that those tunnels stay up almost all the time, only ICMP gets dropped from time to time, nothing else.

Hello everyone,

I am trying to implement automatic failover between two ProtonVPN WireGuard tunnels on OPNsense, but I am hitting what seems to be unreliable behavior with WireGuard gateway groups and dpinger.

Environment:
- Latest OPNsense version
- Two ProtonVPN WireGuard tunnels
- VLAN100 traffic policy-routed through a gateway group
- Primary tunnel: CHPROTON-BKP (wg3)
- Backup tunnel: CHPROTON
- Gateway group configured with Tier1/Tier2 failover
- Both WireGuard tunnels are operational and working correctly individually

Observed behavior:
- Traffic works correctly through the primary WG tunnel
- If I manually disable the primary gateway/interface, failover works and traffic correctly moves to the backup tunnel
- However, if the primary Proton peer becomes unusable or disconnected, the WireGuard interface often still remains "UP"
- dpinger/gateway monitoring still considers the gateway healthy
- Gateway group does not fail over correctly
- Traffic blackholes until I manually disable the dead gateway/interface

Additional observations:
- Proton tunnels reuse the same local tunnel IP (10.2.0.2), which may contribute to routing/state ambiguity
- OPNsense locally-generated traffic (ping/curl from firewall itself) does not seem to follow policy-routing/gateway-group rules, making reliable local health probing difficult
- Handshake age and RX/TX counters are not reliable enough because WireGuard keepalives continue even when real Internet traffic is broken
- Packet captures confirm that route-to rules are applied and packets leave through the expected WG interface, but sessions still fail when the gateway/group logic gets stuck

What I already tested:
- Different monitor IPs
- Gateway groups with trigger levels
- State resets
- Manual route testing
- tcpdump validation on WG interfaces
- Monitoring handshake age
- curl/ping probes
- Rebooting OPNsense
- Manually disabling/enabling gateways/interfaces

At this point I am considering:
1. Keeping only one active Proton tunnel and one cold standby
2. Creating a custom watchdog script using Monit
3. Using WAN failover underneath a single WireGuard tunnel instead of multiple WG tunnels in a gateway group

My questions:
- Has anyone successfully implemented reliable automatic failover between multiple ProtonVPN WireGuard tunnels on OPNsense?
- If yes, how are you detecting tunnel failure reliably?
- Are you using gateway groups, Monit scripts, dpinger, or another method?
- Did anyone find a clean workaround for locally-generated traffic not following policy-routing rules?
- Is this considered a known limitation/bug with WireGuard + gateway groups on OPNsense?

Any feedback or working architectures would be greatly appreciated.

Thanks!

Hi everyone,

I am trying to improve hostname visibility in OPNsense/Zenarmor and I am facing an issue with reverse PTR resolution for dynamic DHCP leases.

Current setup:

* OPNsense latest version
* Unbound enabled as main DNS resolver
* Dnsmasq DNS & DHCP enabled only for DHCP handling
* dnsmasq listening on port 53053
* Local domain: lab
* Zenarmor installed

What works:

* Forward lookup works correctly

Example:

```bash
drill lab003.lab @127.0.0.1
```

Returns:

```text
lab003.lab. IN A 192.168.100.204
```

What does NOT work:

* Reverse PTR lookup

Example:

```bash
drill -x 192.168.100.204 @127.0.0.1
```

Returns:

```text
NXDOMAIN
```

I also verified:

```bash
cat /var/db/dnsmasq.leases
```

and the lease hostname is correctly present.

Additional observations:

* dnsmasq logs show:

```text
read /var/etc/dnsmasq-leases - 0 names
```

* Enabling "Prefer DHCP" did not resolve the PTR issue.
* Enabling "Register ISC DHCP4 leases" also did not help.
* Zenarmor mostly displays IP addresses instead of hostnames due to missing reverse PTRs.

Questions:

1. Is this expected behavior with Unbound + dnsmasq DHCP integration?
2. Are dynamic PTR records supposed to be generated automatically in this architecture?
3. Is there a recommended approach to get automatic reverse PTR resolution without creating static mappings for every device?
4. Would using KEA DHCP improve this situation?
5. Is there a known limitation/bug regarding dynamic PTR generation in OPNsense?

Goal:

* Preserve dynamic DHCP
* Avoid static mappings for every device
* Improve hostname visibility in Zenarmor/logging/reporting

Thanks!

# My OPNsense + Proton VPN + Oracle Cloud Recursive DNS Journey (WireGuard + VLANs + DNS Hijacking)

Hi everyone,

I wanted to share a project I've been working on over the last few days with OPNsense. I still consider myself a beginner/newbie with OPNsense specifically, but I honestly had a lot of fun building and troubleshooting this environment over roughly 3 days.

The amount of flexibility OPNsense provides is honestly impressive.

My goal was to build a segmented home/lab network with:

* VLAN isolation
* forced DNS
* recursive DNS with filtering
* private DNS transport over WireGuard
* selective VPN routing
* RFC1918 local bypass
* cloud-hosted DNS
* clean routing logic

I also wanted to understand *why* things worked, not just copy/paste configs.

I'm posting this because I learned a lot during the process and maybe it helps someone else trying to build a similar architecture.

All sensitive information below is sanitized:

* no real public IPs
* no private keys
* no preshared keys
* no exact cloud identifiers

---

# Physical Infrastructure

Current hardware/network:

* OPNsense firewall/router
* 2x Layer-3 switches
* SFP56 fiber interconnects between switches
* dual fiber uplinks between switches
* multiple VLANs
* Oracle Cloud VM
* Proton VPN WireGuard tunnels

I will also add:

* a third access switch

because the current switches are 24-port models and I'm starting to run out of ports.

The switches are connected through:

* SFP56 fiber
* 2 physical links between them

The idea is eventually to continue expanding VLAN segmentation and lab environments.

---

# High-Level Goal

The final design became:



Clients
→ OPNsense
→ DNS hijacking / local forwarding
→ WireGuard tunnel
→ Oracle Cloud recursive DNS
```

while one VLAN uses Proton VPN for Internet egress:

```text id="xv7fzo"
VLAN100
→ Proton VPN
→ Internet
```

and all internal RFC1918 traffic stays local.

---

# Sanitized Topology Diagram



The diagram includes:

* VLAN layout
* WireGuard topology
* Proton VPN tunnels
* Oracle Cloud recursive DNS
* DNS flow
* PBR logic
* security controls
* validation tests

All IPs are sanitized intentionally.

---

# VLAN Layout

Current VLANs:

```text id="6b6rk4"
VLAN50  Users
VLAN60  IoT
VLAN70  General
VLAN80  Lab
VLAN90  Management
VLAN100  PowerUser
VLAN240  Infra
```

Each VLAN has:

* its own gateway
* firewall rules
* DNS handling
* routing policy

---

# DNS Architecture

Initially I was forwarding DNS from OPNsense to Oracle Cloud using the Oracle public IP.

That worked, but I quickly realized:

* source IP changes become annoying
* VPN exits complicate ACLs
* public DNS exposure is unnecessary

So I built a dedicated WireGuard tunnel between:

* OPNsense
* Oracle Cloud

Now DNS travels privately:

```text id="sv3m8j"
OPNsense
→ wg2
→ Oracle wg0
→ Unbound recursive DNS
```

This was validated using:

```bash id="6np8n5"
tcpdump -ni wg2 port 53
```

I could clearly see:

```text id="j6v1p8"
OPNsense-WG-IP → Oracle-WG-IP:53
```

which confirmed DNS was traversing the private tunnel.

---

# Important Discovery #1

## OPNsense Uses Round-Robin DNS Behavior

One thing I discovered:

If multiple DNS servers are configured under:

```text id="vppfjt"
System → Settings → General
```

OPNsense appears to use them in a round-robin-like manner.

That caused confusion during testing because:

* some queries used Oracle
* others used another resolver

For clean validation and predictable behavior:

* I ended up using only the Oracle WireGuard DNS server.

This made troubleshooting MUCH easier.

---

# Important Discovery #2

## WireGuard Instances Must Use Different Ports

Another thing that confused me initially:

Different WireGuard instances on OPNsense should use different listen ports.

Example:

```text id="o1pl5j"
wg0 → 51820
wg1 → 51830
wg2 → 51840
```

When multiple instances were using overlapping/default ports, behavior became inconsistent.

After assigning unique ports:

* everything stabilized immediately.

---

# Important Discovery #3

## WireGuard Key Logic

This was another major learning point for me.

The rule is simple:

```text id="9blz0y"
Your device keeps its own private key.
The peer gets your public key.
```

So on OPNsense:

```text id="0twd1z"
Instance:
- OPNsense private key

Peer:
- Oracle public key
```

On Oracle:

```text id="4ujpx3"
Interface:
- Oracle private key

Peer:
- OPNsense public key
```

The preshared key:

* must match on both sides
* but does NOT replace public/private key authentication.

At first I was confusing:

* public keys
* private keys
* preshared keys

especially because Proton VPN client configs look different from traditional WireGuard server configs.

---

# Important Discovery #4

## Cloud Firewalls + OS Firewalls Both Matter

This was another very important lesson.

When working with cloud VMs, you often have:

* cloud-level security rules
* operating system firewall rules

Both must allow the traffic.

In my case:

* Oracle Cloud security lists / NSGs had to allow:

  * WireGuard UDP port
  * DNS traffic
* Ubuntu itself also needed firewall rules

Even after Oracle Cloud allowed the traffic, DNS still failed until I allowed it locally on Ubuntu.

Example:

```bash id="0w7b1s"
sudo iptables -I INPUT 1 -i wg0 -p udp --dport 53 -j ACCEPT
sudo iptables -I INPUT 1 -i wg0 -p tcp --dport 53 -j ACCEPT
```

So the troubleshooting sequence became:

```text id="1rj4z9"
Cloud security rules
→ Linux firewall
→ Service binding/listening
→ routing
```

This was probably one of the biggest troubleshooting lessons from the whole project.

---

# Proton VPN Setup

I configured:

* Proton UAE
* Proton Switzerland

using WireGuard.

Important detail:

* I did NOT route the whole firewall through Proton.

Instead:

* only VLAN100 uses Proton through Policy-Based Routing.

This keeps:

* management stable
* OPNsense updates clean
* troubleshooting easier

while still allowing selected clients to use VPN egress.

---

# PBR (Policy-Based Routing)

The key logic:

```text id="z3b6q8"
Default VLANs
→ WAN

VLAN100
→ Proton VPN
```

For VLAN100 I added:

1. RFC1918 bypass rule
2. Proton gateway rule

in that order.

That means:

```text id="yp9u4r"
Internal traffic
→ local routing

Internet traffic
→ Proton VPN
```

This solved:

* local access issues
* inter-VLAN communication
* NAS/server access problems

while still tunneling Internet traffic.

---

# DNS Hijacking

All VLANs now use DNS hijacking rules.

If a client tries:

```text id="iq6jrf"
8.8.8.8
1.1.1.1
9.9.9.9
```

the request gets redirected back to OPNsense.

Then:

```text id="x0s2d2"
OPNsense
→ Oracle over WireGuard
```

This ensures:

* filtering
* DNSSEC
* logging consistency
* centralized control

---

# Oracle Cloud DNS Server

Oracle Cloud VM runs:

* Ubuntu
* WireGuard
* Unbound recursive DNS
* DNSSEC
* HaGeZi blocklists
* TIF threat feeds

Unbound receives DNS from OPNsense through WireGuard only.

I also modified iptables to:

* allow DNS from wg0
* allow WireGuard UDP
* restrict unnecessary exposure

---

# Validation Tests I Used

## Verify WG Route

```bash id="wsc9d3"
route -n get <oracle-wg-ip>
```

Expected:

```text id="20y5zy"
interface: wg2
```

---

## Verify DNS Through WG

```bash id="3h5m9r"
tcpdump -ni wg2 port 53
```

Then:

```bash id="otm32j"
dig google.com
```

Expected:

```text id="vw2m7i"
WG-IP → WG-IP:53
```

---

## Verify Proton Exit

From VLAN100:

```bash id="quvb8f"
curl ifconfig.me
```

Expected:

* Proton public IP

---

## Verify OPNsense Still Uses WAN

From OPNsense shell:

```bash id="wq1pp9"
curl ifconfig.me
```

Expected:

* ISP WAN IP

This was intentional.

I did NOT want the firewall itself depending on the VPN.

---

# Current Status

Everything is now operational:

* Proton VPN working
* Oracle WireGuard tunnel working
* DNS over WireGuard validated
* VLAN100 PBR validated
* DNS hijacking validated
* DNSSEC validated
* recursive DNS validated
* RFC1918 bypass working
* internal access preserved

---

# Next Improvements

Some of the next things I plan to implement:

* EAP-TLS certificate-based Wi-Fi authentication
* additional VLAN segmentation
* third access switch deployment
* improved monitoring
* maybe HA/failover later
* physical topology documentation
* additional DNS hardening
* more management isolation

I'm especially interested in moving toward:

* WPA-Enterprise
* EAP-TLS
* certificate-based authentication

instead of relying only on traditional PSKs.

---

# Final Thoughts

Honestly, I started this mostly wanting to "play" with OPNsense and learn more deeply how:

* routing
* WireGuard
* DNS
* VLANs
* firewall rules
* recursive DNS

all interact together.

It became a much bigger learning experience than expected.

I still consider myself a beginner with OPNsense specifically, but I'm really impressed with:

* flexibility
* visibility
* debugging capabilities
* policy routing
* WireGuard integration
* overall architecture possibilities

The troubleshooting tools alone:

* tcpdump
* route inspection
* firewall logs
* live states

made learning much easier.

Hopefully this helps someone trying something similar.

Hey Nero

Thanks for responding .

I've made a summary that can help others :


Successfully validated transparent DNS interception + centralized DNS enforcement.

Test scenario:
Client intentionally queried external resolvers directly:

* 1.1.1.1
* 2.2.2.2

Goal:
Force all DNS traffic to local resolver regardless of client configuration.

Validation chain:

1. Client-side packet capture initially showed:

192.168.50.214 -> 2.2.2.2:53

2. However, WAN-side packet capture showed NO outbound DNS/53 traffic leaving externally.
3. At the same time, local Unbound overrides were applied successfully even when querying external resolvers directly:

dig @2.2.2.2 aljazeera.com

Returned:

0.0.0.0

which only existed in local Unbound configuration.

4. VLAN-side capture still showed original tuples (expected pre-NAT behavior):

192.168.50.214.57805 > 2.2.2.2.53: A? aljazeera.com

but WAN capture confirmed no actual DNS egress.

5. Final proof came from Unbound query logs:

query: 192.168.50.214 ufpa.br. A IN
reply: 192.168.50.214 ufpa.br. A IN NOERROR

6. Upstream DNS validation:
    WAN capture on TCP/853 showed:

192.168.1.74 -> 9.9.9.9:853

confirming:

* local interception works
* firewall itself performs upstream DNS-over-TLS
* clients no longer query external resolvers directly.

Final architecture:

Client
→ forced DNS interception (NAT redirect)
→ local Unbound
→ Quad9 DNS-over-TLS

Interesting observation:
Ingress/VLAN packet captures may still display original pre-NAT destination tuples, while WAN captures reveal the actual post-NAT egress reality.


Hope I'm correct on my understanding and that's also helps someone

Even more confusing:

* `dig @1.1.1.1 google.com
* `dig @2.2.2.2 aljazeera.com

still succeed from the client (macbook terminal) (just in case has something special with mac).

After applying the correct DNAT/SNAT Rules and related Firewall Rules that should work indeed, but instead of the queries going to those Public DNS Servers the queries should show up in the Query Log of your Private DNS Server ;)

I also noticed:

* some DNS requests *are* going to `192.168.50.1`
* but other requests still leave directly to public DNS servers

That's not good...

Try these settings : https://forum.opnsense.org/index.php?msg=259581
And if you have questions let me know :)

Hi Folks,

Actually maybe its working. Just need to know when capturing packets from opnsense, if it capture before NAT, if its the case, then probably its working.
Im confused now. lol

Hi everyone,

I'm trying to enforce DNS redirection/blocking on the latest OPNsense version for a VLAN network, but I'm seeing behavior that I don't fully understand and would appreciate some clarification from experienced users.

My setup:

* VLAN interface: `VLAN50Users`
* Firewall IP / local DNS resolver: `192.168.50.1`
* Goal:

  * Force all clients to use the local Unbound resolver
  * Prevent clients from using external DNS servers like:

    * `1.1.1.1`
    * `8.8.8.8`
    * `2.2.2.2`

What I configured:

1. NAT Port Forward rule:

* Interface: VLAN50Users
* Protocol: TCP/UDP
* Source: VLAN50Users net
* Destination: any
* Destination Port: 53
* Redirect target IP: 192.168.50.1
* Redirect target port: 53

2. Firewall rules on VLAN50:

* Pass DNS to `This Firewall`
* Block DNS to external destinations
* General allow rule below them

States were reset after every change.

However, packet captures still show direct DNS traffic going to public resolvers:

Example captures:

```text id="8x3y4q"
192.168.50.214 -> 1.1.1.1:53
192.168.50.214 -> 8.8.8.8:53
192.168.50.214 -> 2.2.2.2:53
```

Even more confusing:

* `dig @1.1.1.1 google.com`
* `dig @2.2.2.2 aljazeera.com`

still succeed from the client (macbook terminal) (just in case has something special with mac).

I also noticed:

* some DNS requests *are* going to `192.168.50.1`
* but other requests still leave directly to public DNS servers

Additional notes:

* Client is connected via Ethernet (not Wi-Fi)
* Rules are on the VLAN interface tab (not floating)
* Direction is IN
* Protocol is TCP/UDP
* Tested with macOS terminal using `dig`

Questions:

1. Is packet capture showing packets before NAT/filter processing?
2. Is there something different in newer OPNsense versions regarding DNS interception?
3. Is the recommended modern approach:

   * NAT redirect only?
   * block only?
   * or both together?
4. Is DNS over TLS / HTTPS interfering here?
5. Is there a known requirement for floating rules or reply-to disabling in this scenario?

I found this old tutorial:
https://forum.opnsense.org/index.php?topic=9245.0

but behavior on current versions seems different.

Any clarification on the correct/recommended way to fully enforce local DNS on current OPNsense would be greatly appreciated.

Thanks!