Topics

[Observation]

Updated to 24.7.3_1 with no real issue except for one plugin which I no longer needed due to the new dashboard capabilities..kudos!

Observation: If i leave the dashboard up for more than 30 minutes or so the animated based widgets either pause, hiccup or stop all together with the occasional page crash.

This happens in edge or in chrome that I've noticed so far.  I've also tried tweaking some of the browser's process and power saving settings to test to see if they were interfering here but I haven't found any correlation.

A simple refresh of the page corrects the issue for a short period of time and then it returns.  Is this a known issue?

Just updated and it updated to 24.1.10_2 but when I read announcements there is only mention of 24.1.10 plus 24.1.10_1 hotfix.

Did I just beat the announcement?

[Problem]

Problem: Trying to setup my OPNsense box as a nut master but no matter what configuration options I try I can't get it to function properly.

Physical Setup: OPNsense box is connected to my APC Back-UPS XS 1500M

Steps I've tried:  I can get the Apcupsd plugin, via USB cable type and UPS Type: USB, to talk with my UPS.  Status shows all the appropriate information.  Documentation says this service alone can be setup as a server but it is VERY unclear on how to accomplish that.

I then install the Nut plugin.  I've tried disabling Apcupsd and setting nut to communicate via USBHID and I've tried to use the Apcusd driver with the Apcusd plugin enabled; in either scenario, I can't see anything in the Nut diagnostics about the battery unit at all.

Question: What am I missing?  The web and YouTube are surprisingly lacking in content on this scenario.

The report for Unbound (not the logfile) appears to stop functioning until I restart unbound.  DNS resolution still works but the report shows zero queries.

Anyone come across this?

[Observed Behavior]

Observed Behavior: Tier 1 GW has enough packet loss to be marked as down.  Tier 2 GW kicks in and everything transitions nicely.  Tier 1 connection goes back to online/green, 0% packet loss, and SOMETIMES connections fall back to Tier 1, sometimes they don't.  I have not been able to pin down when it does versus it doesn't.

I've seen various posts on this but haven't seen relevant solutions.  Anyone have any thoughts?

Bonus notes:

• Clearing the entire state table does NOT cause connections to fall back
• Physically removing the connection to Tier 2 GW or rebooting that device DOES cause all connections to fall back to Tier 1 connection smoothly
• My nvidiashield pro, which is constantly streaming most of the day, NEVER falls back to Tier 1 GW unless I force via the method above

Configuration Notes:

• OPNsense version 23.1.11
• IPv4 only, IPv6 disabled
• Relevant Firewall Rules: IPv4 Lan Network Pass rule to Gateway group
• GW 1 is set to Tier 1
• GW 2 is set to Tier 2
• GW Group Trigger Level was "Packet Loss".  I'm now testing "member down"
• Monitor IP of GW 1 is 8.8.8.8
• Monitor IP of GW 2 is 8.8.4.4
• Allow default gateway switching is enabled
• System DNS Servers - 9.9.9.9 assigned to GW 1, 149.112.112.112 assigned to GW2
• NAT: Outbound Mode is set to "Hybrid outbound NAT rule generation"
• I do NOT use Wireguard
• I do NOT use Suricata
• I do NOT use any plugins related to routing or DNS
• I DO host OpenVPN server for "road warrior" purposes - no active connections
• Sticky Connections is NOT enabled

[PROBLEM]

Before you beat me up on this topic being brought up before, in various forms; you're right.  However, in my searching, I found ZERO resolutions outside of "rebooting" which is not what I'd want to do with an enterprise class option like OPNsense.

Internet Provider Context:

