Allowing "Sloppy State" for NAT?

[BillyJoePiano]

I'm trying to figure out how to allow "sloppy state" for NAT rules.

For allow rules on the Firewall, I see there's an option to allow "Sloppy State".  My understanding is that this causes the rule to ignore TCP sequence numbers (although there may be more to it than that?)  In practice, it seems like there are fewer dropped connections when I allow "Sloppy State"

However, I do not see the option for "Sloppy State" in either Port Forwarding rules or Outbound NAT rules.  And I'm not seeing where the corresponding auto-generated "allow" rules exist for these NAT rules, although they do seem to be working since the connections work as expected!  I'm using the latest stable version, OPNsense 25.7, just installed this week!

I was hoping to configure this "sloppy state" for a special use-case that involves two different hosts (client and server) on different local subnets, using both a port forwarding rule and an outbound NAT rule.  Therefore, any "allow" rules on the WAN interface wouldn't be applicable in my situation.


A slightly more detailed explanation of the setup:

The client sends traffic which it thinks is destined for a specific address/port combo on the public internet.  However, the port forwarding rule translates this traffic's destination address to the server, which is located on an isolated management network that the router is also connected to (although the router does NOT serve as a default gateway for this network, which is strictly for local traffic)

Furthermore, in order for the server to correctly route its responses (since the server has multiple interfaces), the source address for this client-originating traffic also has to be translated using an outbound NAT rule, to become the address of the OPNsense router.  Otherwise, the server would try to route the responses through its default gateway on a different interface, and I don't want to mess with the routing table of the server.

In short, I have to trick the client, by making the server look like an address on the public internet, and then I have to trick the server by making the client look like the OPNsense's interface on the isolated subnet.  Thus, the need for two NAT rules.

The problem arises if there is a brief break in the connection, and some TCP sequences get lost.  It seems like the traffic is getting lost after that, because I have to completely reset the connection for it to work again.  It seems like a situation where "Sloppy State" might help...

The only other consideration is that the server's port is fixed, while the client's port is ephemeral.  If there were a way to make the client's port fixed, then it would be very easy to deal with lost-state traffic -- simply create these same rules in reverse (Port forwarding NAT from server to client, followed by Outbound NAT translating to the public IP which the client expects).  However,  with an ephemeral client port, I can't know my target port on the port forwarding rule, so that approach is a dead end.  Which is why I'm wondering about creating a "sloppy state" on the original NAT rules.