Messages

WORKAROUND

In your web UI, set the "Pre-authentication Key" to "file:/dev/null".  This effectively works the same as not specifying an auth key and achieves what I described in my previous comment.

ps: Also check this Github issue: https://github.com/opnsense/plugins/issues/4661#issuecomment-3186000984

Thank you sir.  I had never had any issue until this past weekend when we had a power outage. Changed the authkey as you have above and all fixed.

In the WAN DHCP Settings, there is a setting for "Reject Leases From" described as "If there are certain upstream DHCP servers that should be ignored, place the comma separated list of IP addresses of the DHCP servers to be ignored here. This is useful for rejecting leases from cable modems that offer private IPs when they lose upstream sync."

I have added the IP of my cable modem (Coda 57) "192.168.100.1" to this field.

When my cable carrier drops, my opnSense WAN interface still gets a 192.168.100.xx IP address and doesn't let it go until next DHCP refresh. Today they did some work in my neighborhood and everything went down at 9am and I ran home at lunch to get it back up by simply reloading the interface.

It seems the above setting is meant specifically for this issue, but is not working properly. Has anyone else run into this, have a way to fix it, or any suggestions?

opnSense has been fully updated, and the issue has remained for the year I've had this new provider and this modem.

I had the same issue after update and creating a new key solved it.  Another issue I'm not having with Tailscale is my exit node (through opnsense) just stops working from time to time.  I can still access my network but if I enable the exit node, I have no network connection.  If I uncheck advertise, apply, recheck advertise, apply, it starts working again.

Updated to 22.1.2 last Friday.  Each night since, both Unbound and Suricata have been in a stopped state when I get up in the morning.

Code Select Expand

2022-03-13T04:34:50-05:00 Informational unbound [71050:0] info: service stopped (unbound 1.15.0).
2022-03-13T04:20:39-05:00 Informational unbound [71050:0] info: start of service (unbound 1.15.0).
2022-03-13T04:20:39-05:00 Notice unbound [71050:0] notice: init module 0: iterator
2022-03-13T04:20:39-05:00 Notice unbound daemonize unbound dhcpd watcher.
2022-03-12T20:34:14-06:00 Notice unbound dhcpd expired MTXINABOX @ 192.168.37.200
2022-03-12T20:33:13-06:00 Notice unbound dhcpd expired dan-Standard-PC-i440FX-PIIX-1996 @ 192.168.37.179
2022-03-12T16:02:08-06:00 Informational unbound [41343:0] info: start of service (unbound 1.15.0).

Here we see me restarting the Unbound service yesterday afternoon at 4:02pm after coming back from a trip.  Then it needs to start the service again at 4:20am?  And then stops the service at 4:34am?  From 4:34 until when I manually start it again in the morning there's 7 pages of statistics all generated within 2 minutes of that service stop.

Code Select Expand

2022-03-13T04:31:27-05:00 Notice suricata [100278] <Notice> -- all 3 packet processing threads, 4 management threads initialized, engine started.
2022-03-13T04:23:28-05:00 Notice suricata [100207] <Notice> -- This is Suricata version 6.0.4 RELEASE running in SYSTEM mode
2022-03-13T00:02:37-06:00 Notice suricata [100188] <Notice> -- rule reload starting
2022-03-12T16:10:09-06:00 Notice suricata [100188] <Notice> -- all 3 packet processing threads, 4 management threads initialized, engine started.
2022-03-12T16:02:14-06:00 Notice suricata [100101] <Notice> -- This is Suricata version 6.0.4 RELEASE running in SYSTEM mode

For Suricata we see me starting it at 4:02pm yesterday (again, when I got back from a trip), no information until the Rule Reload at 2:37am.  Nothing showing the service stopped for any reason and yet here I am starting the service at 4:23am today.

How can I figure out what is causing these services to stop? 

Again, forgive me as I'm not a developer and such...

Thanks for the update on that.  I'm not sure what you would like for implementation feedback, just testers or what settings should be placed in the UI? 

I wouldn't say it is necessarily "important"? but I don't believe it is expected behavior to query unbound and have it come back with a default domain when a machine is on a different vlan with different domain.  That's how I wandered into this thread.  More than likely users just don't care or don't do rDNS lookups often?  No idea.

Really appreciate the work on OPN, I've been pretty happy with it overall.  This isn't a sticking point where I would go through the work of switching or putting my USG (shudder) back in place.

From GitHub, it looks like this has been solved? How can I test the new version?

I may have gotten lost in the conversation of the original problem and the talk of DDNS.  Are you saying Unbound handling multiple domain names on different VLANs has been fixed?

I'm fully updated and have the same issue as the OP.  Wondering if there is a solution coming or not.  It's not a huge deal, just easier to understand what device I'm looking at on a rDNS lookup (pi-hole stats).