Messages

Thank you for your questions.

I am using an ARRIS (SB6190-RB) Cable Modem it comes preconfigured in bridge mode. There's no additional setup required. I plug it into the WAN port of my current OPNsense box and voila.

The TP-Link TL-SG108E is v5 and has the most current firmware installed. All settings are left at default with the exception of the 802.1Q VLAN Configuration and the 802.1Q VLAN PVID Setting. I've attached those settings and hopefully that will clear things up.

Thank you

Hi,

Another router on a stick setup question.

I am using Xfinity as my ISP.
I am using OPNsense 26.7

TL-SG108E configuration.

1️⃣ VLAN 10 (WAN/Modem Port)
VLAN ID: 10
Ports:Port 1 → Untagged
Port 5 → Tagged
Ports 2–4 → Not Member

2️⃣ VLAN 20 (LAN‑A, 192.x)
VLAN ID: 20
Ports:Port 2 → Untagged
Port 5 → Tagged
Ports 1, 3, 4 → Not Member

3️⃣ VLAN 30 (LAN‑B, 172.x)
VLAN ID: 30
Ports:Port 3 → Untagged
Port 5 → Tagged
Ports 1, 2, 4 → Not Member

4️⃣ VLAN 40 (LAN‑C, 10.x)
VLAN ID: 40
Ports:Port 4 → Untagged
Port 5 → Tagged
Ports 1–3 → Not Member

5️⃣ PVIDs (Port VLAN IDs)
(see attached)

The modem connects to port 1.
Port 5 connects to PC.

I can ping all subnets. I can access the GUI and SSH. WAN doesn't get an IP address assigned.
WAN is set up to use DHCP for both v4 and v6. All other settings are default.
Initially I left the MAC address blank.
Then I tried setting it to use the MAC address of the physical link, the address of the switch, and a randomly created MAC. I tried these with and without promiscuous mode enabled.
Rebooted the modem/OPNsense in between each setting change as well just for good measure.

No luck at all.

Maybe some wizard can shed some light on this.

Thanks!

---
Edit:
I've tried using the MAC address of my current OPNsense box, set VLAN priority to 6 and 7 respectively, but I am still having the same issue.

tcpdump -ni re0_vlan10 port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on re0_vlan10, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:29:15.088863 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:29:26.118714 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:29:48.321257 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:29:50.349083 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:29:55.381867 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:30:09.383068 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:30:29.402982 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:30:36.421088 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:30:48.423105 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:31:04.452439 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:31:05.516106 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:31:07.580611 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:31:12.586850 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:31:22.670109 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:31:33.703175 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:31:48.722855 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:32:11.326441 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:32:16.327227 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
16:32:25.352865 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:b7:85:1f:be:ad, length 300
^C
19 packets captured
141 packets received by filter
0 packets dropped by kernel

ZFS rules. The snapshot/rollback function alone. Accessible from the UI.

Damn, why didn't I know this. System > Snapshots
Alright, I will switch back.

Any thoughts on my original question though? I don't mind SMART giving me a warning whenever the short test runs, but why is my log being spammed like it did; or maybe it's being triggered by something else?

I would appreciate any insight you may have.

Thanks

But in post #1 you said you installed on UFS.

My first ZFS install, then the NVMe failed, then I did a fresh UFS install on a new NVMe. I've been using OPNsense for a few years now and always used UFS without any performance issues, but about a month ago I wanted to try out ZFS and added some more RAM and did a fresh install. Sorry for the confusion.

[...]
Has anyone experienced a comparable situation and how to address it?

No, my SSDs all have low P/E cycles - I didn't find any with spare usage. A few have >90000 Power On Hours (10 years). Even so, I'm paranoid about endurance, so I would consider any SSD with high spare usage unreliable for any application other than temporary storage.

1310 POH with 26TBW is a heck of a write rate.

I had Zenarmor installed. RAM usage was consistently around 14GB. I will need to read up on it some more before I reinstall it to avoid excessive writes and memory usage.

