IPSEC rules as floating not working

junicast

Hi,

pfSense 2.4.4p3 CARP with two dedicated X86 systems.

I have an IPSEC Tunnel to a remote destination.
Our users come in locally via LAN interface but there are also OpenVPN roadwarrios. Both type of clients shall get the same set of rules which is why I use floating rules where I select both the LAN and the OpenVPN interface for the rules. That way I can keep the rules in sync to each other. Reasonable, right?
There is one rule that is for connections to a remote site that is connected via IPSEC. The IPSEC connections is using (S)NAT though, meaning I created two phase 2 entries in the IPSEC tunnel, one for each interface.
Those floating rules don't work though.
If I specify one rule in the LAN interface and one in the OpenVPN interface seperately they work.
What can I do to make them work in floating or isn't that possible with IPSEC connections?

interface rule:

floating rule (there are actually two interfaces selected but can't grow the selection box)

junicast

What I was lacking was the Quick flag on the floating rule because within the non-floating rules of the interface there's a REJECT rule.
Without that Quick flag it's Last Fit not First Fit.

Derelict

I am going to expand on that a little.

As the rule set is processed, rules without quick set determine what happens to a packet when the end of the rule set is reached. Packets can be matched by multiple non-quick rules that can change the action to be taken as the rule set is processed.

There can also be match rules that set certain characteristics (like a pipe or shaping queue or packet tag) and processing always continues through the rule set because they neither block nor pass traffic. Match rules always behave like non-quick rules.

Processing stops and the matching action is taken when a rule matches with quick set.

This is how the default deny rule works. It is very high in the rule set and sets all traffic on all interfaces to deny but is not quick. So if nothing further down changes that (like a matching pass rule) that is the action taken on the packet when the end of the rule set is reached.

junicast

@Derelict
Thank you for that good explanation.
I think for my purpose it would be better to create Interface Groups because all I want is to keep rules for different interfaces in sync to each other.

Derelict

Interface groups are great if the rule set can be crafted so it applies properly to all interfaces in the group. There is usually some difference in rule sets on each interface, however.

I use an interface group to block egress of anything RFC1918 out the WANS group, for instance. (Or ULA on IPV6WANS, etc)

Another application I have seen is setting each interface's DHCP server to set the same DNS server (not the interface address) and you can then make an interface group rule that passes DNS to that server.

junicast

In my case we have users who work remotely via VPN who whall get the same filters as those who work locally.