Messages

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]

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