• WAN - Cox Cable - Cable Modem (Private/bogon networks blocked and Reject leases from 192.168.100.1 set
• WAN2 - T-Mobile Home Internet

PROBLEM: After an outage or issue with the Cox Cable connection (WAN), OPNsense fails over to T-mobile (WAN2) pretty gracefully.
After Cox corrects their issue, I'm unable to get a valid IP from the Cox Cable modem unless I reboot the OPNsense router.

ATTEMPTED STEPS TO RESOVLE: If I go to INTERFACES: OVERVIEW, and select the WAN interface (wan, igb0) I do see both "Reload" and "Release" as options for DHCP.

If I attempt either, usually one of 2 things happens:

• I can see the gateway assigned to the interface but i'm given no IP address or DNS servers
  
• It hangs and is completely blank

I can do try these options for many times and the result is always the same.

The ONLY thing that allows me to receive an IP again is rebooting OPNsense.  This tells me, given its inability to communicate properly to obtain a refreshed IP without rebooting is clearly an OS/Driver/OPNsense issue.

Anyone know why this could be?

[PROBLEM]

Before you beat me up on this topic being brought up before, in various forms; you're right.  However, in my searching, I found ZERO resolutions outside of "rebooting" which is not what I'd want to do with an enterprise class option like OPNsense.

Internet Provider Context:

• WAN - Cox Cable - Cable Modem (Private/bogon networks blocked and Reject leases from 192.168.100.1 set
• WAN2 - T-Mobile Home Internet

PROBLEM: After an outage or issue with the Cox Cable connection (WAN), OPNsense fails over to T-mobile (WAN2) pretty gracefully.
After diagnosing the issue with the primary WAN connection and bring it back up, I'm unable to get a valid IP from the Cox Cable modem.

ATTEMPTED STEPS TO RESOVLE: If I go to INTERFACES: OVERVIEW, and select the WAN interface (wan, igb0) I do see both "Reload" and "Release" as options for DHCP.

If I attempt either, usually one of 2 things happens:

• I can see the gateway assigned to the interface but i'm given no IP address or DNS servers
  
• It hangs and is completely blank

I can do try these options for many times and the result is always the same.

The ONLY thing that allows me to receive an IP again is rebooting OPNsense.  This tells me, given its inability to communicate properly to obtain a refreshed IP without rebooting is clearly an OS/Driver/OPNsense issue.

Anyone know why this could be?

I first noticed double the memory usage of the router than usual.  With my configuration it usually uses anywhere from 2-4GB.  It's currently using over 8GB of RAM.

I ran a netstat -Lan and got the following (*filtered):
Proto Listen Local address
tcp4  193/0/128   *.53

This pointed me to DNS; running unbound, I attempted to restart the service but I saw no change in the listening queue or memory usage.

I continue to get the following notices at consol:

sonewconn: pcb 0xfffff8010279d1f0 (0.0.0.0:53 (proto 6)): Listen queue overflow: 193 already in queue awaiting acceptance (3 occurrences)

Anyone else get this or know what to do here?

Updated to 22.7.3_2 this morning and the system came backup with my primary LAN showing 90%+ packet loss. At first I thought it was just a GUI glitch, but it ended up being real.

Checked relevant logfiles that I could think of and didn't see anything alarming.

Decided to just reboot the system again and it came up perfectly, no more packet loss.

Posting to see if others have seen behavior or have ideas on what/where to look in the logfiles for anything meaningful to share.

[6/26 - Update]

Went to view the Unbound logfile, page kept running.  I was able to navigate away and everything is working fine, but the process is now constantly consuming 25-40% of CPU.  Been running for the past 20 minutes so far.

Checking the system logs, the command consuming the CPU is:

/usr/local/bin/python3 /usr/local/opnsense/scripts/systemhealth/queryLog.py --limit 20 --offset 0 --filter --module core --filename resolver --severity Emergency,Alert,Critical,Error,Warning python3.8

6/26 - Update: I've narrowed the issue down to the "Warning" filter.  When it is selected, the process never returns any results.  When I select "Notice", those results are returned within 10 seconds.

I also suspect this may nothing to do with the update and may have been present before.  I'm just noticing it now as I was checking things out after the upgrade.

Killing the process works and doesn't appear to have any negative impact.  Given it's just a log query, I wouldn't expect it to.