Recent posts

#1
General Discussion / Re: Issue with update from 26....
Last post by acpower1975 - Today at 03:53:34 AM
Hi,

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
#2
General Discussion / Re: Any plan to support 4G umb...
Last post by Maurice - Today at 03:26:48 AM
Official 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.
#3
General Discussion / Re: NUT is Broken After Udatin...
Last post by vk2him - November 14, 2026, 11:54:33 PM
Quote 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
#4
General Discussion / Re: NUT is Broken After Udatin...
Last post by anibis - November 14, 2026, 10:21:00 PM
Quote 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.
#5
Hardware and Performance / Re: N150 Mini PC, RTL8153, AX8...
Last post by dogshome - November 14, 2026, 10:05:15 PM
J4125 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.
#6
26.7, 26.10 Series / Re: Can anyone at OPNsense cre...
Last post by junkyjunky - November 14, 2026, 10:02:42 PM
I 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
#7
High availability / Re: HA with prefix delegation:...
Last post by ajr - November 14, 2026, 08:08:01 PM
After doing the setup (interfaces, DHCP6 and radvd) again from scratch,
tcp connections now work correctly.
In case of ping6 things get screwed up:

Incoming from WLAN shows global addresses:
oot@opn1:~ # tcpdump -nvi vlan03 icmp6
tcpdump: listening on vlan03, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:21:57.367066 IP6 (hlim 255, next-header ICMPv6 (58), payload length 32) fe80::184b:3cc0:64c8:616b > fe80::20d:b9ff:fe48:5c1e: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20d:b9ff:fe48:5c1e
  source link-address option (1), length 8 (1): 2a:1d:b8:a7:3c:71
16:21:57.367311 IP6 (hlim 255, next-header ICMPv6 (58), payload length 24) fe80::20d:b9ff:fe48:5c1e > fe80::184b:3cc0:64c8:616b: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::20d:b9ff:fe48:5c1e, Flags [router, solicited]

16:22:30.765033 IP6 (hlim 255, next-header ICMPv6 (58), payload length 24) fe80::20d:b9ff:fe48:5c1e > fe80::c72:8634:5d07:76c5: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::20d:b9ff:fe48:5c1e, Flags [router, solicited]
16:22:34.992643 IP6 (flowlabel 0xc0c00, hlim 64, next-header ICMPv6 (58), payload length 16) 2003:cb:170f:6f3:48cc:5883:5412:514f > 2a02:2e0:3fe:1001:302::: [icmp6 sum ok] ICMP6, echo request, id 19531, seq 0

Outgoing at WAN shows only local addresses:
root@opn1:~ # tcpdump -nvi igb1 icmp6
tcpdump: listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:11:59.122356 IP6 (hlim 64, next-header ICMPv6 (58), payload length 9) fe80::20d:b9ff:fe48:5c1d > fe80::cece:1eff:feb3:757f: [icmp6 sum ok] ICMP6, echo request, id 44961, seq 15220
16:11:59.122714 IP6 (hlim 64, next-header ICMPv6 (58), payload length 9) fe80::cece:1eff:feb3:757f > fe80::20d:b9ff:fe48:5c1d: [icmp6 sum ok] ICMP6, echo reply, id 44961, seq 15220

A group rule exists to allow icmp v6 for all nets.
#8
26.7, 26.10 Series / Re: Static-port outbound NAT d...
Last post by anomaly0617 - November 14, 2026, 07:25:08 PM
No, the AI anonymized/redacted information before providing the final report. The internal network is RFC1918, the external network is appropriately set static with a valid static IP, and some traffic makes it through, just not all of it. This is most frustrating because it means "sometimes" outbound calling works, and sometimes it does not. I could tell the SIP provider to accept both the default outbound IP and the one designated for VoIP, but that doesn't really resolve the underlying issue.

I've been testing on this for a few days now to make sure it's not something internal or external to the firewall, but the config prior to upgrading to 26.7 was stable for years. So this is something new in the 26.x line, it's just a question of whether it's an OPNsense problem, a PF problem, or a FreeBSD problem.
#9
26.7, 26.10 Series / Re: tailscale interface down (...
Last post by Bossybear - November 14, 2026, 06:56:02 PM
I installed tailscale on another machine on my LAN and it works fine.
I've deleted tailscale from OPNSense. :(
#10
26.7, 26.10 Series / tailscale interface down (red ...
Last post by Bossybear - November 14, 2026, 06:08:15 PM
OPNsense v26.7.9_1-amd64
I installed the os-tailscale plugin (v1.104.5) and followed the usual and customary setup instructions.
My firewall is listed as authorized in the devices list on the tailscale web ui.
Tailscale status says it is running, it has an IP address assigned.

When I go to the Interfaces to assign the tailscale interface to a local (opt4) the network status is red (offline)

No matter what I do from here on out, this interface never goes online.

What am I doing wrong?