Messages

Have you tried rebooting the firewall?
I find that sometimes - especially after messing with VLAN and interface assignments - some unexpected behavior can sometimes occur even after proper configuration and applying your changes - requiring a reboot to fix.

Services --> Unbound DNS --> Query Forwarding --> [ + ]
Server IP: YOUR PI-HOLE IP

Then let clients get the OPNSense Firewall (default) IP for DNS Server.

With this setup, clients will use Unbound on OPNSense for DNS, and Unbound will forward DNS requests to the Pi-Hole.

----
For an alternative, more advanced setup:

Firewall --> NAT --> Port Forward --> [ + ]

Interface: Guest_Network
TCP/IP Version: IPv4 (or "IPv6" - if required - make separate rules)
Protocol: TCP/UDP
Destination: This Firewall (or "any" - if you want to also catch  and redirect client attempts to use other, unauthorized internet DNS servers)
Destination port range: DNS - DNS (or use an alias for ports 53 and 853 to include DNS over TLS)
Redirect target IP: YOUR PI-HOLE IP
Redirect target port: DNS (or use an alias for ports 53 and 853 to include DNS over TLS)
Filter rule association: Add associated filter rule

If the Pi-Hole is on the same subnet, also select:
Source [Aadvanced]
Source / Invert: [CHECK]
Source: YOUR PI-HOLE IP
in order prevent outbound requests from the Pi-Hole getting redirected to itself.

Then let clients get the OPNSense Firewall (default) IP for DNS Server.
All DNS traffic should now bypass OPNSense (Unbound) and get NATed to the Pi-Hole.

I would use this setup and have the Pi-Hole forward requests for my local domain to OPNSense.

The advantage of doing it this way is being able to have a different set-up for different subnets. e.g. I could make traffic on my VPN subnet contact a different Pi-Hole that also uses the VPN to prevent VPN DNS Leaks while also maintaining local name resolution and Pi-Hole Ad-Blocking.

----

If you want to go for the first option while also preventing client attempts to use other, unauthorized internet DNS servers, make the NAT rule above but use:
Destination: any
Redirect target IP: 127.0.0.1 (or ::1 for IPv6)

My system log is getting flooded with the following message:

Severity:Notice | Process:kernel | UDP6: M_MCAST is set in a unicast packet.

1. What is likely to cause this?
2. How would I track down what is causing this?
3. Should I even bother?

So, I have a similar setup. I suspect you haven't fully completed all the steps to set up a PPPoE connection.

First, to get PPPoE working:

• The DSL Modem that was previously managing the PPPoE connection had to be switched "Transparent Bridging" mode.
• A new connection needed to be made under "Interfaces: Point-to-Point: Devices" using the username, password, and settings that the DSL modem was previously using to connect to the ISP.
• Under "Interfaces: Assignments" the "Network port" for "WAN" needed to be selected as the new pppoe device instead of the physical port.
• Under "Interfaces: [WAN]", IPv4 Configuration Type twas changed to PPPoE and IPv6 Configuration Type changed to none.

After that, you can turn on gateway monitoring for the the automatically generated gateway and include it in a group.

I have my ISP modem set up for transparent bridging with OPNsense managing the PPPoE connection to my DSL.

Occasionally, this connection will stop passing traffic. Internet will stop working and gateway monitoring will show 100% packet loss, then eventually gateway down, and removing it from the active gateways list on the home page. OPNsense does not attempt to reset/reestablish this connection and I typically have to reboot the ISP modem to restore my internet connection.

Is there a way to configure OPNsense to attempt to reset this connection automatically when the gateway does down?

So I'm having the same problem between LANs on the SAME firewall.

I have only one OPNsense box.

My SSH sessions to my server on LAN 2 kept freezing up after about 30 seconds. At first, I thought my server was lagging, but problems went away the moment I was on the same LAN.

The only thing standing between LAN1 and LAN2 is this OPNsense box.

That being the case, OPNsense must be killing the Intra-LAN traffic after about 30 seconds.