Messages

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]

If a client makes a DNS request to OPNsense instead of pi-hole, do you still see the client as the requester on pi-hole? Meaning: your pi-holes are on a different subnet and you NAT the requests?

My IPv4 LAN is on a single /24, no vLANs or seperate subnets. However, in your example, the origin should show as Opnsense, but again, I have Unbound (on Opnsense) behind a firewall rule. Only the 2 Pi-hole DNS servers can connect to it. Any other port 53 attempts (IPv4 & IPv6) through the gateway (Opnsense) get redirected (NAT) to the Pi-holes.

Also, I've never been to that site, or any of its related github links. I doubt very much any else in my household has visited that site either considering it's a technology related site. So I can only think of something running on a schedule.

What logging will I need to turn on? Just the logging in Unbound, or Unbound & some other logs in Opnsense? Also, if I'm logging all DNS queries in Unbound, what kind of log sizes can I expect? Opnsense is only using 10% of a 30GB VD, but I worry what would happen if the logs fill the available space and Opnsense started wigging out (as I've had happen in the past when the drive was full). The logging may have to good on for some days or even over a week, as the last time this happened was almost 1 week ago and it's been quiet till today.

PS; Hopefully I didnt mix up any terminology, but everything is on a single net of 192.168.2.0/24. IPv6 is via SLAAC and DHCPv6 with a /56 from the ISP. I've been playing around with assigning ULA, but that's only been for 2 devices for testing while I stilll try to learn DNSMasq and figure out how (or if) I will segment my network.

I have a wierd issue on my network and I'm stumped as to the origin. Opnsense, for the 2nd time in a week, has gotten rate limited by Pi-Hole, even with the limit set to 6000 DNS quieres in a minute by a client. I wasn't able to see anything in the Pi-hole logs the last time it happened (I didnt noticed it before "old" logs were purged), but this time I caught it. Seems like Opnsense is making DNS requests for "quantumwarp-dot-com", almost 8k requests in less then 15 seconds. I don't have any logging on the Opnsense side that would show why that is happening, but from the looks of Pi-hole, it's originating from Opnsense, as all LAN DNS requests must go through Pi-hole first, even those from Opnsense, before going through Unbound (on Opnsense) and out to the WAN. The last time I had malformed DNS requests, it was because of a old alias that was trying to update a no-longer installed script in Opnsense. Currently, I have nothing custom installed in Opnsense, and it is up to date. I do have some "new" to my network docker apps running, but again, the origin is showing as Opnsense.

Anyone else seeing these requests?

How should I go about finding the origin of these requests? Just start logging all DNS requests from Unbound on Opnsense?

My LANs DNS flow is as follows: Unbound on Opnsense makes WAN DNS queries, and is firewalled to only accept DNS request from the 2 Pi-hole DNS servers on my LAN. All LAN devices via DHCP settings are directed to the Pi-holes, and any attempts by LAN devices to connect to WAN DNS servers via port 53, are redirected to the 2 Pi-hole DNS servers. All DNS request which go through Pi-hole, would show up in the Pi-hole logs with the LAN client origin, which means if it was some other device other the Opnsense making those 8k requests, the log would show which client. In this case, it shows that its Opnsense.

Just checked 2nd DNS server logs and that one had over 3k requests in the same time frame. So all in total, Opnsense is making 11k DNS requests in less then 15 seconds for that one domain.

I'm planning on switching from ISC to DNSMasq. The only thing holding me up is some of the confusing jargon used in the "help" sections leaving me wondering if I do or don't need to set something, or even what I'm supposed to set in the first place.

That and I have over 40 static entries in the ISC DHCPv4 that I would need to recreate in DNSMasq, both for IPv4 and now IPv6.... I really wish there was a 1 touch "import from ISC" option in DNSMasq for static entries. Would make switchover *much* more easier for those reluctant to do so. *hint hint*

Can Unbound work with ISP assigned IPv6 prefixes in its overrides? I don't see any mention of being able to use ::x:x:x:x type address to use the ISP delegated prefix. I've assigned a ULA, but we all know in a Mixed IPv4 & IPv6 network, ULA is basically ignored in favor of GUA and IPv4.

I just noticed today that when I perform a nslookup of the Opnsense firewall FQDN on the LAN side, it responds with the GUA, the fixed IPv4 address, AND the external WAN IPV4 address.

Code Select Expand

Server:  dns.lan.internal
Address:  fe80::xxxx:xxxx:xxxx:xxxx

Non-authoritative answer:
Name:    opnsense.lan.internal
Addresses:  xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
          192.168.2.1
          xxx.xxx.xxx.xxx
Is this normal or some bad configuration on my end that I've made? I wouldn't have noticed it if my PC suddenly was unable to connect to the firewall via the FQDN.

Going by the post, its possible it was a expired token. I think I actually did restart my browser after I started getting 404 via FQDN. My PC stays on 24/7, my browser is usually only open when I have my PC unlocked. So I most likely had the browser restart as I did step away from my PC for a while after the issue.

