Messages

You can patch it in from the opnsense shell

Ah, nice. Thanks.

One last question: If I replace ISC/Unbound with dnsmasq and use dnsmasq to resolve my local hostnames, will reverse lookup also work? I never got an answer to my previous questions in other topics whether this works or not:

nslookup mymachine.lan.internal returns 192.168.2.5
nslookup 192.168.2.5 returns mymachine.lan.internal.

P.S.: After all these discussions, maybe it is time for me to re-think my DNS strategy.
Currently I am using my pi-hole cluster directly (or via redirected means) and use opnsense's dns for local address resolution (via conditional forwarding from pihole). I can't recall in detail why I set it up this way years ago, but there must have been a very good reason. I faintly remember it was a workaround for an issue with pihole or opnsense (or a combination of both).
Anyhoo, IMO it is a better architecture to do it the other way around: use opnsense's dns and use the pi-hole cluster as upstream DNS. I guess I have some thinking and planning to do. I probably will change to this architecture when I migrate away from ISC/Unbound.

Thanks for all the interesting discussions around this topic.

Thanks for the replies.

Unfortunately this logic makes it impossible for me to replace unbound/isc with dnsmasq. Imagine my opnsense system specifies my pihole as the upstream dns. Then my pihole (which is set and used by all my clients) asks via conditional forwarding dnsmasq on opnsense for internal address resolution. If anything goes wrong here, and we all know that can happen and has happened in the past (due to bugs, misconfig, and whatnot), there's an infinite query loop.

As mentioned before, I need dnsmasq (as my current unbound) for internal address resolution only. If I cannot configure dnsmasq to do just that, I cannot use it.

This also means that I cannot migrate from ISC to dnsmasq (dhcp only), because I still need dnsmasq to do local address resolution. dnsmasq dhcp does not register the leases with Unbound but with dnsmasq only. So I still need Unbound which then asks dnsmasq, which then could still ask my pihole - there's the infinite loop again. The same is true, if I were to use 127.0.0.1 in an Unbound/dnsmasq or dnsmasq-only scenario.

I know that dns resolvers have a bunch of settings to mitigate such loops, but when I currently go through the stack and its options, nothing seems to apply.

It should be easy to add a GUI option to tell dnsmasq not to forward queries at all. I know that it is possible to configure dnsmasq not to forward queries. opnsense just needs to create an option for that.

I'm running 25.1.7_4 and looked at the settings for Dnsmasq DNS & DHCP. My current Unbound DNS does not do query forwarding and I currently do not want to do that with dnsmasq either.

However, if I wanted to do so, how would I specify the upstream DNS servers? There is nothing to set in the options.
Also, there is no way to enable/disable query forwarding, so what does dnsmasq do? I don't see, whether it is active or not. Is it enabled or not? This all is very confusing.

These are the only options one can set for query forwarding:
You cannot view this attachment.

Ok, I am slightly confused: in certain comments people say they use dnsmasq for internal resolution and unbound for external.

Just to be clear, does this mean I can use dnsmasq for internal address resolution (including reverse lookups)? Because another comment mentioned that reverse lookups would have to be forwarded to Unbound or maybe it meant a setting in Unbound has to be set. Either way, Unbound seems to be required.

As mentioned before, I currently use Unbound only for internal address resolution.

So what is it? Can dnsmasq (when used as an ISC DHCP v4 and Unbound replacement) resolve local addresses including reverse lookups?

Here is the link:

Thanks a bunch for the scripts.

Well, my DNS setup is a bit different than probably most people have:

I use a pi-hole keepalived cluster and most VLANs must use that cluster for DNS resolution (via an outbound NAT rule). The only time the Unbound DNS is used is for local address resolution via conditional forwarding on pi-hole.
My OPNsense Unbound can theoretically also forward queries to upstream servers, but I could turn that off, since I do not use Unbound, except for local addresss resolution (standard and reverse, which is however initiated from pi-hole). No machine is using OPNsense's Unbound directly - ever.
A few dedicated machines in certain VLANs are allowed to use external DNS servers directly. All others use my pi-hole cluster even if they have set external DNS servers.

As for DoH, I am not using it - for now. I might be doing so in the future though.

So my use-case is rather easy. I need my OPNsense's DNS (whatever that might be) for local address resolution only. However, I also need reverse lookup. I think I've read that I would have to add 2 forwards to DNSmasq, which in turn would require me to run Unbound as well for the reverse lookup. This makes this simple setup less simple, because I would have to run 2 DNS services on OPNsense instead of just one.
I have to look into this before I migrate to DNSmasq.

For reverse dns, I added an 2 additional forwards

Oh, wait. Does this mean that you cannot use dnsmasq only (for DHCP and DNS), if you want a working reverse DNS, in which case you have to use Unbound as well?

