Growing states table, some leak?

jimp

Once you are booted into the debug kernel, see if you can reproduce the problem.

If you can, see if anything additional shows up in the system log.

If you don't see the problem on the debug kernel, then that may also confirm that what Kristof attempted to fix there was the actual problem.

w0w

@jimp
I see it's growing, but not reached its limit. When should I expect anything additional in logs? Can you provide some keywords?

EDIT: Ahh wait... forgot to select the right kernel :)

w0w

I regret to inform you that the firewall is not available
because of

I don't see anything useful in the log files, nothing new, nothing related to the problem.

jimp

Just to confirm, in each of your tests these systems have state synchronization (pfsync) configured and enabled, right?

Is it enabled with an IP address for the peer filled in or just enabled and left blank?

Is the sync interface private between the two HA nodes alone? Or could there be something else on the sync segment also doing pfsync?

w0w

@jimp said in Growing states table, some leak?:

Just to confirm, in each of your tests these systems have state synchronization (pfsync) configured and enabled, right?

Yes, exactly

@jimp said in Growing states table, some leak?:

Is it enabled with an IP address for the peer filled in or just enabled and left blank?

'pfsync Synchronize Peer IP', 'Synchronize Config to IP' are filled on the primary node with peer IP address, on the secondary 'pfsync Synchronize Peer IP' only filled.
'Set a custom Filter Host ID' is left blank, but I see those generated IDs on both nodes.

@jimp said in Growing states table, some leak?:

Is the sync interface private between the two HA nodes alone? Or could there be something else on the sync segment also doing pfsync?

Direct connection between firewalls, 10.0.88.0 network, not used anywhere else.

kprovost

@w0w Can you try turning up pf's debugging? (pfctl -x loud)

On a system that's not yet run out of states I suspect you're going to see "pfsync_state_import: unknown route interface: <if name>". That'd confirm my current theory.

jimp

@w0w said in Growing states table, some leak?:

'pfsync Synchronize Peer IP', 'Synchronize Config to IP' are filled on the primary node with peer IP address, on the secondary 'pfsync Synchronize Peer IP' only filled.
'Set a custom Filter Host ID' is left blank, but I see those generated IDs on both nodes.

Maybe I'm reading this wrong but this should be matching on both systems for State Synchronization (pfsync). You should have it enabled on both and have both set with the address of the peer (or both blank) -- it's not like XMLRPC, state sync wants to work in both directions.

And related to what Kristof asked above, also check the output of ifconfig -l on both systems, it should (ideally) match so they all have the same interfaces in the OS. What he's noting is that it may be tossing an error if there is a state for a certain type of rule on an interface that does not exist on the peer node. (e.g. PPPoE WAN, maybe a VPN interface in certain cases, that sort of thing)

w0w

@jimp
No this not your reading, it was me writing early morning .
State Synchronization enabled on both and have peer IP filled.

@jimp said in Growing states table, some leak?:

And related to what Kristof asked above, also check the output of ifconfig -l on both systems, it should (ideally) match so they all have the same interfaces in the OS. What he's noting is that it may be tossing an error if there is a state for a certain type of rule on an interface that does not exist on the peer node. (e.g. PPPoE WAN, maybe a VPN interface in certain cases, that sort of thing)

Yes, this can be the cause of the problem. WAN2 have different interfaces.

@kprovost said in Growing states table, some leak?:

Can you try turning up pf's debugging? (pfctl -x loud)

Will do that ASAP. Thanks.

w0w

@jimp, @kprovost said in Growing states table, some leak?:

pfctl -x loud

pfsync_state_import: unknown route interface: igb0

Hmm… Yes. That's it.

kprovost

@w0w Cool. The fix is under review in https://reviews.freebsd.org/D41779 and should easily make 23.09.

The only way I see to work around this is to make sure that every interface used as a route-to target exists on all members of the HA setup. You could create dummy interfaces with ifconfig epair name <ifname> if that's difficult for some reason.

w0w

@kprovost
Thanks a lot!
Not sure if ifconfig epair name <ifname> can be used on pfSense, I think I am going with VLANs instead...
EDIT: No, VLANs can't be used, for the same reason :)

jimp

@w0w In the past, users have used a single interface lagg to work around similar problems. Then the interfaces end up as laggX.<vlan> on both systems.

w0w

@jimp said in Growing states table, some leak?:

@w0w In the past, users have used a single interface lagg to work around similar problems. Then the interfaces end up as laggX.<vlan> on both systems.

Thank you, sir!
This is definitely a good idea, I've reconfigured both firewalls to use LAGGs, will see…

What about adding this workaround to https://docs.netgate.com/pfsense/en/latest/recipes/high-availability.html ?

jimp

We only claim to support systems with matching hardware and so on officially, so while it may work it's not something we want to document that much and imply it should be relied upon regularly.

That said, I think it may be mentioned somewhere already in there since it used to be a problem with state matching and pfsync if the interfaces didn't line up in the OS. Different problem but similar workarounds.

w0w

@jimp
Ok, great.
It's funny that this leak didn't make itself known earlier.