Messages

[thank you]

Because it is in the mimugmail repository, which you have to install first: https://github.com/mimugmail/opn-repo

Ah thank you! Any significance with them not being included in the Opnsense repository of community plugins - unvetted, discouraged, deemed 'less-than', etc... ? Or is this me just conflating 'community edition' with 'user community' and all those [show community plugins] are 1st party.

Any idea why I'm not seeing this community speedtest plugin available under Firmware -> Plugins -> [Show Community] ? I am definitely interested in a plugin like this, I had installed the package 'py311-speedtest-cli' a bit ago for cli use.

Yep, I had same issue just a couple days ago, the reply-to change solved it: https://forum.opnsense.org/index.php?msg=247319

I just accomplished this by going to the host reservation in DNSMASQ, and under the DNS section of the host setup putting in a CNAME Record of MQTT.PSHARKAUBURN.LAN. So now my DHCP reservation of SERVER (SERVER.PSHARKAUBURN.LAN) has an automatic CNAME entry of 'MQTT.PSHARKAUBURN.LAN' pointed to it.

I didn't do anything in unbound to make this work regarding the SERVER -> MQTT stuff. I HAD previously done the setup related to using DNSMASQ + UNBOUND together, where UNBOUND is forwarding DNS lookups for PSHARKAUBURN.LAN -> 127.0.0.1:53053 which is what port I put DNSMASQ DNS listening on.

Pic Attached

[no joy]

Sounds like a case requiring to enable Firewall: Settings: Advanced: Disable force gateway.

Thank you for the suggestion but that did not help. I'm also not quite sure why it would help since the connection is within a single network so there is no routing involved.

So same effective setup, same issue, and this forum post was the top hit from google regarding the issue. Home network is on 192.168.1.x/24 , my test Opnsense box is pulling 192.168.1.144 from DHCP on the WAN side, and it's handing out 10.17.1.x/24 on the LAN side. I have 'block private networks' UNCHECKED on the WAN interface because of the double router setup and I want to come in from a 192.168.1.x address.

Created a rule on the WAN interface: PASS, IN, IPv4, TCP from 'WAN net' to 'This Firewall, WAN Address' on port 443, apply immediately on match. Applied the rule, it's the only firewall rule I've created.

Coming in from desktop on the 192.168.1.X network and trying to hit https://192.168.1.144 ; no joy. Bring up firewall -> Live View from a machine on the LAN side of the Opnsense router I've been using for config. Scope it to source or destination of the 192.168.1.X desktop IP, trying the webpage again from that machine, still no joy but also seeing nothing in the Live View (no passes or blocks). Change the page address to http://192.168.1.144, still no joy (as expected because my rule is against port 443 not 80) but now seeing the red firewall blocks in Live View.

Google leads me here, I try Franco's suggestion:

Sounds like a case requiring to enable Firewall: Settings: Advanced: Disable force gateway.

Still no joy. This was under 'Multi-Wan' area and I didn't have a multi-wan setup, but tried the suggestion anyway. Some reddit posts on the topic suggest turning off 'reply-to', SUCCESS!

So on my WAN rule itself, under Advanced Features [show] -> Reply-To = Disable. Intent seems similar to the 'disable force gateway' under the multi-wan advanced settings. Of interest, looking at same Live View and I'm still not seeing pass/block against the WAN side desktop IP that is now successfully able to hit the web gui - any ideas why?

Good deal! You mentioned client isolation a couple times, just a ping that this is a setting on the wireless APs at the SSID level. If you enable it, those wireless clients will not be able to see each other or anything else inside your network except the OPNSense as the default gateway. Even with everything in the same network, those wireless clients become blind to everything (normally). This would be HEAVILY recommened to enable for something like a Guest WiFi network.

Its funny, the guide Patrick posted kinda opens up with 'bridging the lan devices is kind of a pain, it's easier if you just buy a switch for downstream' which is spot on. I think you get errors like 'can't add a device to itself' or 'device is already part of the interface' when you're configuring from the LAN interface and need to add that port to the bridge, to takeover the LAN interface. Feels like trying to call customer support about phone issues, on the phone having the issues... and step one from them is reboot the phone, and you never hear step 2 because you followed step 1.

When I was messing with my OPNSense router (with it sitting behind another router) I found it easier to fiddle by disabling the packet filter (firewall) with 'pfctrl -d' from the OPNSense shell, and then come into the OPNSense web gui from the WAN side (just another computer on the home network) so that mucking around with LAN interfaces doesn't cut the cord you're calling from.

I'm definitely a noob here too, so take my info in stride. What I'm hearing is you want a single subnet for simplicity. So you'd be looking for igc0 to be WAN network, and igc1 + igc2 + igc3 to be members of a bridge (bridge0) and that bridge0 be assigned to the LAN interface. You'd give that bridge an IP like 192.168.150.1/24. You've have DHCP running against the LAN interface, serving out a range like 192.168.150.50 - 192.168.150.200 (or however many you want); and that leaves you plenty of IPs outside the DHCP range for servers or static-y devices.

