Messages

Its one or the other,IPv4 -or- IPv6. You have to create individual IPv4 options, and seperate IPv6 options.

For your dns-server [6] option, that would only apply to IPv4, and the ip address you enter would of course only be IPv4 ip, seperated by a comma if entering multiple addresses.

In the DNSmasq Interface setting, after you disabled the WAN interface, were the other interfaces that you do need DNSmasq on checked? I just finished the swithover from ISC to DNSmasq myself today, and didn't see any such warnings in my DNSmasq logs. I know the little help blurb for Interface says "If no interfaces are selected, Dnsmasq will listen on all available IPv4 and IPv6 addresses by default", but I find more often then not, that you have to add in or explicitly choose an option to make sure it actually works.

Per default it sets the domain in the range exactly for the range.

That means reservations outside the range will get the default domain from general settings.

You can change that by opening advanced mode in the range and moving the domain type to interface.

Thanks for that clarification. I actually already have domain type set to interface since the OPNsense GUI help said it should be set to interface if using IPv4 and IPv6 ranges.

I'm in the process of switching from ISC to Dnsmasq and was reading through the OPNsense manual site again to make sure I'm sure configuring everything correctly when I came across this note under Dnsmasq DNS reservations:

A dynamic range like 192.168.1.100-192.168.1.199 and a reservation like 192.168.1.101 are valid and there will be no collisions.

The reservation can also be outside the dynamic range, but it is not recommended for simple setups as the dynamic dns registration with dhcp-fqdn will not work correctly.

If I understand this correctly, setting a reservation outside of the dynamic range will result in the FQDN of the reservation not working (not resolving)? Is this correct?

I've always setup those systems that require a fixed static IP (Proxmox for example) and static IP reservations via DHCP, seperate from the range that I used for dynamic assignments. I've always worked under the assumption since my early internet days, that setting a DHCP reservation in the dymanic range might result in collisions, for instance if the system that would normally recieve a fixed DHCP reservation wasn't on the network and a different system got assigned that particular IP address. I get that a modern setup like OPNsense should be "smart" enough to prevent that, but not having the FQDN resolve would be an issue. Can anyone confirm this? If its true and problems can occur, I'd have to redo how I have my IPs assigned on my LAN all over again.

BTW: the more general approach would be to use the device's MAC instead, because the EUI-64 is not the only way an IPv6 device can communicate - think of IPv6 privacy extensions.

What exactly do you mean "use the device's MAC instead"? Is it possible to use MAC addresses instead of IPs in OPNsense? Or are you talking about the LLA (fe80:) address?

As for DNS (or any other) services on your network: Keep in mind that you do not need a specific DNSv6 server at all, because IPv6 can be resolved via DNSv4 just fine. So, if you have dual stack on your LAN and have a working DNSv4 server, you are all set.

I thought if a device used the IPv4 address of the DNS server, the DNS server would only give an IPv4, or the client would default to sticking with IPv4. If this is the case that the client will get an IPv6 and use the IPv6, then yes, it really wouln't matter if I just keep the DNS servers with IPv4 addresses.

Thus, you usually do not need to distribute DNSv6 via DHCPv6 at all. Strictly speaking, you do not need DHCPv6 either and with dynamic IPv6 prefixes, you should probably better use SLAAC in the first place. See this for why.

Yes, for those clients that can only use SLAAC (Android and IoT devices being main culprits on my network), I don't bother with DHCPv6 for those devices. But the systems that do support DHCPv6, I setup for SLAAC + a fixed GUA address, as a couple I have open to the WAN via GUA IPv6 addresses.

OPNsense itself does not go through the Pi-holes since Unbound is active and the option to disable using itself (127.0.0.1) for queiries is disabled (not check marked).

However, pretty much any and every DHCP configuration section(s) that allows you to set a DNS server (besides System > General) will tell you that if a DNS server is not set, it will use the DNS server entries already set in System > General. So one setting should cover any and every other section that could also use that setting, instead of manually configuring each and every entry.

Yes, I run a pair of Pi-holes strictly for ad-blocking, into Unbound on Opnsense with a override list for those systems that have a fixed IP and recursive quieries, and currently use ISC+RA for DHCP/DHCPv6. I'm in the process of (finally) switching over to DNSMASQ for DHCP/DHCPv6/RA, hence why I'm wondering where I can use the partial IPv6 address cause I want to use GUA for all the systems that work with DHCPv6. I had tried ULA, but it didn't seem to play nice on the LAN (systems randomly were inaccessible from one moment to another, Unbound would spam the Pi-holes with thousands of requests a second [infinite loop?]), and it's my understanding that in a mixed IPv4/IPv6 environment, ULAs will pretty much be ignored if a IPv4 or GUA is available in a DNS response. I currently use the LLA address of the Pi-holes for its IPv6 address which seems to work. But if I can make use of partial GUA IPv6 addresses everywhere, I'd rather try to do that.

I know I'm going to use the wrong terminology, but hopefully the question will be understood.

My ISP (Verizon) designates a prefix for IPv6 addresses, and it is not fixed. So in sections such as "Firewall > Aliases", or "ISC DHCPv6", I need to use the shortened IPv6 address, such as "::aaaa:bbbb:cccc:dddd". But what about sections such as "System > General > DNS Servers"? Is there a list of where the ::x:x:x:x shortcut can be used, or where it can't be used?

I didn't even know that DoH used that many ports. I thought it was just the typical 80 and 433. I'll give it a whirl and see how it work on my network. Thanks.

