"Recent posts
#1
26.1, 26,4 Series / CLOSED: Previously working os-...
Last post by mrzaz - Today at 11:00:23 PMHello,
I have managed to figure out what the culprit was for this problem.
Explanation:
When I enabled tailscale client on the server the PowerShute is running, in the tcpdump traces
from opnsense shows that it only sends but never receives on LAN net.
From tcpdump in opnsense could see this behaviour.
But when I disable the tailscale app in .4 server then all comes through OK.
I even saw this when testing with net-snmp snmpwalker. (packets leaving but no response on LAN .20 from 192.168.x.4.
Client however handled it because I got output)
I suspect that the server gets the the command from LAN 192.168.x.20 but
then (because tailscale is also enabled in opnsense) it sends
the response back on the tailscale interface.
Synology (which also has tailscale) seems to handle it.
Net-SNMP plugin in opnsense seems to handle it.
apcupsd in opnsense, NOT so much. :-/
Not sure when in time they swapped from net-snmp in apcupsd to other snmp client ?
So in the past it is most likely working because 1 - I hadn't enabled tailscale on server yet.
OR 2. they changed from net-snmp to other and then it broke.
Seems like Net-SNMP handles it better though.
Net-SNMP tailscale on in server (also look similar with apcupsd with only outgoing on LAN net.)
Net-SNMP tailscale off in server
I will test a bit with some settings in server tailscale client.
But now I have found the main reason at least.
Interesting is that Net-SNMP for sure handles it even if the response came back on tailscale interface. (as seen further up)
I tested to use the tailscale IP to the server instead of the LAN net and then it works with apcupsd with tailscale enabled in server. 😊
Best regards
Dan Lundqvist
Stockholm, Sweden
I have managed to figure out what the culprit was for this problem.
Explanation:
When I enabled tailscale client on the server the PowerShute is running, in the tcpdump traces
from opnsense shows that it only sends but never receives on LAN net.
From tcpdump in opnsense could see this behaviour.
But when I disable the tailscale app in .4 server then all comes through OK.
I even saw this when testing with net-snmp snmpwalker. (packets leaving but no response on LAN .20 from 192.168.x.4.
Client however handled it because I got output)
Code Select
root@OPNsense:~ # snmpwalk -v1 -c private 192.168.x.4 .1.3.6.1.2.1.1
SNMPv2-MIB::sysDescr.0 = STRING: PowerChute Business Edition
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.318.1.3.33.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (60296) 0:10:02.96
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: PowerChute UPS
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 10
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00I suspect that the server gets the the command from LAN 192.168.x.20 but
then (because tailscale is also enabled in opnsense) it sends
the response back on the tailscale interface.
Synology (which also has tailscale) seems to handle it.
Net-SNMP plugin in opnsense seems to handle it.
apcupsd in opnsense, NOT so much. :-/
Not sure when in time they swapped from net-snmp in apcupsd to other snmp client ?
So in the past it is most likely working because 1 - I hadn't enabled tailscale on server yet.
OR 2. they changed from net-snmp to other and then it broke.
Seems like Net-SNMP handles it better though.
Net-SNMP tailscale on in server (also look similar with apcupsd with only outgoing on LAN net.)
Code Select
root@OPNsense:~ # tcpdump -i em1 host 192.168.x.4 and udp port 161
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on em1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:59:54.947059 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(26) system
21:59:54.948212 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysDescr.0
21:59:54.948706 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysObjectID.0
21:59:54.949247 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysUpTime.0
21:59:54.949683 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysContact.0
21:59:54.950191 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysName.0
21:59:54.950629 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysLocation.0
21:59:54.951030 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysServices.0
21:59:54.951481 IP OPNsense.57487 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.8.0
Net-SNMP tailscale off in server
Code Select
root@OPNsense:~ # tcpdump -i em1 host 192.168.x.4 and udp port 161
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on em1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:01:08.907568 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(26) system
22:01:08.908316 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(55) system.sysDescr.0="PowerChute Business Edition"
22:01:08.908388 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysDescr.0
22:01:08.908763 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(39) system.sysObjectID.0=E:318.1.3.33.1
22:01:08.908788 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysObjectID.0
22:01:08.909213 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(31) system.sysUpTime.0=60296
22:01:08.909235 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysUpTime.0
22:01:08.909562 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(28) system.sysContact.0=""
22:01:08.909580 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysContact.0
22:01:08.909861 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(42) system.sysName.0="PowerChute UPS"
22:01:08.909879 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysName.0
22:01:08.910161 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(28) system.sysLocation.0=""
22:01:08.910177 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysLocation.0
22:01:08.910461 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(29) system.sysServices.0=10
22:01:08.910479 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.sysServices.0
22:01:08.910810 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(29) system.8.0=0
22:01:08.910827 IP OPNsense.50746 > 192.168.x.4.snmp: C="private" GetNextRequest(28) system.8.0
22:01:08.911209 IP 192.168.x.4.snmp > OPNsense.50746: C="private" GetResponse(30) snmp.snmpInPkts.0=499
I will test a bit with some settings in server tailscale client.
But now I have found the main reason at least.
Interesting is that Net-SNMP for sure handles it even if the response came back on tailscale interface. (as seen further up)
I tested to use the tailscale IP to the server instead of the LAN net and then it works with apcupsd with tailscale enabled in server. 😊
Best regards
Dan Lundqvist
Stockholm, Sweden
#2
26.7 Series / Re: os-upnp plugin not working...
Last post by bamf - Today at 10:52:31 PMQuote from: Warbreaker on July 20, 2026, 08:00:36 PMI finally got it working.
I added this "Source NAT" rule:
https://www.pasteboard.co/lTHlqpZ_SWPY.png
Is this rule required now for getting UPnP IGD & PCP back to work? Why? I am facing the same issue. Active mappings with IP address ?.
#3
26.7 Series / Re: 26.7.1: Network(s) alias u...
Last post by pfry - Today at 10:48:47 PMSimilar issue: Firewall rules and aliases.
Likely inconvenient on a running firewall, but: I'd check "Firewall: Diagnostics: Aliases" to make sure the member elements appear as you expect. Also, check the "Statistics" box in the alias definitions to look for rule matches (pass rules only). I'd also look at "Firewall: Diagnostics: Statistics" -> "rules" to make sure the rules are defined as you would expect.
Could be a bad rule expansion - the diagnostic view may be enlightening.
Likely inconvenient on a running firewall, but: I'd check "Firewall: Diagnostics: Aliases" to make sure the member elements appear as you expect. Also, check the "Statistics" box in the alias definitions to look for rule matches (pass rules only). I'd also look at "Firewall: Diagnostics: Statistics" -> "rules" to make sure the rules are defined as you would expect.
Could be a bad rule expansion - the diagnostic view may be enlightening.
#4
26.1, 26,4 Series / Re: IPv6 breaks after a while ...
Last post by meyergru - Today at 10:25:12 PMThe /128 on the WAN must be the IA_NA IPv6. But if you use a /56 prefix, there must be the least significant 8 bits that are used for any other interface - I understand the prefixes 0, 1 and 2 for your internal interfaces. But what is the /64 on the WAN made up from?
Let's leave out the fe80::/64, because those are link-local and of no special interest apart from that the WAN uses a link-local gateway as well.
I wonder what the /64 GUA on the WAN is? What is the 8-bit prefix of that? Are the first 56 bits shared with the IA_PD from your LAN interfaces?
And now I see: You are using OpnSense virtualized under some kind of KVM (i.e. TrueNAS Scale). That complicates things A LOT.
What do I mean by this? See: https://forum.opnsense.org/index.php?topic=44159.0, especially the part about "bridge-mcsnoop 0", which could well explain what you are seeing, because the known bug manifests in IPv6 connectivity breaking after a short while.
That being said, I have no experience with TrueNAS Scale at all.
Let's leave out the fe80::/64, because those are link-local and of no special interest apart from that the WAN uses a link-local gateway as well.
I wonder what the /64 GUA on the WAN is? What is the 8-bit prefix of that? Are the first 56 bits shared with the IA_PD from your LAN interfaces?
And now I see: You are using OpnSense virtualized under some kind of KVM (i.e. TrueNAS Scale). That complicates things A LOT.
What do I mean by this? See: https://forum.opnsense.org/index.php?topic=44159.0, especially the part about "bridge-mcsnoop 0", which could well explain what you are seeing, because the known bug manifests in IPv6 connectivity breaking after a short while.
That being said, I have no experience with TrueNAS Scale at all.
#5
General Discussion / Re: apc ups commlost
Last post by Lucid1010 - Today at 10:20:36 PMapcupsd and NUT work together without any issues. I use apcupsd alongside NUT because it provides features such as automatic shutdown of the OPNsense host and configurable battery thresholds.
Since the NUT configuration in OPNsense doesn't work properly, I'm using apcupsd alongside it.
nut.conf, upsd.conf, ups.conf ...etc configure not working
Since the NUT configuration in OPNsense doesn't work properly, I'm using apcupsd alongside it.
nut.conf, upsd.conf, ups.conf ...etc configure not working
Quote from: Patrick M. Hausen on Today at 03:51:49 PMQuote from: lmoore on Today at 03:47:17 PMNUT includes the driver APCUPSD-Driver and it may tempt some users to use it.
From the thread I got the impression they were trying to install and run the standalone apcupsd alongside NUT which probably won't work.
There is an os-apcupsd plugin. Don't run that if you intend to run NUT and vice versa.
#6
26.7 Series / Re: Services widget
Last post by AhnHEL - Today at 10:05:08 PMI didnt think of this, awesome recommendation, thank you.
Quote from: Mabub on Today at 09:05:22 AM@Franco: Thanks for the effort that went into the new design, but I have to admit that I'm not a fan of it in its current form. It feels quite different from the overall look and feel of the interface, service names are now truncated, and the descriptions are no longer visible.
Personally, I find the previous design more practical and easier to read. Hopefully, this change can either be reconsidered, refined, or at least offered as an optional alternative rather than becoming the default for all widgets.
No offense intended—this is simply my personal feedback as a user. I appreciate the work that goes into OPNsense, but for me, this particular change does not feel like an improvement.
Back to the Roots...
Couldn't find any errors, but as always, use at your own risk!
For those who don't want that, here is the good view:
1. Login SSH
2. Press 8 for Shell
3. sudo nano /usr/local/opnsense/www/js/widgets/Services.js
4. Copy Contents in Services.js
https://github.com/opnsense/core/blob/stable/26.1/src/opnsense/www/js/widgets/Services.js
5. Reboot
#7
26.7 Series / Re: Significantly lower CPU te...
Last post by Nullman - Today at 09:59:51 PMQuote from: gspannu on Today at 09:24:58 PMWhat is your WAN connection type? PPoE or other?
Other.
#8
26.7 Series / Trouble with Apple Private Rel...
Last post by tonys - Today at 09:33:02 PMI'm having issues with my iPhones reporting "Privacy Warning" and/or "internet not connected" errors since upgrading to 26.7. I applied the 26.7.1 patch today but the problems persist. Google AI is reporting that Apple's Private Relay is being temporarily blocked or getting slow access via Unbound DNS which causes iOS to timeout and issue these errors. I've tried a lot of different tests suggested by Google AI but I can't solve this issue. I don't know why DNS requests to Quad9 are getting stalled when they come through any device running Private Relay. This didn't happen under OPNSense 21.x.
I've also noticed slow updates on the OPNSense web page when going through the various settings. OPNSense is accessed from my Mac via Private Relay under Safari as well so this further indicates the problem is between Private Relay and Unbound DNS. It sometimes takes more than a full minute to update the OPNSense GUI whenever I switch to a different settings page if the new page hasn't been cached already.
I'm current using both AdGuard and Stevens Blacklist lists with the Normal relaxed/balanced blocking level setting.
I've also noticed slow updates on the OPNSense web page when going through the various settings. OPNSense is accessed from my Mac via Private Relay under Safari as well so this further indicates the problem is between Private Relay and Unbound DNS. It sometimes takes more than a full minute to update the OPNSense GUI whenever I switch to a different settings page if the new page hasn't been cached already.
I'm current using both AdGuard and Stevens Blacklist lists with the Normal relaxed/balanced blocking level setting.
#9
26.1, 26,4 Series / Re: IPv6 breaks after a while ...
Last post by DWM89 - Today at 09:27:14 PMThanks for the reply.
My current situation is this:
I have a static /30 IPv4 and static IPv6 subnet from my ISP (Vodafone business in BaWü Germany) (but no texactly sure whether /56, /59 or /62 since those are common prefix lengths that customers could get according to my research. i configured /56 and it works)
When on 25.7 all just works fine but when upgrading I didn't get neither IPv4 nor v6 address but when I clicked on the renew button in the interfaces overview my opnsense got the whole shebang. correct IPv4 and v6 and everything works fine in the beginning. I can connect to hosts that are only v6 and also other hosts that are only v4.
after a while not actively using the v6 I realize that I can't connect to v6 hosts via ssh anymore nor can I ping them.
not from my main client in my LAN net nor directly from my opnsense terminal.
in Interfaces overview the IPs are still shown on the WAN interface but as mentioned, only IPv4 remains working and reboots/removing and plugging back in the cable wont fix the issue
I didn'T configre "request only prefix" only "send prefix hint"
on 25.7 i see 3 v6 IPs/networks:
a public /128 and /64 and a fe80:/64
also I see a fe80: IP as a gateway
on my LAN interface I assigned prefix ID 0 and on my other 2 networks the IDs 1 and 2
are these helping information?
should I provide some more specifics?
best regards
My current situation is this:
I have a static /30 IPv4 and static IPv6 subnet from my ISP (Vodafone business in BaWü Germany) (but no texactly sure whether /56, /59 or /62 since those are common prefix lengths that customers could get according to my research. i configured /56 and it works)
When on 25.7 all just works fine but when upgrading I didn't get neither IPv4 nor v6 address but when I clicked on the renew button in the interfaces overview my opnsense got the whole shebang. correct IPv4 and v6 and everything works fine in the beginning. I can connect to hosts that are only v6 and also other hosts that are only v4.
after a while not actively using the v6 I realize that I can't connect to v6 hosts via ssh anymore nor can I ping them.
not from my main client in my LAN net nor directly from my opnsense terminal.
in Interfaces overview the IPs are still shown on the WAN interface but as mentioned, only IPv4 remains working and reboots/removing and plugging back in the cable wont fix the issue
I didn'T configre "request only prefix" only "send prefix hint"
on 25.7 i see 3 v6 IPs/networks:
a public /128 and /64 and a fe80:/64
also I see a fe80: IP as a gateway
on my LAN interface I assigned prefix ID 0 and on my other 2 networks the IDs 1 and 2
are these helping information?
should I provide some more specifics?
best regards
#10
26.7 Series / Re: Significantly lower CPU te...
Last post by gspannu - Today at 09:24:58 PMQuote from: Nullman on July 20, 2026, 04:58:03 PMNope. Its all default. No additional packages, no tuneables.
Thanks.. 👍
What is your WAN connection type? PPoE or other?