You have it on a decent fast UPS? ZFS is usually the choice filesystem for this fw application.

Maybe start here https://man.freebsd.org/cgi/man.cgi?smartd.conf%285%29

This was the first ZFS installation I ever did. I never had any performance issues in the past.

I previously had a ZFS install of OPNsense (mirrored, 1x 2.5 SATA and 1x NVMe m.2). I had the SMART plug installed and enabled to run short self-tests twice a week. One day the widget reported the NVMe drive failed, and I received failure notifications every second spamming the log.
The following is the health information:

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x04
Temperature:                        35 Celsius
Available Spare:                    100%
Available Spare Threshold:          1%
Percentage Used:                    104%
Data Units Read:                    2,314,455 [1.18 TB]
Data Units Written:                 52,182,266 [26.7 TB]
Host Read Commands:                 36,689,077
Host Write Commands:                486,151,530
Controller Busy Time:               7,726
Power Cycles:                       18
Power On Hours:                     1,310
Unsafe Shutdowns:                   15
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               35 Celsius
Temperature Sensor 2:               35 Celsius

When I researched the issue, I came across the following.

https://forum.proxmox.com/threads/how-to-get-rid-of-smart-reliability-notifications.130103/

Dear Client,
'Critical Warning: 0x04' is caused by "Percentage Used" being above 100%. In its own right, this only indicates that the drive is now out of warranty by the manufacturer. However, as long as 'Available Spare' is greater than 'Available Spare Threshold', you can safely ignore this.
Unfortunately, tools like smartctl will report the disk as failed, so you might need some custom filters for your monitoring.
This topic has been investigated and analyzed with our vendors for a very long time. Unfortunately, it is not possible to disable this warning for our use case. If you insist on it nonetheless, we can offer to replace the SSD for you as a gesture of goodwill.
Thank you very much for your understanding.

I have since replaced the NVMe with a new one and did a fresh installation of OPNsense on UFS. I would like to reuse my old NVMe again with OPNsense later, because there's nothing wrong with it.

My question:

I would like to keep using SMART, but I would like to a) avoid receiving SMART notification every second filling up the log and b) possibly not having SMART report the drive as failed to begin with.

Has anyone experienced a comparable situation and how to address it?

Thank you

Ah my bad, I included the wrong screenshot. The settings are correct because I also received an email.
Thank you for your feedback.

[Script:]

OPNsense 25.1.5_5-amd64
os-apcupsd (installed) 1.2_3

I am using monit to restart apcupsd when the process fails (pasted_image.png)

I would also like to receive an email alert upon status changes. I came across the following post.
https://forum.opnsense.org/index.php?topic=23071.0

(pasted_image002.png, pasted_image003.png)

Script:

Code Select Expand

#!/bin/sh

STATUS=$(/usr/local/sbin/apcaccess -p STATUS)
OK='ONLINE'
if [ "$STATUS" != $OK ]; then
echo "$STATUS"
exit 1
else
exit 0
fi
Email alert message content:

Status failed Service UPSStatusCheck

   Date:        Mon, 21 Apr 2025 13:00:54
   Action:      alert
   Host:        CPUUsage
   Description: status failed (1) -- ONLINE

Your faithful employee,
Monit

When I enable the service check I get the email (see above) reporting a failed status. Does anyone have a suggestion what I am doing wrong here?

Thank you

I previously had NUT set up as service mode netclient. It connected to my NUT master server simply fine and the diagnostics page on OPSsense pulled the correct configuration settings.
Now I want to change my service mode to standalone. I had uninstalled NUT from my master server. I changed my NUT settings on the OPNsense end. This should be straightforward based on examples I've googled, such as this

https://schnerring.net/blog/configure-nut-for-opnsense-and-truenas-with-the-cyberpower-pr750ert2u-ups/

Unfortunately, no matter how hard I've tried, I can't get it to work. My setup is as follows (see attached).