Already have 53 and 853 blocked, and 53 forwarded. I'm more concerned about DNS over HTTP and supposedly that site also tracked DoH sites, and thier list was updated daily. Keyword there seeming to be "was". Even looking at the country listings shows everything lat being checked 2 or more years ago.

I should probably ask if there is a known realiable regularly updated list of DoH servers to use for blocking purposes?

To anyone in the know, is public-dns.info still actively updated? Thier last changelog entry is from 2020, and on the main front page the recent server last checked times all show 2 years ago. Thier Contact link also forwards to a different site.

If they aren't active anymore, is there another such actively updated public DNS server list that I can use in Opnsense as an alias for blocking purposes?

Is it possible that Opnsense can get into a infinite loop with the DNS server(s)?

I'm really not sure, in what scenario would you think that a loop be possible? The flow should be either 'client - pi-hole - unbound' or 'client - OPNsense - pi-hole - unbound'. Would there be a situation where unbound sends a request to pi-hole?

The alias that I use in the NAT rule that allows the Pi-hole servers to use the Unbound service on Opnsense, only has the IPv4 and LLA IPv6 of each Pi-hole server. If the Pi-hole server uses any of thier GUA IPv6 address to try to query the Unbound service on Opnsense, Opnsense would just forward (NAT) that request back to the Pi-hole server since the GUA is not in the alias of that NAT rule. I can see that happen on a regular basis in the logs, but again, I don't see (yet?) any appear to be a infinite loop. I've yet to see the issue crop up again so far since removing the ULA prefix (which the Pi-holes were also using) from my network.

You redirect does work, indeed.

If I remember correctly, in the case of a device trying to query (let's say) 1.1.1.1, on pi-hole the originating client is listed as OPNsense, since it is forwarded from OPNsense. Is that not so? That is why I thought it would be helpful to have logging for one or all of these rules enabled, temporarly.

If you now manually query 1.1.1.1 from a client, what does the pi-hole show as the client?

It does show as originating from Opnsense when the request gets redirected (NAT).

Is it possible that Opnsense can get into a infinite loop with the DNS server(s)? I noticed that the Pi-holes sometimes use thier GUA address to make a DNS request, which is not one of the addresses I have in the "DNS_IPv6" alias in the firewall rules. The GUA address is being created using the ISP assigned /64 prefix, which is *not* fixed, via SLAAC, as well as creating another GUA address via DHCPv6. Neither of those IPv6 addresses are in the alias, so I can imagine a loop occuring, but the logs currently don't show that happening.

Some IoT devices ignore the DHCP assigned DNS servers, or have hard coded DNS servers. I recall my living room TV was one such device, ignoring DHCP assigned DNS server, even though it was using DHCP for its IP address. Had to go digging deep in menus to disable it using its own "preferred" DNS servers. Now-a-days, you also have web browsers that will also ignore the assigned DNS servers in favor of using whatever DNS servers they want as well. It's also why I run with 2 DNS servers instead of 1, cause Android devices will automaticallly use a Google DNS server for the 2nd "backup" DNS server if only given 1 DNS server through DHCP (and tend to prefer the Google server over the primary assigned one). I have DNS over TLS port blocked as well, but clients trying to use that port will usually fall back to normal DNS, so that's still covered without any additional rules besides the block. Only thing I can't realiable block is DNS over HTTPS, since that would require blocking some commonly used websites.

My IPv4 LAN is on a single /24, no vLANs or seperate subnets

That means if something (virus/malware/rough application/script) is trying to contact a public DNS directly, it will show up on the pi-holes as if the query came from OPNsense but it may really be originating from a client.

Is this true? With the firewall rules I have in place, I cannot directly query Unbound sinces it's on Opnsense, from any of my PCs/VMs. All DNS requests get redirected to the Pi-holes. Or at least thats how it appears to be working to me.

NAT >  Port Forward

Code Select Expand

LAN TCP/UDP ! DNS_IPv4 * * 53 (DNS) DNS_IPv4    53 (DNS) DNS redirect IPv4
LAN TCP/UDP ! DNS_IPv6 * * 53 (DNS) DNS_IPv6    53 (DNS) DNS redirect IPv6
Rules > LAN

Code Select Expand

In IPv4+6 TCP/UDP DNS_Server  * * 53 (DNS) * * Allow Pihole to contact Unbound
In IPv4 TCP/UDP ! DNS_IPv4  * DNS_IPv4  53 (DNS) * * DNS redirect IPv4
In IPv6 TCP/UDP ! DNS_IPv6  * DNS_IPv6  53 (DNS) * * DNS redirect IPv6
In IPv4+6 TCP/UDP * * * 53 (DNS) * * Reject all DNS to WAN and Unbound
Is this wrong? Or must the DNS server be on a seperate subnet (vlan?) for it to work properly?

[Edit] Aha! I think I understand now what you are saying. You mean if Opnsense gets a DNS query, because it's NATing it to Pi-hole, it will appear to Pi-hole as if it's originating from Opnsense, and not the original client that made the query? [/edit]

[Edit2] It just happened again twice in a row. Thousands of DNS queries in seconds showing as originating from Opnsense, except this time it was more familiar sites, including some of my own LAN only FQDNs. Internet access also started to go down as site were no longer resolving. Restarting Unbound in Opnsense fixed that. Something is either acting up in Opnsense, or theres something else amiss in my network. [/edit]