Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - mrzaz

#1
Quote from: bamf on October 03, 2026, 12:16:56 PMThis is not a bug. Create an Alias if you want to combine entries.

After doing some more testing I found that:

if you do it Predefined and then Input it remove predefined.

If you do Input first and then select Predefined it shows like both is selected, but this only until press apply/save. Then it only save the last one selected.

So the confusion was that I was able to selected 2 at first (like multiselect) but later was reverted to only last selected threw me a curveball.

So we could revert this topic from bug to rather an opinion about function.

It would have been easier if I select something and later click on something else in the drop down it should auto deselect the previous entry so when closing the dropdown (before apply/save)
there should only be one entry = the last thing selected and not as today that you find it after you pressed save.

Best regards
Dan Lundqvist
Stockholm, Sweden
#2
Quote from: Patrick M. Hausen on October 03, 2026, 11:36:54 AMI wasn't aware you could do both in one rule. Always used it as either - or.

Apparently it is working as a multiselect function.

If you do the input function first and then select the predefined after it works OK but if you select the predefined first and then selected the input function it removes the predefined function.

Dan Lundqvist
Stockholm, Sweden
#3
Quote from: Patrick M. Hausen on October 03, 2026, 09:31:11 AMWhen you select "single host or network" you are supposed to enter an IP address or network manually. When you select any predefined alias, e.g. "LAN net" the type is implicit.

Yes, i understand that.

But why I reported this is the fact that selecting a predefined object first in a multiselect option and later select an object that requires an input, the previous selected item in the multiselect is removed.

If I select the object which requires input first and then  select the predefined as second it stores both.

It shouldn't matter in what order you select them.

Best regards
Dan Lundqvist
Stockholm,Sweden
#4
Hello,
I am running latest "OPNsense 26.7.5-amd64" found a "bug" in "Edit rule" under "Source" when
first selecting "LAN Network" and later multiselect "Single host or network" and add anything.

Then the "LAN Network" is removed and only stores the "Single host or network".
If I then multiselect again and select "LAN Network" then both is stored.
Seems like when I have multiselect anything before "Single host or network" it gets removed
regardless what is entered.

One more interesting thing is that the default edit field for "Single host or network" is "lan".
Regardless if I enter a network/24 beside the "lan" or remove "lan" and enter network/24
the previously selected "LAN Network" gets unselected.

If I later select source again and again select "LAN Network" then both is multiselected OK.

Have not tested all combinations but seems to be an issue with this multiselect handling.
Could possible be in all multiselect inputs that contains "Single host or network".

I included 2 screenshots inline and rest in the zip.

Best regards
Dan Lundqvist
Stockholm, Sweden
#5
Hello,

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)
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.00

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.)
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
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
#6
Hello,
I am running latest 26.7 i stumbled on a thing that is a bit confusing.

In NAT you have 3 settings to use:  Manual, Pass and Register rule.
- Manual = Choose this if you want to create your own Firewall ‣ Rules [new] manually. No linked filter rule is created.
- Pass = A filter rule will be automatically added and updated. This rule cannot be seen or edited in Firewall ‣ Rules [new].
- Register rule = Adds a linked filter rule in Firewall ‣ Rules [new] that is automatically updated when the NAT rule is updated. The created filter rule cannot be manually edited.

I created a brand new NAT rule called "TEST" with following:
- WAN, IPv4, TCP
- Source = Any
- Destination = WAN address, Single port or range, 1234
- Translation = 192.168.x.y, Single port, 1234

And then I selected "Register rule" (so I should see a linked rule in Rules even if not possible to modify.)
BUT, when I did that I still can't see the readonly rule in rules list.  (Running the new rules engine.)

I then changed to a lighter skin and realized that the readonly NAT generated rules was hiding
under one more "Automatically generated rules" at the bottom that is named exactly as the one
at the top which is a bit misleading (even if it is correct).

Would it be possible to change the bottom "Automatically generated rules" to something more
explanatory like "Automatically generated NAT rules"  or "NAT Automatically generated rules"


Dan Lundqvist
Stockholm, Sweden
#7
Quote from: JohnSchnee on July 16, 2026, 01:22:51 PMHi,

are you sure this was changed in the last update?

I'm using rebellion for a long time, and thats like its normal design, which I really appreciate.

I'm working at night alot, and all the colours are somehow darker than in other themes.

I have not tested Rebellion for a very long time so I could not say if this was
as before upgrade. Was just baffled by an overall dark theme to suddenly having
what background that poked the eyes a bit. :-)