Your existing ASUS router and the TP-Link would need to be running in just AP mode (both of them) serving as access points, you could give them static IPs like 192.168.150.2 + 192.168.150.3 (what i'd do) or let them pull from DHCP. You don't want them offering services like DNS or DHCP, that's the Opnsense router's job since you really just want one network. With just one subnet/network - routing doesn't really come into play (except to the outside world) and everything is in the same L2 broadcast domain, everything is going to see each other at the layer 2 level, and being in the same network packets don't have to be routed.

Your original description mentioned multiple networks 192.168.140.X/24 + 192.168.150.X/24 which naturally makes things isolated unless you setup routing between those 2 separate networks (and that's regardless of bringing VLANs into the picture). It sounded like you put ports of both networks (igc2 + igc3) into the same VLAN which doesn't make them automatically talk to each other - different IP networks (layer 3) means they need layer 3 routing to communicate and routes setup between them. OPNsense is obviously a router, but you'd need to be setting up firewall rules allowing inter-vlan / or interface-interface communication if you have a different network on each physical interface.

So I found that going to Services -> Unbound -> Settings and toggling 'Advanced' and then setting 'Outgoing Network Interfaces' to explicitly 'WAN' seemed to make a difference. That setting, normally hidden, defaulted to 'ALL'. I have 3 interfaces on my machine, LAN, WAN, and OPT1 which is unconnected onboard WiFi. Toggling outbound to 'WAN', apply, stop, re-starting the service and this seems to bring DNS resolution to life.

Any ideas why? And related note, the help wording indicates this only works when the interface is statically configured... but my WAN interface is set by DHCP.

Running 25.7.2 on a recently factory reset installation, and not getting Unbound to work as a recursive DNS server.

Some background: I had downloaded opnsense 25.1 to try out several months ago, installed it on a small box but never went through configuring and setting it up. This weekend I got around to it, and did the update up to 25.7.2. The box is behind my home router, so it's pulling a 192.168 address on the WAN side and handing out 10.X.X.X on the LAN side. Under System -> Settings -> General I left the DNS servers list blank, but CHECKED the allow DNS Server list to be overridden by WAN DHCP. Because of the double router setup, I UNCHECKED the 'Block Private Networks' on the WAN setting so it'd be good with 192.168 traffic. So it was pulling my home router (192.168.1.1) as DNS, which allowed the update from 25.1 -> 25.7.2 to happen. Default install had Unbound running on port 53, and DNSMASQ set to 0 (DNS disabled) while DHCP services were working fine.

Next round of setup included following the guide in the docs for DHCP -> DNS registration: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration. Had no issue setting up DNSMASQ DNS on port 53053. Went into Unbound settings -> Query Forwarding and setup the forward and reverse domain match for my internal LAN domain to forward to 127.0.0.1:53053 (DNSMASQ). I also had CHECKED 'Use System Nameservers' on the Unbound -> Query Forwarding -> Settings page. From a couple LAN clients I verified they got Opnsense router as DNS Server after successful DHCP lease. I was able to successfully test DNS resolution against DHCP clients (FQDN), both forward and reverse and it was working fine.

So at this point I know my LAN clients are hitting Opnsense Unbound on 53 for DNS services, and it's forwarding to DNSMASQ for internal domain resolution against DHCP leases fine. I had a feeling it wasn't running as a recursive DNS server and confirmed after doing a dnscheck.tools that it was resolving from my home router (192.168) DNS settings (set to a public clean browsing service). This made sense with me checking that option on the Unbound Query Forwarding page to 'Use System Nameservers'. After unchecking that box and Unbound restart, I lost DNS resolution to anything external on my LAN test clients. Going into the router -> System -> Settings -> General and unchecking 'allow DNS to be overridden by WAN DHCP' and a system reboot, and I lost DNS resolution on the OPNSense router. I explicitly tried setting it's DNS server list to 127.0.0.1 but had no effect.

On LAN clients, any nslookup against the default DNS server (OPNSense router) were failing. Explicitely pointing a nslookup to use a public server like 8.8.8.8 worked fine. Same on the OPNSense router, doing a 'drill www.google.com' would fail (showing it was asking against 127.0.0.1) while doing a 'drill www.google.com @8.8.8.8' would be successful. So this wasn't a case of not being able to get DNS traffic to the LAN or WAN side of this OPNSense router.

Thinking maybe it was me mucking up something during setup, I did a 'factory reset' option. The only stuff I did was assign interfaces, unblock private networks on WAN, set IP address/subnet on LAN side. I left DNS Servers BLANK, I never checked allow WAN DHCP override, I left default settings untouched in DNSMASQ and Unbound. No custom query forwarding on the Unbound side or anything. I was under the impression that OPNSense would use the internally running default Unbound instance on port 53 as system DNS if the server list was left empty. Trying a 'drill www.google.com' verified it was asking against 127.0.0.1. No luck, not getting resolution from the OPNSense server itself, or a LAN client. I can manually override LAN client to a public DNS Server like 8.8.8.8 and all is well.

Any ideas? I was curious if root hints were missing or something, knowing it needs a starting point explicitly given for recursion to jump off from. Looking through config files, those seem to be there (i'm not a freebsd person by any stretch tho). I know I can get the router working by setting a system DNS server to use (like Google DNS or my ISP) and telling Unbound to forward queries - but I was under the impression that shouldn't be needed; as a recursive DNS server it should be able to do everything it needs on its own.

Any tips or pointers or ideas welcome.