Ok, this is really wierd. Just went to login to Opnsense using FQDN and it's now working like normal. I have no idea what's going on, as the browser has been open this entire time since I made the previous post when it wasn't working.

Just updated to 25.1.7_4 today. Everything seemed to be working fine. I closed out my browser, a few hours later I reopened my browser and am now getting a 404 error when trying to access the Web GUI via https and FQDN. Changing to http only changes the 404 error to "CSRF check failed. Your form session may have expired, or you may not have cookies enabled." when trying to login. Access via IPv4 address works as normal.

Anyone else having the same issue? Any suggestions? I didn't change anything from yesterday to today other then updating Opnsense, which was a small update. I had updated just last week so I believe I was on the latest update prior to 25.1.7_4

I'm having a similar issue. New opnSense install and it appears the dhcpv6 is handing out the router ip as the DNS. I need it to be the pihole ipv6.  How does one edit the config file?

You might want to check out Confused about the DNS Configuration in OPNsense?. Alot of the information given about setting up DNS properly in Opnsense is given there, even though it's not really a "how-to" or step-by-step guide. It's more of a better explanation of what each DNS setting avialable in Opnsense does, and how each setting affects other settings within Opnsense.

In case anyone is still wondering how to edit the config, simply download a configuration backup from 'System > Configuration > Backups', and open the .xml file in your favaorite text editor. Make whatever changes you need to make, save, then restore the "new" configuration back in Opnsense.

Usual word of caution, if you don't know what you're doing in the configuration file, don't do it.

I've come across a possible bug in DNS resolution of a local LAN FQDN address using ISC DHCPv6 static assignment.

My ISP issues dynamic IPv6 GUA prefixes in the /56 range. LAN is set to Tracking, RA is set to assisted, and I have Unbound setup as the main DNS server, and ISC handling DHCP for both v4 and v6 addresses, as well as passing both dynamic and static assignment DNS information to Unbound.

I normally have IPv6 addresses given out in a certain range (isp:isp:isp:isp::xxxx) via ISC DHCPv6, but am attempting to give out a Static IPv6 address to a single server for access outside my LAN. I configured this Static setting in ISC DHCPv6 by using the 'DUID Identifier', assigning a 'IPv6 address' in the form of (::1.2.3.4) since I have a dynamic IPv6 prefix, and used the same 'Hostname' for the client that I use in the DHCPv4 configuration. The client gets both the correct IPv4 and IPv6 addresses and I am able the forward traffic from the WAN side to the server in my network using its GUA IPv6 address that I assigned it.

The problem (bug?) comes when I try to access that server in my LAN using the FQDN (not IP). I noticed it would take some seconds (sometimes well over 30 seconds) before the server would respond when I tried to connect to it. Seeing as how I had made that ISC DHCPv6 entry just before the issue started happening I ran a simple 'ping server.lan.internal', and it was trying to ping the Static IPv6 portion of the address assigned to that server, *without* the ISP assigned prefix.

Code Select Expand

ping server.lan.internal

Pinging server.lan.internal [::1.2.3.4] with 32 bytes of data:
Running a nslookup resulted in the same portion of the IPv6 being reported without the ISP assigned GUA prefix.

Removing the 'Hostname' in the ISC DHCPv6 entry, restarting ISC DHCPv6 *and* Unbound services, did not clear the DNS responce. I had to reboot Opnsense in order to clear that responce. Once rebooted I was no longer getting any IPv6 address in nslookup, but this means that if I was trying to connect to the server on my LAN using only IPv6, I'd have to use the actual IP, and wouldn't be able to use a FQDN.

TL:DR -  It seems that ISC DHCPv6 is passing a incomplete IPv6 address to Unbound when using a dynamic IPv6 entry (::a.b.c.d) along with it's 'Hostname', and it won't clear without rebooting Unbound.

Primary purpose of the dual NICs is just to keep those OS' that require 2 distinct IP addresses for DNS servers, ie Android which will automatically insert a Google DNS ip for use if only 1 DNS server IP is given in DHCP. And yes, I already have Opnsense setup with blocking outbound DNS and fowarding all DNS requests to my Pihole for those clients that ignore the DHCP settings. I still prefer to have 2 actual working IP address for the DNS server.

Hoever, instead of having 2 Pi-hole servers running to acheive that, I opted for a single instance with dual NICs. Works fine for IPv4 and using Link-Local IPv6, but I see with the VM presenting only a single DUID that this would create an issue with Static IPv6 delegation via DHCPv6.

I've been trying to think of other ways, such as assigning 2 IP addresses (IPv4 & IPv6) to the DHCP client, but that seems only possible with the current new DNSmasq which isn't ready for roll out, so trying to figure out a way to work it with ISC and possibly future proofing my setup for the switchover to DNSmasq without having to redo my network yet again, and again, and again...

PS: Trying to set Static IPs on the host is a no go with GUA IPv6 as I have Verizon which only uses Dynamic prefixes. ULA is pretty much useless in a mixed IPv4+IPv6 network, so that option is also out. Gotta stick with GUA as I do have some services I need accesible from the WAN.