Yet, OPNsense is not able to establish a connection to the UPS and it pulls some old configuration that points to my defunct NUT master server. Also, the the diagnostics page on OPSsense is blank, which makes sense since it's not working correctly. This is what I get on the terminal.

Broadcast Message from root@opnsense                               
        (no tty) at 10:25 PDT...                                               
                                                                               
UPS cyberpower@192.x.x.x:3493 is unavailable

I have uninstalled the plug-in, rebooted, disconnected the UPS, and deleted the NUT folder at /usr/local/etc/nut several times.
After the lates plug-in reinstall (again) the settings still point to my defunct NUT master server.

/usr/local/etc/nut $ less upsmon.conf
# Please don't modify this file as your changes might be overwritten with
# the next update.
#
MONITOR cyberpower 1 monuser PWD master
SHUTDOWNCMD "/usr/local/etc/rc.halt"
POWERDOWNFLAG /etc/killpower
MONITOR cyberpower@192.x.x.x:3493 1 nutslave slave slave
SHUTDOWNCMD "/usr/local/etc/rc.halt"
POWERDOWNFLAG /etc/killpower

Where are these settings coming from? Why are they not being overwritten after I made my configuration changes?

Thank you

OPNsense 23.7.12_5-amd64

I have several interfaces but only WLAN WAN is selected in vnstat for usage reporting. It's consistently off by hundreds of GBs. My ISP enforces a data cap of ~1200GB, last month vnstat reported ~1790GB usage. I did not exceed my ISP's data cap.
Any suggestions? Thank you

I am attempting to export my ntopng configuration settings.

Web Gui
Settings > Configurations > Manage Configurations > Configurations
> select: Entire ntopng configuration (includes users, preferences, and all configurations below)
> select 'Export'

Browser download manager error (independent of browser type/version):
couldn't download - network issue

I've also noticed that no backups of configuration settings are being generated under
Settings > Configurations > Manage Configurations > Nightly Backups

Thank you

@rkubes
Thanks for this.
I did some more research and found the following at https://forum.opnsense.org/index.php?topic=21898.msg103540#msg103540

Solution:

Code Select Expand

tunefs -t disable /

I ran this command a week ago and the CAM and TRIM errors disappeared.
The SSD in question is a Lexar NQ100 which was the least expensive SSD I could find on Amazon at the time.

OPNsense 23.7.7_1-amd64
FreeBSD 13.2-RELEASE-p3
OpenSSL 1.1.1w 11 Sep 2023

I've just recently deployed a new instance of opnsense. SYSTEM: LOG FILES: GENERAL log shows the following errors:

Code Select Expand

2023-10-27T11:15:55-07:00 Notice kernel (ada0:ahcich0:0:0:0): DSM TRIM. ACB: 06 01 00 00 00 40 00 00 00 00 01 00
2023-10-27T11:10:17-07:00 Notice kernel (ada0:ahcich0:0:0:0): DSM TRIM. ACB: 06 01 00 00 00 40 00 00 00 00 01 00
2023-10-27T10:06:04-07:00 Notice kernel (ada0:ahcich0:0:0:0): DSM TRIM. ACB: 06 01 00 00 00 40 00 00 00 00 01 00

2023-10-27T11:15:55-07:00 Notice kernel (ada0:ahcich0:0:0:0): CAM status: Command timeout
2023-10-27T11:10:17-07:00 Notice kernel (ada0:ahcich0:0:0:0): CAM status: Command timeout
2023-10-27T10:06:04-07:00 Notice kernel (ada0:ahcich0:0:0:0): CAM status: Command timeout
2023-10-27T09:37:45-07:00 Notice kernel (ada0:ahcich0:0:0:0): CAM status: Command timeout

There are more entries, but for brevity I've just included a sample.
Some searches indicate that this could relate to a hardware problem (SSD drive, SATA cable, or like) or a FreeBSD bug.
My SSD is brand new and SMART reports no errors. BIOS is set to AHCI vs. SATA.
Does anyone have some initial impressions before I explore any other potential hardware issues?

Thank you

Thanks for clarifying, Franco. 👍