Topics

Was checking up on my NTP server and noticed a connection from Censys in the logs. I already have an alias with every IP range Censys uses, setup for blocking in the Opnsense firewall, and that particular IP address is indeed in one of the ranges in the alias (66.132.186.0/24). However, as I stated, it did make it past Opnsense to the NTP server in my network.

I noticed a similiar behavior previously with the GeoIP alias as well. I would add in an entire country to ban from accessing one of my services via a GeoIP alias, but I would see in the logs of the daemon that IPs from that country were still coming through. I chaulked that up to maybe GeoIP wasn't up-to-date, but it kept happening very frequently, to the point where I was creating my own alias of the IP ranges (/24) to ban in a seperate alias. That usually took care of the issue, but occasionally a connection attempt from one of those blocked IP ranges would still get through.

Has anyone else experienced this?

I am probably misunderstanding how Crowdsec works, but from what I have read, it seems that Crowdsec doesn't monitor the packets going across the interfaces like other IDS/IPS software does, but instead just watches firewall logs for any known abusive patterns. Does this mean that if I have any IP blocking lists in the Opnsense firewall, that I need to enable logging on each entry in order for Crowdsec to "see" any potential patterns? Or is the enable logging option only for the users eyes, and internally Opnsense still keeps logs?

I ask because after adding in some block lists, my Crowdsec Console reports that it's been very quiet from my setup, which could mean either I screwed up the settings and its no longer reporting (not likely because it still sees the firewall and other systems reporting on my network), or as thier own popup help states, that it could just be there is nothing to report on (the blocklists are blocking any suspicious activity, but Crowdsec doesn't see it).

Was setting up a port forward and IPv6 passthrough for my NTP server and came across a issue trying to setup the IPv6 part.

When creating the alias, I accidently created a type 'Host(s)' alias instead of a type 'Dynamic IPv6 Host' alias. I didn't realize what I did because the type 'Host(s)' alias did not give an error when I used the second half of the IPv6 GUA address for the machine. When testing, Opnsense was blocking the incoming connections with 'Default Deny/State Violation Rule'. Upon checking the rule and alias, it was then I realized I had that alias type set as 'Host(s)' instead of 'Dynamic IPv6 Host'. So I simply changed the type to 'Dynamic IPv6 Host', and tested again, only for Opnsense to continue to block the incoming connection. I couldn't figure out why as everything, the rule and alias, should be correct now. I thought maybe it was something with the rule and spent the next hour+ editing it, deleting it, manually recreating it, and even cloning the working IPv6 pass rule I already had in place for another service. It wasn't untill I deleted the Alias and recreated it from the start with the correct type 'Dynamic IPv6 Host' set, that the rule then started to work and the connections could pass through the firewall.

Currently running:
OPNsense 26.1.4-amd64
FreeBSD 14.3-RELEASE-p9


TL/DR - If you attempt to create a Alias for a dynamic IPv6 host, but you choose type 'Host(s)' and save, you cannot simply change the type after to correct it. You must delete the Alias, and recreate it again with the correct type.

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.

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?

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?

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 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.

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'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.

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?

Yet another issue I've found which does cause minor problems. I switched the hardware I was running my DNS server (Pi-hole) on, updated any and every entry in Opnsense in regards to IPv6 address (I use fixed link-local fe80: addresses for this), and many of my devices are still using the old IPv6 addresses for DNS server. I've deleted all the leases, I've stopped the ISC DHCPv6, disabled the service entirely, deleted all IPv6 leases in Opnsense list, re-enabled, restarted, forced clients to renew DHCP, and yet they are still getting and using the old IPv6 addresses for the IPv6 DNS servers. Only 1 of my computers so far has changed the IPv6 DNS server address entries to the updated ones.

I exported a configuration to see if I could find where that old IPv6 was showing up and found them in the <dhcpdv6> section.

Code Select Expand

<dhcpdv6>
    <lan>
      <domainsearchlist>home.lan</domainsearchlist>
      <ddnsdomainalgorithm>hmac-md5</ddnsdomainalgorithm>
      <enable>1</enable>
      <range>
        <from>::0</from>
        <to>::ffff</to>
      </range>
      <prefixrange>
        <from/>
        <to/>
        <prefixlength>48</prefixlength>
      </prefixrange>
      <dnsserver/>
      <ntpserver>fe80::xyz</ntpserver>
      <numberoptions>
        <item/>
      </numberoptions>
      <ramode>assist</ramode>
      <rapriority>medium</rapriority>
      <ramininterval>200</ramininterval>
      <ramaxinterval>600</ramaxinterval>
      <radomainsearchlist/>
      <radnsserver>fe80::aaaa</radnsserver> #This contains the old IPv6 DNS server address
      <radnsserver>fe80::bbbb</radnsserver> #This contains the old IPv6 DNS server address
    </lan>
  </dhcpdv6>

The <radnsserver> entries contain the old IPv6 DNS server entries, and I have no idea how to change that in the GUI. I can't even find any reference to that in the ISC DHCPv6 panel at all.

I did however manage to "fix" the issue by editing the configuration file and uploading/applying the new configuration to Opnsense. Now the new IPv6 DNS server addresses are being given to the DHCPv6 clients on my network. If I simply deleted those entries, Opnsense would start giving out the IPv6 address for my ISP dns server (definetely not what I want) even though I have the IPv6 DNS server address entries in System>Settings>General tab setup. I had to change the IPv6 addresses for both of the <radnsserver> entries.

Again, that did fix the issue, but I still have no idea where in the Opnsense GUI that can be changed, if at all, nor why Opnsense continued to use those old entries, and ignore the new ones, when the appropiate changes where made in the ISC DHCPv6 panel.

After updating to OPNsense 24.7.9_1-amd64 via GUI, I'm having 2 issues, 1 very similar to a previous issue in the previous version(s) (22.x-23.x).

First issue; netdata daemon in both the Dashboard>Services info box, and under Services>Netdata>General, shows as not running (Stopped with option available to start), when in fact it is running and available. Attempting to resolve the discrepency in the Opnsense GUI by either Restarting the service, or Stopping then Starting the service, results in Netdata failing to restart at all, and it wont restart until Opnsense itself is rebooted.

This was similar to an issue in 22.x-23.x when certain VPN services would exhibit the same exact issues. I don't believe it was ever fixed. There was a work around but I didn't know how to perform it since there were never any clear instrustions given on how to do so.

Issue 2; ever since update to 24.7.9_1, I now have over 11.5k DNS queries for "<html" and "<!doctype" every 24 hours orginating from my Opnsense box. I'm still going through the various services I have running on some of VMs in my network, but so far it does seem to be Opnsense making those queries, not any of my other VM/PC in my network.

Neither issue is affecting my network or causing downtime, both appear to be just annoyances.