I am setting up a new OPNsense box using 22.1.6. My old box is @ 21.7.8. I have all the settings rules in place and appears to be working ok so far.
I noticed that when looking at the Firewall Live View it now shows 'Default deny / state violation rule'.
Is this 'state violation rule' message something new for version 22, or do I have a settings to fix?
Thanks to all for a great firewall. Been using for 5 years now.
When you look at the automatically generated floating firewall rules, you will find exactly the one you see. I think it has just been renamed from the older "Default deny".
Just read the release notes for 22.1.6 and it mentions possible state violations in the deny label. Live view shows state violation on every default deny label. Is this what it meant or do I need to look for where the state violations are coming from?
Ok, they just renamed it. Took me by surprise. Thanks
Too many questions over the years why "default deny" blocks traffic that has other rules supposedly matching. Most of the time it was TCP traffic with Reset flags set so not even real traffic.
Cheers,
Franco
I am getting a ton of igmp Default deny / state violation rule blocks in my log, I enabled logging to track down packet loss with some apple HomeKit devices. Destination is 224.0.0.1 so its clearly multicast. Is this an issue or can it be ignored? I do get pass traffic on 1 vlan but the rest of the vlans get dropped. Source is all my switches:
Opnsense --> Aggregation switch --> Main switches/poe switches/servers
The blocks are originating from every switch but 1 which is interesting.
Edit: I also get blocks from a reverse proxy on 1 vlan to a server on another vlan. Both vlans have default allow all rules internally.
I got the same issue...
In my case ssh-sessions get killed, because after the first allow it is followed by denials.
I read somewhere this might be caused by packages being out of order/sequence.
Could this be caused by my use of vlans and a switch? (Although one system is also connected through the same switch and that one works fine.)
Quote from: Mr. Happy on June 27, 2022, 01:33:56 PM
I got the same issue...
In my case ssh-sessions get killed, because after the first allow it is followed by denials.
I read somewhere this might be caused by packages being out of order/sequence.
Could this be caused by my use of vlans and a switch? (Although one system is also connected through the same switch and that one works fine.)
I stumbled here investigating a similar issue where I have local ssh sessions across 2 internal networks getting killed after less than 30 seconds of connecting, but only from vlan traffic on a virtual machine. I am noticing this rule being applied to traffic that normally should get through and just can't quite figure it out yet.
I connect from 10.1.69.10 via ssh to 10.1.1.2. Initial connection good. Wait a few seconds. SSH session freezes.
Attaching image of initial accept and then rejection. I can't seem to get any rule right to fix it.
My issue was
fixed alleviated doing the following:
- Navigate to Firewall > Settings > Advanced/li]
- Go to Miscellaneous > Firewall Optimization
- switch from "normal" to "conservative"
This caused any of my "FA" and "FCA" TCP packages to stop being blocked, which was causing intermittent issues in certain applications (like connecting via SSH across different local networks). Changing the algorithm helped me idle a lot longer, but it still disconnects.
This is driving me nuts!
Quote from: almighty on July 16, 2022, 01:45:36 AM
My issue was fixed alleviated doing the following:
- Navigate to Firewall > Settings > Advanced/li]
- Go to Miscellaneous > Firewall Optimization
- switch from "normal" to "conservative"
This caused any of my "FA" and "FCA" TCP packages to stop being blocked, which was causing intermittent issues in certain applications (like connecting via SSH across different local networks). Changing the algorithm helped me idle a lot longer, but it still disconnects.
This is driving me nuts!
I did this, we will see. I have plenty of resources so shouldn't hurt anything.
I'm still having major issues. I eventually went into each firewall rule and enabled logging on them to help me trace through things. Turns out some of the blocks are legitimate due to there already being a stored "state" of the connection so anything trying to keep it alive or acknowledge it is just ignored. More of a red herring.
My latest issue is around SMB file sharing across subnets/vlans dropping connection (in addition to my ssh connection). I just cannot figure this out. I even just tried assigning spoofed macs to all vlans to ensure there wasn't some weird incorrect reply to the wrong MAC going on, but that did not fix it.
There's something further down that's hard to trace going on, and it may not even be at the firewall level. It could be the host machine (SSH/SMB server) that has multiple ips and it's re-routing out the wrong end or something.
Pretty sure that's what it is... the Linux server is replying back lazily through the fastest path, which is through a different way than the request came inbound. I need to implement this on the linux server: https://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming
Edit: It was definitely a Linux issue with switching interfaces. Once I put the vlan interface down on the machine the problem went away, isolating the issue. Then I put the vlan interface in a network namespace (netns) and I was able to keep the vlan on the Linux machine while segregating the routing to avoid this issue.
Let me add my 2 cents.
In Firewall->Diagnostics->Sessions
When FW optimizations are normal you can see that it expires after 30 seconds
When FW optimizations are conservative you can see that it expires after 900 seconds.
And indeed the SSH session lasts roughly for the same time.