Messages

Unbound on port 53, DNSmasq on port 53053, and set up the Unbound query forwarding in accordance with OPNSense docs:
https://docs.opnsense.org/manual/dnsmasq.html

I followed the examples at that link for my configuration, and it's running flawlessly for me across 5 different interfaces. Unlike the first person who responded to you, I feel like this was a pretty rock solid initial release for a lighter and more efficient DHCP. From what I've gathered between here and Reddit, the majority of the people having issues decided to wing it with their setup and didn't read the guides first.

Oh, I followed that guide explicitly. It's absolutely busted for people who have anything beyond a extremely simplistic network.

See https://github.com/opnsense/core/issues/8623, https://github.com/opnsense/core/issues/8612, https://github.com/opnsense/core/issues/8611

Here's the fun part: you'd expect overrides in Unbound to be queried first by Unbound, right? e.g. if it's in Unbound's overrides, it doesn't even need to query an upstream (e.g. dnsmasq). Wrong. If you followed that guide and setup query forwarding for your local domain to dnsmasq, it'll query dnsmasq first, fail (since it's a non-existent DNS entry since it's, well, an override), and THEN fallback to its own overrides.

Like I said, busted.

Edit: Don't get me wrong - it works fine for regular internet usage. All my clients have internet connectivity. It's just absolutely busted for those who self host lots of services and so rely on hostname resolution, since the main problem right now is that hostname resolution is VERY rough around the edges compared to ISC

I actually just tested it, you cannot do dnsmasq -> unbound anyhow. Since dnsmasq needs to be on port 53 in that scenario, and unbound on some other port such as 53053, this completely breaks DNS lookups. For whatever reason, dnsmasq is hard coded to use the system name servers set in Settings -> General, which means you create a DNS loop - dnsmasq -> system name server -> dnsmasq -> system name server etc. There's no way around it since you cannot specify a port (e.g. unbound's listening port) in Settings -> General.

dnsmasq's implementation is overall baffling and feels somewhat like the team is trying to fit a square peg into a triangular hole.

No, Unbound only supports ISC for "direct" lookups at the moment. You can either have queries go to dnsmasq first and then unbound, or the other way around, which is less clunky. You set query forwarding in Unbound pointed at 127.0.0.1:port_dnsmasq_listens_on for only your local domain. This way, all queries go to unbound first, and don't go anywhere else unless they are for a local hostname lookup, which are then sent to dnsmasq for resolution.

However, IME, dnsmasq is pretty buggy and will regularly fail to properly lookup hostnames. I've been trying for over 2 days to get dnsmasq working properly and have reverted to ISC, and written off dnsmasq as "testing stage" level implementation. I have no real interest in being a beta tester, I need my network to JustWorkTM

You should try to find out where your dns queries get stuck.

I think Unbound does not cache queries it forwards to other DNS servers, and Dnsmasq should not need to cache its own DNS entries because they are static.

I'm just a bit surprised because I run dnsmasq fully features like in the docs since 2 months now and did not experience anything strange. Though I also do not query local services quite as much as you might do. So saying its broken is kinda not true.

Maybe our setups are quite different.

I believe it's unbound because when running a nslookup on my windows machine to a host that is in unbound's overrides, it times out twice before finally succeeding, suggesting unbound is choking on...something because it's a local lookup to unbound.

Edit: Once the query forwarding is turned off, it's able to resolve things better but obviously only for things in unbound's overrides. That said, I will be unable to test this further as I've fully abandoned dnsmasq and do not intend on returning to it in the near future, it's far too experimental for my tastes and makes my internal network communications extremely flakey.

I have problems getting ipv6 working with dnsmasq. RA is active and pool settings are set, but i don't get dnsv6 nor even a ipv6 address on my iPhone. I plan to use dhcpv6 + slaac :/

Edit: got that working by disable the general RA setting...

But now a new issue: how do i get reverse lookups working with dnsmasq?

Double check to make sure you're not also running radvd (Services -> Router Advertisements) when trying to run dnsmasq's RA implementation.

I would not say its broken, I would say now that it is released there are more testers that find out all the edge cases that can still be improved.

Thanks for reporting something :)

Seems like a different way of saying it's broken :)

Overall, since switching, my DNS queries for local services have been extremely flakey - it almost feels like dnsmasq is crumpling under pressure or something with unbound blasting it lookup requests.

I have cache for dnsmasq disabled since it seems unnecessary (it's all local lookups anyhow), don't know if that's what killing dnsmasq. In theory it shouldn't be since unbound has its own cache, but given how strange things are with dnsmasq, who knows.

No, you can mix and match these services however you want.

You can also mix dnsmasq dhcpv6 with radvd.

Yep, figured that out after some testing.

Unbound lookups for local hostnames is pretty broken for DHCP reservations though (https://github.com/opnsense/core/issues/8612). dnsmasq is definitely not ready for the limelight yet, at least not in opnsense.

Wait, so for Dnsmasq DHCP, are we not supposed to rely on radvd anymore and instead need to use the Dnsqmasq RA function?

Er, what happens if you run zfs upgrade zroot and THEN update the bootloader? Are you screwed?

The new 24.7.4 update has fixed both ntopng and crowdsec.

I had squid do the same thing (port open but no connections). A restart always fixed it.

Seems to have something to do with it listening to specific IP addresses instead of 0.0.0.0.

Unfortunately, restarts and complete resets of the plugins aren't doing anything. It seems specific to TCP - my unbound (UDP) is working fine

Did you check with netstat -na | grep LISTEN if the services are indeed listening on 127.0.0.1:<port>?

Yes. For redis, I see 127.0.0.1.6379 *.* LISTEN. For crowdsec, I see it listening on 6060 and 8088.

In the firewall live logs, I can also see ntopng and crowdsec being allowed to contact those ports. So clearly, the services are listening, are being allowed, but not talking back.

I doubt it's just a coincidence that ntopng and crowdsec both cannot contact their respective ports (6379 for ntopng and 8088 for crowdsec) after the update. They were working just fine prior. In fact, in my crowdsec security engine (before I tore it all down in an effort to fix this issue), it showed my bouncer as offline on the exact day I updated to 24.7. That's far too close to be a coincidence.

Edit: Most definitely an opnsense issue with TCP ports. Even running cscli metrics, metrics can't get a response from port 6060.

Under Firewall > Diagnostics > Sessions, lots of syn_sent:closed errors.

127.0.0.1:37989   127.0.0.1:1405   127.0.0.1:6379   SYN_SENT:CLOSED

It appears the bug is with opnsense, not ntopng. This is evident by the fact that I have now noticed that crowdsec cannot contact the LAPI either. Please advise.

I actually already tried that post, and have the packages "properly" updated.

No dice. The only thing in the /var/db/redis folder is dmp.rdb as well. In /var/db/ntopng, I only see a .lock file. No logs even.

Edit: The other person's initial problem also appears to at least be able to get redis connected before crashing. I can't even get redis to connect.