But if it is nothing new since before 26.7 then we could just close this thread.

//Dan
#8
Hello,
I just tested Rebellion theme on 26.7 and also got some funky color scheme
on input boxes giving white background with black text background and white text.

//Dan Lundqvist
Stockholm, Sweden
#9
26.7, 26.10 Series / Re: Cicada theme
July 16, 2026, 12:01:25 PM
I see the same issue in mine as well.
I have sent an email to the guardian of the cicada theme and we'll see what they say.

//Dan Lundqvist
Stockholm, Sweden
#10
Quote from: nero355 on July 16, 2026, 12:36:40 AMHow many Interfaces does your NAS have ?

Usually this kind of stuff leads to A-Sync Routing issues that need to be solved...
2
But second one is right now not in use.

Danne
#11
Quote from: Patrick M. Hausen on July 15, 2026, 10:08:43 PMThese packets should not go through the firewall at all if 192.168.x is the same x for both systems. I'd first check the netmasks/prefix-lengths of both systems.

Both OpnSense (.20 LAN) and NAS (.64) is in same net and do have same netmask in both machines.
Also the NAS has .20 as default GW and it is working. Running both from outside in to webserver (NAT) but also from inside to other Synology NAS remote.

//Dan
#12
Quote from: Patrick M. Hausen on July 15, 2026, 09:58:38 PMCould you post the details of a blocked packet?

Sure. But see my updated comments as well in main thread.

__timestamp__   2026-07-15T22:01:22
ack   3617553731
action   [block]
anchorname   
datalen   0
dir   [in]
dst   192.168.x.20
dsthostname   
dstport   80
ecn   
id   13194
interface   em1
ipflags   none
ipversion   4
label   Default deny / state violation rule
length   40
offset   0
protoname   tcp
protonum   6
reason   match
rid   02f4bab031b57d1e30553ce08e0ec131
rulenr   5
seq   
src   192.168.x.64
srchostname   
srcport   47713
status   2
subrulenr   
tcpflags   A
tcpopts   
tos   0x0
ttl   44
urp   1024

//Danne
#13
Hello,
I have an issue that I could not find the culprit to that is driving me crazy.

In the live log I get a "Default deny / state violation rule" from a my local NAS that
is on my LAN network and should not block this port.
64 = NAS
20 = OpnSense LAN interface

LAN  In  2026-07-15T21:40:22  TCP  192.168.x.64:56672  192.168.x.20:80  block  Default deny / state violation rule

Other IPs in my LAN does not have any issues accessing port 80 on .20

I am using the latest OPNsense 26.1.11_10-amd64 and is using the new upgraded style rules.

I even have a "Default allow LAN to any rule" enabled but also tried a separate LAN_HOME to LAN_HOME alias firewall for both in and out.
And have also made a specific to .64 but still same issue.

Is there anyone that could point me in the right direction why this only happens from one device and not all ?

I do have CrowdSec and Q-Feed plus a few others but have tested to switch off Intrusion Detection (suricata)

I have talked a bit with ChatGPT and it gave me some hints.
As the entry in the live log contains only A (ACK) it could be:
An ACK packet means:
It is not the start of a TCP connection (which would be a SYN packet).
It is trying to continue an existing TCP session.
OPNsense/PF is saying: "I don't have a state for this connection," so it logs Default deny / state violation rule and drops the packet.
1. The state expired.  This is very common with browsers that reuse keep-alive connections.
2. NAS kept the connection alive - Many NAS devices (especially Synology and QNAP) maintain persistent HTTP/HTTPS sessions.

This is most likely the culprit.

In other words, PF expected a state entry that no longer exists.

//Dan Lundqvist
Stockholm, Sweden
#14
Quote from: franco on July 15, 2026, 01:53:42 PM>- Add option to clean out configuration data in config.xml for plugins not longer installed.

How about System: Configuration: Defaults: Components: all the entries that are annotated with "(not installed)".  :)


Cheers,
Franco

Nice. I didn't know about this one.  :-)
I have been running OpnSense now for quite many years but you never learns it all.
New things to discover.  hehehe

I will check but I think that one will most likely do what I want.

//Danne
#15
I think we need to close this thread as it, for an unexplained reason started to work.
I could now see that packets sent, that earlier never got a reply now suddenly started to respond.

I did one thing though.  I uninstalled the apcupsd plugin and re-installed and now it works.

/Dan