Messages

This issue plagued me for quite some time.  I had advanced settings set within Wireguard to set the DNS without realizing the impact it had on the OPNsense box's own DNS for updates and troubleshooting via the console.  Once I removed this advanced DNS setting and then set it on the DHCP end, my /etc/resolv.conf was back to normal and fixed my DNS issues.

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.

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.

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