Messages

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.

Going through the release notes of the recent Opnsense version, I'm planning to eventualy switch over from ISC to DNSmasq for my home network. As I was going through setting up the Hosts entries for Static ips, I noticed that the VM I have Pi-hole running on with 2 virtual NICs, has the same DUID for each NIC, which makes sense since it's the same client. Currently ISC DHCPv6 shows that each NIC has a unique IPv6 GUA address, which I assume is because of the client host OS using SLAAC to assign the GUA IPs.

I'm probably just not reading the help documents correctly, or maybe there is a setting I need to toggle, or maybe make use of something else in Opnsense (alias? Unbound Overrides?), but I don't see any way it's possible for me to assign a Static IPv6 GUA address to each individual NIC, if they both use the same DUID (though they do have different MACs). Other then making a 2nd VM for the pi-hole (I abosuletely don't want to do this), what can I do?

I found it! Looks like the Spamhaus alias I have from ages ago is causing the issue.

Code Select Expand

http://localhost/scrape.php?v=4&url=https://www.spamhaus.org/drop/drop_v4.json
I'm guessing the local php file that was parsing the link isn't working any longer with the newer version of Opnsense, or was removed when I upgraded. For now I'll just disable it and figure out what to do. Didn't even think it was something firewall related, I thought it may have just been a bad link somewhere else.

Now that I think back, I believe that at the time I had added those aliases, Spamhaus didn't have a list that was compatible with the way Opnsense normally parsed URL lists, so the php script was used to parse it. Looks like thats changed since there is now a setup guide in Opnsense docs.

I guess this can be considered closed as the other issue with the service not appearing active in the main dashboard appears to have gone away about 2 updates ago as well.

I'm not even sure where to begin to look or what logs to enable. I don't think it's Unbound making the query to the Pihole, but something else in Opnsense. Is there a "catch-all" log I might enable where I could possible see the requests?

If this information helps:
I am running Pihole DNS server in its own dedicated VM. No other daemons or services run on it.
All clients on my network use the Pihole as their DNS server, both IPv4 and IPv6.
Opnsense is running Unbound as the primary DNS server that Pi-Hole uses, and I've configured firewall rules to only allow the Pihole access to Unbound, and only Unbound is allowed out the WAN to make DNS queries. Opnsense itself is configured to use the Pihole as a DNS server. So everything on my network is always:
DNS query > Pihole > Unbound > WAN
So afaik, Opnsense itself is making those wierd queries.

As I stated in my first post on this, Opnsense versions prior to 24.7.9_1, didn't have this issue.

Updated to latest 24.7.11_2 and the DNS issue is still ongoing. Still averaging around 11.5k requests daily each for "<html" and "<!doctype".

Speaking of man-in-the-middle, in my case, I prefer using DNS-over-TLS with Cloudflare because of thier no-tracking/logging policies, but also because it it's one less way my ISP (Verizon) can track the home usage.

For those who have similar ISPs that love to log everything and sell customer data, DoT could be useful.

Would a current backup of the Opnsense configuration not work with a release that is older but still in the same version, ie downgrading from the latest 24.7.9_1 to a earlier 24.7? I'm considering doing this myself, as I too seem to find some new quirk every other day with this latest release, when the previous update seemed to be running without any issues.