"Recent posts
#1
Hardware and Performance / Re: N150 Mini PC, RTL8153, AX8...
Last post by nero355 - Today at 04:14:16 PMQuote from: dogshome on November 14, 2026, 10:05:15 PMThe passive heatink consists of a 3mm 80x80 copper sheet, topped with an 80x80x27mm plain aluminium heatsink. The large lump of copper negates the need for a fan, yes, I tested it. If I could have found a copper pin heatsink at a reasonable price, that would be fitted.Shop around on the used market for weird models from the past like these :
- https://noai.duckduckgo.com/?q=Zalman+CNPS6000-Cu&ia=images&iax=images
- https://noai.duckduckgo.com/?q=Swiftech+MC462&ia=images&iax=images
And many more! :)
Another option is to have a look at 1U Coolers pulled from Servers and put on eBay for example.
In case you want something brand new I think your best bet are the Low Profile Coolers from Scythe and Thermalright that usually have at least 4 heatpipers going through them.
Good luck with the hunt! ;)
#2
General Discussion / Re: Issue with update from 26....
Last post by acpower1975 - Today at 12:54:33 PMHi,
After running both the health and connectivity checks, I tried another round of updates, and it completed successfully.
Now it is running properly again.
The issue is closed now.
Thanks.
Regards
Andy
After running both the health and connectivity checks, I tried another round of updates, and it completed successfully.
Now it is running properly again.
The issue is closed now.
Thanks.
Regards
Andy
#3
General Discussion / Re: Any plan to support 4G umb...
Last post by Lucid1010 - Today at 11:08:04 AMI was trying to configure a cellular backup with a Quectel 5G modem, and FreeBSD's hardware support continues to fall short.
Requiring 8-year-old code for a 5G module?
Much better off using Linux or OpenWrt for this kind of setup.
Requiring 8-year-old code for a 5G module?
Much better off using Linux or OpenWrt for this kind of setup.
#4
Virtual private networks / [Solved] WireGuard clients had...
Last post by willwilliam - Today at 10:43:38 AMoutbound NAT misses 10.0.0.0/24 when assigned wg interface has no IPv4 config
Hi everyone,
I just spent a few hours troubleshooting a subtle issue with the WireGuard plugin, and since the fix was not documented anywhere I could find, here is a full write-up. Hopefully it saves someone else the debugging time.
Setup
Proxmox host behind an ISP box (double NAT). OPNsense runs as a VM on the Proxmox host and serves several VLANs (LAN, Wi-Fi, cameras...). The WireGuard plugin (os-wireguard) terminates a full-tunnel VPN for road-warrior clients, subnet 10.0.0.0/24 , outbound NAT in hybrid mode.
Symptom
WireGuard tunnel works fine for reaching the LAN: clients connect, they can reach hosts behind OPNsense (Home Assistant, Proxmox, etc.). But with a full-tunnel client ( 0.0.0.0/0 ), IPv4 internet through the tunnel silently fails — while some websites appear to work.
On my Linux client:
The confusing part: Google, Amazon and other big sites loaded fine — because my ISP line has IPv6, and WireGuard's 0.0.0.0/0 only captures IPv4. IPv6 traffic bypassed the tunnel entirely, making half the internet look healthy. Any IPv4-only site failed.
DNS was fine, and OPNsense itself could ping 8.8.8.8, so the WAN path was healthy.
Diagnosis
The live firewall log showed the smoking gun: packets from the WireGuard client were leaving the WAN interface with their original source address, never NATed:
WAN out TCP 10.0.0.2:59398 -> 54.171.207.179:443 pass (let out anything from
firewall host itself)
WAN out UDP 10.0.0.2:33065 -> 141.101.90.106:443 pass
The ISP box in front of OPNsense obviously can't route replies back to 10.0.0.2, so every connection times out.
Root cause
The WireGuard interface is assigned (Interfaces → Assignments, device wg0 ), but its IPv4 configuration type
is "none" — which is normal with the os-wireguard plugin, since the plugin itself manages the address on
wg0 .
However, automatic outbound NAT builds its "local networks" list from the addresses configured on assigned interfaces. With IPv4 set to "none", the WireGuard subnet ( 10.0.0.0/24 in my case) never makes it into the automatic outbound NAT rules — so client traffic egressing WAN is never translated.
You can confirm by looking at Firewall → NAT → Outbound (hybrid/automatic mode): the auto rule sources list "LAN networks, VPN networks, ..." but the VPN interface contributes nothing since it has no configured address.
Fix
Add a manual outbound NAT rule (Firewall → NAT → Outbound → Add):
Apply, reconnect the client, done:
Suggestion
It would be great if the os-wireguard plugin (or the outbound NAT page) could warn the user when an assigned wg interface has no IPv4 configuration, hinting that automatic outbound NAT will not cover its subnet. Maybe a docs note would be enough. Happy to file this on GitHub if it's the right place
Hi everyone,
I just spent a few hours troubleshooting a subtle issue with the WireGuard plugin, and since the fix was not documented anywhere I could find, here is a full write-up. Hopefully it saves someone else the debugging time.
Setup
Proxmox host behind an ISP box (double NAT). OPNsense runs as a VM on the Proxmox host and serves several VLANs (LAN, Wi-Fi, cameras...). The WireGuard plugin (os-wireguard) terminates a full-tunnel VPN for road-warrior clients, subnet 10.0.0.0/24 , outbound NAT in hybrid mode.
Symptom
WireGuard tunnel works fine for reaching the LAN: clients connect, they can reach hosts behind OPNsense (Home Assistant, Proxmox, etc.). But with a full-tunnel client ( 0.0.0.0/0 ), IPv4 internet through the tunnel silently fails — while some websites appear to work.
On my Linux client:
Code Select
$ curl -4 -v --connect-timeout 10 https://www.google.com
* Trying 142.251.157.119:443...
* Connection timed out after 10001 millisecondsThe confusing part: Google, Amazon and other big sites loaded fine — because my ISP line has IPv6, and WireGuard's 0.0.0.0/0 only captures IPv4. IPv6 traffic bypassed the tunnel entirely, making half the internet look healthy. Any IPv4-only site failed.
DNS was fine, and OPNsense itself could ping 8.8.8.8, so the WAN path was healthy.
Diagnosis
The live firewall log showed the smoking gun: packets from the WireGuard client were leaving the WAN interface with their original source address, never NATed:
WAN out TCP 10.0.0.2:59398 -> 54.171.207.179:443 pass (let out anything from
firewall host itself)
WAN out UDP 10.0.0.2:33065 -> 141.101.90.106:443 pass
The ISP box in front of OPNsense obviously can't route replies back to 10.0.0.2, so every connection times out.
Root cause
The WireGuard interface is assigned (Interfaces → Assignments, device wg0 ), but its IPv4 configuration type
is "none" — which is normal with the os-wireguard plugin, since the plugin itself manages the address on
wg0 .
However, automatic outbound NAT builds its "local networks" list from the addresses configured on assigned interfaces. With IPv4 set to "none", the WireGuard subnet ( 10.0.0.0/24 in my case) never makes it into the automatic outbound NAT rules — so client traffic egressing WAN is never translated.
You can confirm by looking at Firewall → NAT → Outbound (hybrid/automatic mode): the auto rule sources list "LAN networks, VPN networks, ..." but the VPN interface contributes nothing since it has no configured address.
Fix
Add a manual outbound NAT rule (Firewall → NAT → Outbound → Add):
| Setting Value Interface WAN Protocol any Source 10.0.0.0/24 (or your WireGuard alias) Source port * Destination * Destination port * Translation address Interface address |
Apply, reconnect the client, done:
Code Select
$ curl -4 -sI https://www.google.com
HTTP/2 200Note: I deliberately did not set a static IPv4 on the assigned wg interface, since the plugin already manages the address on wg0 and I did not want to risk a duplicate address.Suggestion
It would be great if the os-wireguard plugin (or the outbound NAT page) could warn the user when an assigned wg interface has no IPv4 configuration, hinting that automatic outbound NAT will not cover its subnet. Maybe a docs note would be enough. Happy to file this on GitHub if it's the right place
#5
General Discussion / Re: Issue with update from 26....
Last post by acpower1975 - Today at 03:53:34 AMHi,
Below is the audit results.
***GOT REQUEST TO AUDIT CONNECTIVITY***
Currently running OPNsense 26.7.8_2 (amd64) at Sun Nov 15 10:43:02 +08 2026
Current repository configuration:
/usr/local/etc/pkg/repos/FreeBSD.conf:
FreeBSD-base: { enabled: no }
FreeBSD-ports: { enabled: no }
FreeBSD-ports-kmods: { enabled: no }
/usr/local/etc/pkg/repos/OPNsense-aux.conf:
OPNsense-aux: {
fingerprints: "/usr/local/etc/pkg/fingerprints/OPNsense",
url: "https://pkg.opnsense.org/${ABI}/26.7/aux",
signature_type: "fingerprints",
priority: 11,
enabled: no
}
/usr/local/etc/pkg/repos/OPNsense.conf:
OPNsense: {
fingerprints: "/usr/local/etc/pkg/fingerprints/OPNsense",
url: "https://pkg.opnsense.org/${ABI}/26.7/latest",
signature_type: "fingerprints",
priority: 11,
enabled: yes
}
/usr/local/etc/pkg/repos/SunnyValley.conf:
SunnyValley: {
fingerprints: "/usr/local/etc/pkg/fingerprints/SunnyValley",
url: "https://updates.zenarmor.net/opnsense/${ABI}/26.7/bee49e10-0c3c-4e85-a980-8336d2652c3c",
signature_type: "fingerprints",
priority: 7,
enabled: yes
}
Checking connectivity for host: pkg.opnsense.org -> 89.149.222.99
PING 89.149.222.99 (89.149.222.99): 128 data bytes
136 bytes from 89.149.222.99: icmp_seq=0 ttl=52 time=163.801 ms
136 bytes from 89.149.222.99: icmp_seq=1 ttl=52 time=163.852 ms
--- 89.149.222.99 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 163.801/163.827/163.852/0.025 ms
Checking fragmentation for host: pkg.opnsense.org -> 89.149.222.99
PING 89.149.222.99 (89.149.222.99): 1500 data bytes
1508 bytes from 89.149.222.99: icmp_seq=0 ttl=52 time=164.136 ms
1508 bytes from 89.149.222.99: icmp_seq=1 ttl=52 time=164.138 ms
--- 89.149.222.99 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 164.136/164.137/164.138/0.001 ms
Checking connectivity for repository (IPv4): https://pkg.opnsense.org/FreeBSD:15:amd64/26.7
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data: .......... done
Processing entries: .......... done
OPNsense repository update completed. 933 packages processed.
Updating SunnyValley repository catalogue...
Fetching meta.conf: . done
Fetching data: .. done
Processing entries: .. done
SunnyValley repository update completed. 14 packages processed.
All repositories are up to date.
Checking connectivity for host: pkg.opnsense.org -> 2001:1af8:5300:a010:1::1
ping: UDP connect: No route to host
Checking connectivity for repository (IPv6): https://pkg.opnsense.org/FreeBSD:15:amd64/26.7
Updating OPNsense repository catalogue...
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/meta.txz: Non-recoverable resolver failure
repository OPNsense has no meta file, using default settings
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/data.pkg: Non-recoverable resolver failure
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/data.tzst: Non-recoverable resolver failure
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/packagesite.pkg: Non-recoverable resolver failure
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/packagesite.tzst: Non-recoverable resolver failure
Unable to update repository OPNsense
Updating SunnyValley repository catalogue...
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/meta.txz: Non-recoverable resolver failure
repository SunnyValley has no meta file, using default settings
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/data.pkg: Non-recoverable resolver failure
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/data.tzst: Non-recoverable resolver failure
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/packagesite.pkg: Non-recoverable resolver failure
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/packagesite.tzst: Non-recoverable resolver failure
Unable to update repository SunnyValley
Error updating repositories!
Checking server certificate for host: pkg.opnsense.org
Connecting to 89.149.222.99
depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
verify return:1
depth=1 C=AT, O=ZeroSSL, CN=ZeroSSL RSA Domain Secure Site CA
verify return:1
depth=0 CN=pkg.opnsense.org
verify return:1
DONE
Checking server certificate for host: updates.zenarmor.net
Connecting to 172.67.74.209
depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R4
verify return:1
depth=1 C=US, O=Google Trust Services, CN=WE1
verify return:1
depth=0 CN=zenarmor.net
verify return:1
DONE
***DONE***
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.7.8_2 (amd64) at Sun Nov 15 10:48:05 +08 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.7.8 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.7.8 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
SunnyValley (Priority: 7)
OPNsense (Priority: 11)
>>> Check installed plugins
os-crowdsec 1.0.12
os-isc-dhcp 1.0_7
os-sensei 2.7.2
os-sensei-updater 2.0
os-sunnyvalley 1.5_2
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.7.8_2 has 69 dependencies to check.
Checking packages: .......................
openssh-portable-10.6.p1,1 version mismatch, expected 10.6.p2,1
Checking packages: .
openvpn-2.7.8 version mismatch, expected 2.7.9
Checking packages: .
opnsense-26.7.8_2 version mismatch, expected 26.7.9_1
Checking packages: ..
opnsense-lang-26.1.7 version mismatch, expected 26.7.9
Checking packages: .
opnsense-update-26.7.8 version mismatch, expected 26.7.9
Checking packages: ..............
php85-phpseclib-3.0.57 version mismatch, expected 3.0.58
Checking packages: .........
py313-dnspython-2.9.0,1 version mismatch, expected 2.9.2,1
Checking packages: .......
py313-sqlite3-3.13.16_10 version mismatch, expected 3.13.18_10
Checking packages: .......
sudo-1.9.17p2_2 version mismatch, expected 1.9.17p2_4
Checking packages: ..... done
***DONE***
Thanks.
Regards
Andy
Below is the audit results.
***GOT REQUEST TO AUDIT CONNECTIVITY***
Currently running OPNsense 26.7.8_2 (amd64) at Sun Nov 15 10:43:02 +08 2026
Current repository configuration:
/usr/local/etc/pkg/repos/FreeBSD.conf:
FreeBSD-base: { enabled: no }
FreeBSD-ports: { enabled: no }
FreeBSD-ports-kmods: { enabled: no }
/usr/local/etc/pkg/repos/OPNsense-aux.conf:
OPNsense-aux: {
fingerprints: "/usr/local/etc/pkg/fingerprints/OPNsense",
url: "https://pkg.opnsense.org/${ABI}/26.7/aux",
signature_type: "fingerprints",
priority: 11,
enabled: no
}
/usr/local/etc/pkg/repos/OPNsense.conf:
OPNsense: {
fingerprints: "/usr/local/etc/pkg/fingerprints/OPNsense",
url: "https://pkg.opnsense.org/${ABI}/26.7/latest",
signature_type: "fingerprints",
priority: 11,
enabled: yes
}
/usr/local/etc/pkg/repos/SunnyValley.conf:
SunnyValley: {
fingerprints: "/usr/local/etc/pkg/fingerprints/SunnyValley",
url: "https://updates.zenarmor.net/opnsense/${ABI}/26.7/bee49e10-0c3c-4e85-a980-8336d2652c3c",
signature_type: "fingerprints",
priority: 7,
enabled: yes
}
Checking connectivity for host: pkg.opnsense.org -> 89.149.222.99
PING 89.149.222.99 (89.149.222.99): 128 data bytes
136 bytes from 89.149.222.99: icmp_seq=0 ttl=52 time=163.801 ms
136 bytes from 89.149.222.99: icmp_seq=1 ttl=52 time=163.852 ms
--- 89.149.222.99 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 163.801/163.827/163.852/0.025 ms
Checking fragmentation for host: pkg.opnsense.org -> 89.149.222.99
PING 89.149.222.99 (89.149.222.99): 1500 data bytes
1508 bytes from 89.149.222.99: icmp_seq=0 ttl=52 time=164.136 ms
1508 bytes from 89.149.222.99: icmp_seq=1 ttl=52 time=164.138 ms
--- 89.149.222.99 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 164.136/164.137/164.138/0.001 ms
Checking connectivity for repository (IPv4): https://pkg.opnsense.org/FreeBSD:15:amd64/26.7
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data: .......... done
Processing entries: .......... done
OPNsense repository update completed. 933 packages processed.
Updating SunnyValley repository catalogue...
Fetching meta.conf: . done
Fetching data: .. done
Processing entries: .. done
SunnyValley repository update completed. 14 packages processed.
All repositories are up to date.
Checking connectivity for host: pkg.opnsense.org -> 2001:1af8:5300:a010:1::1
ping: UDP connect: No route to host
Checking connectivity for repository (IPv6): https://pkg.opnsense.org/FreeBSD:15:amd64/26.7
Updating OPNsense repository catalogue...
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/meta.txz: Non-recoverable resolver failure
repository OPNsense has no meta file, using default settings
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/data.pkg: Non-recoverable resolver failure
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/data.tzst: Non-recoverable resolver failure
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/packagesite.pkg: Non-recoverable resolver failure
pkg: https://pkg.opnsense.org/FreeBSD:15:amd64/26.7/latest/packagesite.tzst: Non-recoverable resolver failure
Unable to update repository OPNsense
Updating SunnyValley repository catalogue...
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/meta.txz: Non-recoverable resolver failure
repository SunnyValley has no meta file, using default settings
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/data.pkg: Non-recoverable resolver failure
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/data.tzst: Non-recoverable resolver failure
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/packagesite.pkg: Non-recoverable resolver failure
pkg: https://updates.zenarmor.net/opnsense/FreeBSD:15:amd64/26.7/${SUBSCRIPTION}/packagesite.tzst: Non-recoverable resolver failure
Unable to update repository SunnyValley
Error updating repositories!
Checking server certificate for host: pkg.opnsense.org
Connecting to 89.149.222.99
depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
verify return:1
depth=1 C=AT, O=ZeroSSL, CN=ZeroSSL RSA Domain Secure Site CA
verify return:1
depth=0 CN=pkg.opnsense.org
verify return:1
DONE
Checking server certificate for host: updates.zenarmor.net
Connecting to 172.67.74.209
depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R4
verify return:1
depth=1 C=US, O=Google Trust Services, CN=WE1
verify return:1
depth=0 CN=zenarmor.net
verify return:1
DONE
***DONE***
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.7.8_2 (amd64) at Sun Nov 15 10:48:05 +08 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.7.8 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.7.8 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
SunnyValley (Priority: 7)
OPNsense (Priority: 11)
>>> Check installed plugins
os-crowdsec 1.0.12
os-isc-dhcp 1.0_7
os-sensei 2.7.2
os-sensei-updater 2.0
os-sunnyvalley 1.5_2
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.7.8_2 has 69 dependencies to check.
Checking packages: .......................
openssh-portable-10.6.p1,1 version mismatch, expected 10.6.p2,1
Checking packages: .
openvpn-2.7.8 version mismatch, expected 2.7.9
Checking packages: .
opnsense-26.7.8_2 version mismatch, expected 26.7.9_1
Checking packages: ..
opnsense-lang-26.1.7 version mismatch, expected 26.7.9
Checking packages: .
opnsense-update-26.7.8 version mismatch, expected 26.7.9
Checking packages: ..............
php85-phpseclib-3.0.57 version mismatch, expected 3.0.58
Checking packages: .........
py313-dnspython-2.9.0,1 version mismatch, expected 2.9.2,1
Checking packages: .......
py313-sqlite3-3.13.16_10 version mismatch, expected 3.13.18_10
Checking packages: .......
sudo-1.9.17p2_2 version mismatch, expected 1.9.17p2_4
Checking packages: ..... done
***DONE***
Thanks.
Regards
Andy
#6
General Discussion / Re: Any plan to support 4G umb...
Last post by Maurice - Today at 03:26:48 AMOfficial MBIM support in OPNsense would be great, but I'm not sure the umb driver in its current state would be suitable.
umb(4) was originally developed for OpenBSD in 2016 and ported to NetBSD in 2018. The NetBSD port was then ported to FreeBSD for a commercial closed source project (a plugin for OPNsense 19.7, funnily enough). This code was then open sourced in 2022, which is how it finally made it into FreeBSD 15.0.
While the original OpenBSD code is actively maintained, the FreeBSD port is essentially a snapshot from 2018. None of the improvements the OpenBSD driver received over the last 8 years - like support for additional modems and IPv6 - made it into FreeBSD.
Unless someone picks up the FreeBSD port and brings it into this decade, I'm not sure adding it to OPNsense would be worth the effort.
Just my interpretation of the status quo, not a complaint.
Cheers
Maurice
Source: About a year ago, I did a bit of testing with umb on all three BSDs, accompanied by some digging in commit histories and bug trackers.
umb(4) was originally developed for OpenBSD in 2016 and ported to NetBSD in 2018. The NetBSD port was then ported to FreeBSD for a commercial closed source project (a plugin for OPNsense 19.7, funnily enough). This code was then open sourced in 2022, which is how it finally made it into FreeBSD 15.0.
While the original OpenBSD code is actively maintained, the FreeBSD port is essentially a snapshot from 2018. None of the improvements the OpenBSD driver received over the last 8 years - like support for additional modems and IPv6 - made it into FreeBSD.
Unless someone picks up the FreeBSD port and brings it into this decade, I'm not sure adding it to OPNsense would be worth the effort.
Just my interpretation of the status quo, not a complaint.
Cheers
Maurice
Source: About a year ago, I did a bit of testing with umb on all three BSDs, accompanied by some digging in commit histories and bug trackers.
#7
General Discussion / Re: NUT is Broken After Udatin...
Last post by vk2him - November 14, 2026, 11:54:33 PMQuote from: anibis on November 14, 2026, 10:21:00 PMbut I still have the same NUT is not running error
If I see that not running error, it's usually due to a "known" issue with the initial handshake by my UPS via USB (CyberPower) and the USB driver in any device it tries to connect to. It happens when connecting to all hosts so it's not an Opnsense issue for me - the UPS constantly connects and disconnects before the driver on the host is ready, and that can lead to the UPS not connecting as it timesout. My fix in this situation is to disconnect the USB lead to the UPS, wait a few seconds, then reconnect - 99/100 that fixes it for me. Your issue may be different though
#8
General Discussion / Re: NUT is Broken After Udatin...
Last post by anibis - November 14, 2026, 10:21:00 PMQuote from: DavidGA on August 30, 2026, 11:53:24 PMI previously used to revert nut, which after upgrading to 26.7 is no longer possible. Nut seems to be working in the background (although it is difficult to tell) but the dashboard widget says "Nut is not returning a status. Click to reconfigure Nut." and the diagnostics page is blank.
Is this still broken for you? NUT is working fine for me as I can pull data into HA, but I still have the same NUT is not running error.
#9
Hardware and Performance / Re: N150 Mini PC, RTL8153, AX8...
Last post by dogshome - November 14, 2026, 10:05:15 PMJ4125 with 2.5GB Intel ports is back in play. The passive heatink consists of a 3mm 80x80 copper sheet, topped with an 80x80x27mm plain aluminium heatsink. The large lump of copper negates the need for a fan, yes, I tested it. If I could have found a copper pin heatsink at a reasonable price, that would be fitted.
#10
26.7, 26.10 Series / Re: Can anyone at OPNsense cre...
Last post by junkyjunky - November 14, 2026, 10:02:42 PMI know this is old, but for others who run into this and need help I found this YouTube video very helpful. Got it setup in one go.
https://youtu.be/5baIK2nIkvA?si=WoG7DyauBM6DQkT5
https://youtu.be/5baIK2nIkvA?si=WoG7DyauBM6DQkT5
