Messages

Yes, the rules are on the interface 'in'.

When looking at the states & sessions (after the schedule has expired and the Pass rule not effective) filtered to the single IP address on the device of the scheduled VLAN, there is no 'in' rule active, only the out rule.
BUT despite there being no IN rules associated with that VLAN / IP Address, traffic still flows.

The config on this device is a couple of years old now - we got the DEC750s with BE licences late 2023, so there have been many firmware updates since then.
As it's a fairly simple config, I'm just going to nuke, reinstall the BE firmware and reconfigure later today...

Although working now, been looking around some more with this blocking issue; really can't work out why forcegw would affect in this way.
I'm not totally comfortable with leaving it be - think it's time to nuke the config and start again with a factory default config. Luckily only a few VLAN and PPPoE to setup, so not too much hassle...

Thanks for the pointers here; I've fixed this but if I'm honest I'm not totally sure why!

I managed to reproduce the issue on my home DEC750, by starting a download of a large ISO from Ubuntu and watching it when the blocking was supposed to start. Using the hint from EricPerl, I checked the actual rule allowing the traffic to remain flowing and it was the allow everything out the gateway (forcegw) one. New connections were getting blocked by the scheduled Pass rule as expected.
By checking "Disable force gateway" in the firewall advanced settings, scheduled traffic blocking (by disabling the pass rule on a schedule) worked as expected.

The forcegw rule seemed to be associated with the PPPoE ISP tunnel (Fibre ONT to igb0, carrying PPPoE over VLAN) and I don't fully understand what this forcegw rule is supposed to achieve, but checking the disable box fixed the issue and everything else seems to work fine...

Thanks all :)

Yep, default was unchecked, but to be sure I tried it with both checked and unchecked - same behaviour.

Originally I was using block but on my second round of testing it was a pass rule, and it didnt break existing Teams call.

One single rule for the interface that was Pass based on schedule.

If this pass rule was either disabled manually on the GUI or disabled via schedule, any new connections would be blocked (as watching the live log) but the existing connection through opnSense to the MS Teams mothership remained in place, and the Teams call continued.

Thanks for your help with this. I ended up deleting all firewall rules and starting afresh but it still didnt work as expected.
Foe example, a Teams voice call would continue through the firewall if established before the corresponding allow rule was disabled...

Digging a bit, it seems to be a "feature" in the underlying FreeBSD firewall itself, see https://github.com/opnsense/core/issues/3166

It looks like the only workaround is to create a custom cron job to reset the sessions after the firewall rule has been changed.

Hi,

I'm running latest BE and have had an issue for a while that I have only just got around to posting about :)

When I use firewall schedule to block traffic to a certain VLAN, I can see new sessions are being blocked fine, but any existing sessions remain open.
How can I automatically force terminate any existing sessions with the firewall rule, so block traffic on that VLAN is instant, not waiting for an open session to close?

Not a direct answer, but I'm running PPPoE on a DEC750 connected via FTTH.

Zenarmour is running on LAN interface, and have no problem saturating my 930/930 fibre uplink connection.

I have enabled the PPPoE tunables, but not sure they are needed any more - Protectli have a good articles on opnSense and PPPoE

[/usr/local/etc/rc.syshook.d/start]

Ive had no end of issues with DEC750 and 1gb SFP / DAC cables late 2023/24, and ended up engaging support as it was still under warranty.
Issues seem the same as this - SFP L2 comes up but no traffic flows; stop/starting the interface will work until the next power cycle, when it dropped again.
Happened with the known working FS 1g SFP on the product page, as well as various Cisco SFP & DAC cables.
Affected both WAN (1gb FS SFP to 1gb ONT) and LAN 1gb DAC to switch SFP - both Cisco and Ubiquity.

Strange variation is if you factory reset the device into default config, it works as expected, its only once you create your own config the issue arises...
Support were going to discuss internally as they think its something with the timings on SFP initialisation.

Workaround they gave me is to create a file in /usr/local/etc/rc.syshook.d/start

called 80-axgbe

containing

#!/bin/sh
ifconfig ax0 down && ifconfig ax0 up
ifconfig ax1 down && ifconfig ax1 up
configctl interface reconfigure wan

make sure its executable with chmod +x 80-axgbe

then every reboot, the interfaces get forced down/up to reset the SFP.

Seems to work, but not sure I totally trust it to come back up in all circumstances, so I'm using it at home now...

That's going to be ISP specific.

My ISP (UK CityFibre) doesn't need MAC and MTU is worked out by OPNsense itself.
I would try without and if no luck, try adding them...

Hi

First you need to set up the vlan tagged port.
Go to Interfaces, Other Types, VLAN
Press the red + on the right to add a new vlan

device will be vlan0.401
parent is the physical port linked to your ISP
vlan tag is 401

then save & apply

next you need to add the vlan tagged interface to the pppoe config

So Interfaces, Point to Point, Devices
Add the pppoe details, the link interface will be vlan0.401 (from above)

Finally, use the Interfaces, Assignments menu to set the interface for WAN to pppoe0 (or whatever your pppoe interface was called from above)

Should be all you need :)

my 8gig DEC750 handles my symmetrical 1gig fibre connection (FTTH) using PPPoE without any issues...
I have Zenarmour running as well :)

Sleepyal - what does your CPU usage look like?
That hot with low cpu is a concern, but if it's high CPU, it would look at what's causing that...

Mine is rarely above 20% CPU according to the GUI graphs, and warm to the touch

There is a teardown photo on here: https://wiki.junicast.de/en/junicast/review/opnsense_dec740

Its a 740 (same hardware though) and see the existing SSD model number from the photo and work out specs from that?

Yeah, its odd.

Don't think its config as I downloaded the config when working from live, and compared it to when not working as a proper install.
Apart from some monit and certificate data being different, the tunables and network setup were identical.

Suspect its some kind of boot time initialisation thing done in a live boot only...

Got a ipolex 10g SFP+ to RJ45 from Amazon today - works fine with exactly the same setup / config...