I've been trying to diagnose a mysterious issue where a UDP state
disappears before it's supposed to expire. I finally tracked it down to
pfsync. On the primary server, the state entries look like:
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:02:21, expires in 00:04:59, 34:34 pkts, 17887:20606 bytes,
rule 64
all udp 96.251.22.157:58308 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
age 00:02:21, expires in 00:04:59, 34:34 pkts, 17887:20606 bytes,
rule 49
They shouldn't expire for five minutes. However, the same states, at the
same time, on the backup server:
Thu Jun 4 18:17:27 PDT 2020
all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
age 00:02:22, expires in 00:00:00, 0:0 pkts, 0:0 bytes
all udp 96.251.22.157:58308 (10.128.110.73:9430) -> 198.148.6.55:9430
MULTIPLE:MULTIPLE
expire. And then the synchronization from the backup to the primary
removes them.
These two systems share a carp vip, and other than the macro defining
the local IP address of each individual system, pf.conf is exactly the
same on both.
How come when the state is transferred to the backup after initially
being created on the primary, the state on the backup has the default
timeout for udp multiple rather than the custom one defined in my rules:
match out on $ext_if from 10.128.0.0/16 nat-to $ext_vip
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)
That doesn't seem right. Am I missing something?
Thanks much.
