"Recent posts
#21
26.1 Series / Re: 26.1.rc1 -> 26.1 rc2 ........
Last post by PoMpIs - January 26, 2026, 09:02:33 PMI've also upgraded from RC1 to RC2 and everything works perfectly. I've ported the old rules to the new rules.
I also really like the categories in the new rules. 👌
Cheers 😊
I also really like the categories in the new rules. 👌
Cheers 😊
#22
26.1 Series / Re: New rule system
Last post by Monviech (Cedrik) - January 26, 2026, 08:57:24 PMAnother way to force priority changes:
- Fake Floating: Add a random loopback interface additionally to any single interface rule
- Fake Group: Add a new firewall group with a single interface
Or you change the approach how you build your ruleset.
- Fake Floating: Add a random loopback interface additionally to any single interface rule
- Fake Group: Add a new firewall group with a single interface
Or you change the approach how you build your ruleset.
#23
26.1 Series / Re: New rule system
Last post by franco - January 26, 2026, 08:54:32 PMIt kind of depends what parameters you're targeting the traffic on. You can just use a floating rule without an interface selected while select the source or destination of the traffic in an "in" direction rule correctly. There's no apparent need for an interface and routing domains don't exist so networks don't overlap in a routing setup.
Cheers,
Franco
Cheers,
Franco
#24
German - Deutsch / Re: Probleme mit Alexa / FireT...
Last post by danielhainich - January 26, 2026, 08:44:13 PMHi,
wie sollen denn die Geräte ohne DNS ins Internet kommen? Irgendwer muss die Namensauflösung machen. Und wenn Du den Unbound deaktivierst, machts vermutlich keiner mehr... Also ohne DNS kein Internet.
Was willst Du mit den Blocklisten erreichen?
wie sollen denn die Geräte ohne DNS ins Internet kommen? Irgendwer muss die Namensauflösung machen. Und wenn Du den Unbound deaktivierst, machts vermutlich keiner mehr... Also ohne DNS kein Internet.
Was willst Du mit den Blocklisten erreichen?
#25
26.1 Series / Re: New rule system
Last post by OPNenthu - January 26, 2026, 08:37:52 PMThanks for the correction. I think my question still stands. :)
#26
Hardware and Performance / Re: SFP+ to RJ45 slow WAN spe...
Last post by Seimus - January 26, 2026, 08:31:00 PMDefinitely try to replace the SFP, potentially some that could thermally perform better. Copper SPFs+ are known to be pretty hot..
SFPs have often a MON, a capability to measure temp. Not sure if yours has or if its readable by the OS but you could try to digg it out if you can see what are the temps during the issue.
Maybe you could as well if you are not afraid, open the device and check how is the SPF socket cooled, I mean is there a thermal pad maybe?
As well where is your FW placed? Is it in a rack or in a open space? If possible try to put it in open space.
Regards,
S.
SFPs have often a MON, a capability to measure temp. Not sure if yours has or if its readable by the OS but you could try to digg it out if you can see what are the temps during the issue.
Maybe you could as well if you are not afraid, open the device and check how is the SPF socket cooled, I mean is there a thermal pad maybe?
As well where is your FW placed? Is it in a rack or in a open space? If possible try to put it in open space.
Regards,
S.
#27
26.1 Series / Re: New rule system
Last post by franco - January 26, 2026, 08:28:58 PM"state-policy" directives have nothing to do with the parting of the rule GUI "floating" tab concept and they won't change behaviour either.
Cheers,
Farnco
Cheers,
Farnco
#28
Hardware and Performance / Re: SFP+ to RJ45 slow WAN spe...
Last post by pfry - January 26, 2026, 08:21:19 PMQuote from: viper359 on January 26, 2026, 05:08:55 PM[...]If appliance is powered down for 5 minutes or so, full PPPOE speeds return[...]
That does sound like it's cooling off, but if that's the case, it should be consistent. Do you have any other connectivity options? e.g. a DAC cable and a switch with 10GBASE-T and SFP+ ports.
#29
Hardware and Performance / Re: SFP+ to RJ45 slow WAN spe...
Last post by viper359 - January 26, 2026, 08:19:45 PMHi
Thanks for your response. Yes the sophos appliance. If I power it off for a few minutes, pppoe speeds resume. A few reboots in a row has also worked for both OPN and Sophos OS
Yes the LAN always works at full 10GBE speeds throughout. Which is also using the same type of sfp+ to rj45
I will see if I have a spare sfp I can try
Thanks for your response. Yes the sophos appliance. If I power it off for a few minutes, pppoe speeds resume. A few reboots in a row has also worked for both OPN and Sophos OS
Yes the LAN always works at full 10GBE speeds throughout. Which is also using the same type of sfp+ to rj45
I will see if I have a spare sfp I can try
#30
26.1 Series / Re: New rule system
Last post by OPNenthu - January 26, 2026, 08:18:23 PMIn the new rules system, how do we override a floating rule for a specific interface?
For example we have a quick block rule in Floating, but in one of the interfaces we want to override that block with a higher priority rule. Is this still possible?
In the old system we could just create another Floating rule for the specific interface and position it above the block rule. As far as I can tell, the pf manual allows for that:
https://www.openbsd.org/faq/pf/options.html#state-policy
https://man.openbsd.org/pf.conf.5
... by use of the word 'any' instead of 'multiple', it doesn't preclude floating rules for single interfaces. I think the behavior of the old rules system is still legal.
For example we have a quick block rule in Floating, but in one of the interfaces we want to override that block with a higher priority rule. Is this still possible?
In the old system we could just create another Floating rule for the specific interface and position it above the block rule. As far as I can tell, the pf manual allows for that:
https://www.openbsd.org/faq/pf/options.html#state-policy
Quoteset state-policy option
Sets PF's behavior when it comes to keeping state. This behavior can be overridden on a per-rule basis. See keeping state.
if-bound - states are bound to the interface they're created on. If traffic matches a state table entry but is not crossing the interface recorded in that state entry, the match is rejected. The packet must then match a filter rule or will be dropped/rejected altogether.
floating - states can match packets on any interface. As long as the packet matches a state entry and is passing in the same direction as it was on the interface when the state was created, it does not matter what interface it's crossing. It will pass.
The default is floating.
https://man.openbsd.org/pf.conf.5
Quoteset state-policy if-bound | floating
The state-policy option sets the default behaviour for states:
if-bound
States are bound to an interface.
floating
States can match packets on any interfaces (the default).
... by use of the word 'any' instead of 'multiple', it doesn't preclude floating rules for single interfaces. I think the behavior of the old rules system is still legal.
