Re: pfsync and rule specific state timeouts
Paul B. Henson(hen...@acm.org) on 2020.06.07 15:23:16 -0700:
> On 6/5/2020 11:15 PM, obs...@loopw.com wrote:
>
> >1) ???egress??? can be used to reference the external nic in a rule,
> >instead of having a specific IP. Egress is defined as the nic with
> >the default route. pass in quick log on egress inet proto tcp to
> >(egress) port 22
>
> Ah, I think I seen that in the past but did not remember it offhand.
> Thanks; although these boxes run OSPF and the default route changes
> depend on the network state, so I'm not sure that this would work.
Depending on what you are doing, you can also use interface groups to refer
to interfaces, and if you put only one interface into a unique group, you
can thereby refer in pf to a single interface by its group.
That way different interfaces that server the same function on your two
systems can still be used with an identical ruleset.
>
> >2) Both of the firewall IP addresses can be in a rule if egress is
> >not suitable for your topology, something like this will sync over
> >cleanly with pfsync: pass in quick log on $ext_if inet proto tcp to {
> >$fw1_ext $fw2_ext } port 22
>
> I thought about doing that, but I ended up just making a table with a
> single IP address in it, each router having the appropriate IP address
> in the table, and the rule referencing the table being exactly the same
> on both. Everything is working properly now.
Or use groups again.
> I do still wonder if this requirement is documented anywhere? I've been
> looking, and could not find it. It was very confusing trying to sort out
> why my states were mysteriously disappearing, I ended up having to add
> some extra debugging code in the kernel to figure out what was happening.
This is indeed not very well documented, if at all.
Maybe you can create a diff for the pfsync(4) manpage?
/Benno
Re: pfsync and rule specific state timeouts
On 6/5/2020 11:15 PM, obs...@loopw.com wrote:
1) “egress” can be used to reference the external nic in a rule,
instead of having a specific IP. Egress is defined as the nic with
the default route. pass in quick log on egress inet proto tcp to
(egress) port 22
Ah, I think I seen that in the past but did not remember it offhand.
Thanks; although these boxes run OSPF and the default route changes
depend on the network state, so I'm not sure that this would work.
2) Both of the firewall IP addresses can be in a rule if egress is
not suitable for your topology, something like this will sync over
cleanly with pfsync: pass in quick log on $ext_if inet proto tcp to {
$fw1_ext $fw2_ext } port 22
I thought about doing that, but I ended up just making a table with a
single IP address in it, each router having the appropriate IP address
in the table, and the rule referencing the table being exactly the same
on both. Everything is working properly now.
I do still wonder if this requirement is documented anywhere? I've been
looking, and could not find it. It was very confusing trying to sort out
why my states were mysteriously disappearing, I ended up having to add
some extra debugging code in the kernel to figure out what was happening.
Thanks…
Re: pfsync and rule specific state timeouts
> What if two systems being used as redundant firewalls had different network
> cards? This would make the names of the interfaces different, resulting in
> rule sets that were not the same, preventing per-rule state timeouts from
> being properly applied.
1) “egress” can be used to reference the external nic in a rule, instead of
having a specific IP. Egress is defined as the nic with the default route.
pass in quick log on egress inet proto tcp to (egress) port 22
2) Both of the firewall IP addresses can be in a rule if egress is not
suitable for your topology, something like this will sync over cleanly with
pfsync:
pass in quick log on $ext_if inet proto tcp to { $fw1_ext $fw2_ext } port 22
pfsync and rule specific state timeouts
Where is it documented that in order for pfsync to properly synchronize rule specific state timeouts that the rule sets on the systems being synchronized must be *exactly* the same? I have a pair of redundant firewalls synchronizing state, and recently added a couple rules that increase the default timeout for a UDP connection: pass out quick on $ext_if proto udp tagged VOIP_UDP keep state (udp.multiple 360) pass in quick on vlan110 proto udp from any to port = 9430 tag VOIP_UDP keep state (udp.multiple 360) Despite the timeout being set to six minutes, the states kept disappearing after approximately a minute of idle time. After spending a lot of time trying to debug it, I finally figured out that the states replicated to the backup firewall received the default one minute timeout rather than the six minute timeout specified by the rule, and when they expired on the backup firewall, they were deleted from the primary firewall. After further debugging, I discovered that pfsync on the receiving system only applies the rule specific timeout if the entire rule set is exactly identical on both systems. While my rule set was functionally identical on both systems, it was not exactly the same, having rules such as: pass in quick on $ext_if proto tcp from any to $ext_if port ssh which had the primary IP address on each system substituted, resulting in a rule set that was "different". This seems overly strict. What if two systems being used as redundant firewalls had different network cards? This would make the names of the interfaces different, resulting in rule sets that were not the same, preventing per-rule state timeouts from being properly applied. I can understand you wouldn't want to apply the wrong timeout, but it seems that validating a per rule checksum rather than an entire rule set checksum would be more flexible. Both the rule number and the rule content on both of these systems for these rules are exactly the same. It is just other rules that have a different IP address given that each system has its own separate IP address in addition to the virtual carp address...