With a lot of effort due to my big number of static reservations, I have now made the shift from ISC DHCP / Unbound to DNSmasq "only". Radvd is still in effect, since I use no DHCPv6. Thanks to ChatGPT for helping me to write the programs to extract the CSVs from the configuration XML for both the static reservations plus the DNS mappings and aliases.

@meyergru Any chance you could make these scripts available via a github repo?

I am currently using ISC DHCP / Unbound myself (only v4 - no v6 at all) and I have been quite happy with it. Although the fact that ISC is no longer maintained is a pitty and makes me slightly nervous.

However, I do have a high number of static mappings (as you have). I use around 20 VLANs, but the most mappings are distributed between 3 of them. In my Unbound I have set about 18 overrides with a select few of them having 2-3 aliases. (Thus those are not that hard to recreate manually if need to be.)

One of the very few things that irked me for years has been the problem that I couldn't set a static mapping via an API call. e.g. when creating a VM via TF (or Pulumi, or whatever tickles your fancy, or even manually), it would be great to set a static mapping and when decommissioning the same VM, remove the mapping again. Afaik a lot of services got an API (kudos to the devs), but I haven't seen anything for ISC, thus moving to dnsmasq might be a good choice.
I think to remember a few years ago, the devs were suggesting to migrate to Unbound from dnsmasq (or maybe this was just for one issue in one forum topic), but it seems now it's the other way around. I don't really mind, as long as there is some workable migration. By "workable" I mean in an automated fashion that does not require me to recreate all settings, DHCP ranges, static mappings, and whatnot manually.
On the other side, if it absolutely has to be I probably can invest 5 or 6 hours to manually to do all this. The problem is that this process is rather error prone - manual work always is.
I have also noticed that some VMs (even though they are sending a hostname) get a DHCP address (no static mapping) but are not registered in the DNS. I am not sure why this is happening, but I think this started with 25.1. Either way, moving to dnsmasq might fix that as well.

Anyway, long story short, it would be great to use scripts to migrate to test dnsmasq only. If it doesn't work as I hope, it should be fairly easy to restore a backup and just use ISC/Unbound for now...

I'm trying to migrate from the OpenVPN legacy client connection component to the new instance component.
However, the new form is missing certain features. e.g. there is no way to use no compression (--comp-lzo no).

Then how do I set the following options? (which I've been using for my current openvpn connections)

Code Select Expand

tun-mtu-extra 32;
mssfix 1450;
persist-key;
persist-tun;
remote-cert-tls server;

I can set mssfix in the new form, but it's just a checkmark. There's no value field. So where do I put the 1450? In reality 1450 is the default value for mssfix, but what would I have to do, if I wanted to set another value? The fragment field is most likely the value for --fragment value so there's no way to set the mssfix value.

It also seems that persist-key and persist-tun have to be added to the options.

It's ok the deprecate and even remove functionality, but the new component should at least allow the same functionality as before.

Thanks for the reply. I've setup something like this https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html for Wireguard and something similar for OpenVPN. So certain devices on my network are routed through/via either Wireguard or OpenVPN.

I've read the documentation you quoted, but what I wanted to know was whether this only applies to fail-over multi-wan with multiple physical ports, or also applies to my setup. Because even though I only have one physical WAN port, I have different WAN interfaces (WAN, WAN_WireGuard, WAN_OpenVPN).
I highly suspect that my setup counts as multi-wan, but I wanted to confirm with the experts.

This was an interesting thread, but I have a question about the "reply-to" setting.

I have only one physical WAN interface, but I use one WG0 for incoming Wireguard clients and I have 2 other interfaces that handle outgoing VPN (OpenVPN and Wireguard) connections via separate gateways.
I guess this means I should also disable "reply-to" on WAN rules, correct? 

wireguard is working on the latest BE with zero issues.

What does BE stand for? If you use abbreviations, please use at least the full term once for acronyms that are not immediately clear. If it stands for "build environment", it still lacks specificty. e.g. which build environment, what repo, git hash, ...

I am not sure whether I am even in the correct board. Should this be in the "Virtual private networks" board or (since it isn't fixed) in the "25.1 Production Series" board?

Maybe @franco can chime in.

Thanks for the reply. I only saw it now, because for some reason I did not receive a notification for it.

If I activate dynamic gateway policy, an additional gateway is created, with the suffix _GW. You are correct that it shows as active, but I would have to change all my rules to use that new gateway. Thus it is probably easier to disable monitoring on the original gateway.

Either way, I hope this is fixed in 25.1. I haven't upgraded yet, because I will wait for .1 or .2

Shall I also open an issue in github for this?

Maybe a dev has an idea?