Messages

Ok, I installed the ISC-DHCP plugin, disabled it on WAN, then was able to set my WAN IPv4 to DHCP. Looking at the updated config file, it looks like I just needed to remove the '<enable>1</enable>' line altogether.

Can I make a feature request here? It would be great if OPNsense would remove this line when the ISC-DHCP plugin is not installed, or ignore it when configuring the WAN interface.

I downloaded the config file and found this:

Code Select Expand

  <dhcpd>
    <lan>
      <range>
        <from>192.168.97.10</from>
        <to>192.168.97.245</to>
      </range>
    </lan>
    </wan>
      <enable>1</enable>
      <ddnsdomainalgorithm>hmac-md5</ddnsdomainalgorithm>
      <numberoptions>
        <item/>
      </numberoptions>
      <range>
        <from>192.168.2.100</from>
        <to>192.168.2.110</to>
      </range>
      <winsserver/>
      <dnsserver/>
      <ntpserver/>
    </wan>
  </dhcpd>
I changed the 1 to a 0 and uploaded the config, but I'm still seeing the error. I believe this is a remnant from when I was running ISC DHCP server in 24.7.x. I used 'opnsense-bootstrap -r 26.1' to get up to date, but I guess this part of the config was left behind. I'm not sure how to remove it properly.

26.1.9

I had to enable the Dnsmasq DHCP on my WAN interface temporarily to access a modem that was connected there. Once done, I disabled Dnsmasq and removed all options and scopes. Then I tried to change the WAN's IPv4 configuration from static to DHCP and got the red notice:

Code Select Expand

The following input errors were detected:

    The DHCP Server is active on this interface and it can be used only with a static IP configuration. Please disable the DHCP Server service on this interface first, then change the interface configuration.
I confirmed that Dnsmasq and Kea are disabled. ISC plugin is not installed. The Services widget on the dashboard doesn't list any DHCP server. I even rebooted, but the error persists.

How do I get rid of this error message so I can enable the DHCP client on the WAN interace?

Yeah the alias was disabled :P I'm a little disappointed in how long it took me to figure that one out.

I removed the redundant '10.15.4.0/24' from the 'allowed_internet' alias and this fixed the problem.

edit: never mind, this did not fix the problem.

Yeah, the rule I showed in my first post is the partial output of

Code Select Expand

pfctl -sr. I'm not sure why it looks different in /tmp/rules.debug.

Other than logging, source and label, the two rules in /tmp/rules.debug look identical to me. I'm not using Advanced Features on either of these rules, and I think not on this firewall at all.

Code Select Expand

pass in log on aINTERNAL route-to ( wan_gw ) inet from {10.15.4.52/31} to !$rfc5735 keep state label "..." # Log Pass allowed to internet
pass in on aINTERNAL route-to ( wan_gw ) inet from $allowed_internet to !$rfc5735 keep state label "..." # Pass allowed to internet

OPNsense was version 25.7.11_2 when I noticed the problem, but upgrading to 26.1.3 hasn't fixed it.

I have a floating rule that allows internet access from multiple hosts on several networks (see screenshot). It looks like this in pfctl:

Code Select Expand

pass in on aINTERNAL route-to (wan_gw) inet from <allowed_internet> to ! <rfc5735> flags S/SA keep state label "..."
For some reason, about a week ago some hosts on multiple networks lost access to internet, as if this rule stopped matching packets. One such host has the address 10.15.4.52.

As you can see in the screenshot, I copied this rule and changed only the source from the alias to the explicit network 10.15.4.52/31 and enabled logging. This enabled this specific host to access the internet and the packets are logged as expected.

As you can also see in the screenshot, I have only one block rule in the floating rules. I can confirm there are no block rules in the group or on the interface specific to that network.

And finally, you can see in the screenshot that the alias <allowed_internet> includes the 10.15.0.0/21 network.

As these rules are not quick, I also moved the new rule above the old one, and the new rule still matches, passes and logs the packet, as if the old one isn't matching.

So why did the old rule stop matching packets while the new rule matches packets that should have matched the old one? The old rule used to work, and then stopped working at some point (at least for a handful of hosts that I've tested). I can't think of an explanation except that I'm seeing some sort of bug having to do with the rule or the alias.

So I scheduled the interface reset for a few minutes after midnight, but as it turned out, OPNsense grabbed a new lease with the new IP address 1 or 2 minutes before midnight. I'm not sure what triggered it, but there must have been something on the provider's side that minimised my down time. I ended up deleting the cron job before it ran.

OPNsense 25.7.11_2

My ISP has informed me that my assigned IP address will change at midnight. Looking at /var/db/dhclient.leases.igc0 (WAN), I see that my lease is valid for a few more days.

So I set up a cron job for shortly after midnight for periodic interface reset on wan. Will this have the desired effect of renewing the lease on the WAN and pulling the new address?

Thank you for the suggestion. How did you know the pre-authentication key was expired? My hosts have expiry disabled, but I'm not sure how to check the status of the key.

Now I've updated one of these two firewalls to OPNsense 25.7.7_4 and after a reboot Tailscale is still showing no peers and is not seen on the Tailscale Admin Console. I generated a new auth key and applied it and the host is now connected again. It seems the original auth key expired or somehow became invalid, even though it was generated without expiry, and I haven't found a log on the host itelf or the Tailscale console to confirm this.

OPNsense 25.7.4-amd64
Tailscale plugin 1.2 (1.88.1)

I have multiple firewalls running Tailscale. On November 1 two of these dropped off the tailnet. The hosts are still online, but when I look at their Tailscale status it shows that the service is running, but no peers are visible. I restarted the service but it's still not connecting to the tailnet. Key expiry is disabled for these hosts and they were initially connected using a pre-authentication key.

I don't see any Tailscale logs. What's the best way to troubleshoot this before I just update the firmware and reboot without knowing?

I have a pair of firewalls that I just updated from 25.7.2 to 25.7.5. As usual, I updated the backup firewall first. After it rebooted I updated the primary firewall. After it rebooted I expected the primary firewall to become CARP master, but it didn't. I then tried temporarily disabling CARP on the backup firewall, but it just generated an error "200". I got the same error trying to enter it into CARP maintenance mode.

I suppose I could just reboot the backup firewall, but I'd prefer to know what's not working properly. How to troubleshoot this further?

edit: after a few minutes the primary resumed master role. I guess more patience is all I needed in this case.

I ran opnsense-bootstrap without options and I have a working 24.1 system now that I can upgrade from.