Re: lost pf state - disappeared before expiration?
On 5/17/2020 8:40 PM, Strahil Nikolov wrote: > What is your conf having as a timeout ? Both of the rules explicitly override the default timeout with a six minute rule level timeout: pass in quick on vlan110 proto udp from any to port = 9430 tag VOIP_UDP keep state (udp.multiple 360) pass out quick on $ext_if proto udp tagged VOIP_UDP keep state (udp.multiple 360) Which is being successfully applied, as shown by the states, which start out with a six minute expiration: all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE age 00:00:02, expires in 00:06:00, 24:23 pkts, 12163:13840 bytes, rule 63 all udp 96.251.22.157:55205 (10.128.110.73:9430) -> 198.148.6.55:9430 MULTIPLE:MULTIPLE age 00:00:02, expires in 00:06:00, 24:23 pkts, 12163:13840 bytes, rule 48, source-track However, once a minute has passed, and the expiration shows five minutes left: age 00:02:21, expires in 00:05:00, 29:29 pkts, 14166:18501 bytes, rule 63 all udp 96.251.22.157:55205 (10.128.110.73:9430) -> 198.148.6.55:9430 MULTIPLE:MULTIPLE age 00:02:21, expires in 00:05:00, 29:29 pkts, 14166:18501 bytes, rule 48, source-track Both of the rules simply disappear. Interestingly, I believe the default multiple:multiple timeout is one minute. Which makes me wonder if for some reason the default timeout is being applied to these rules which have an explicit longer timeout? That seems buggy, unless there is something wrong with my configuration. Even so, for a state that says it has five minutes left to go away doesn't seem right. Thanks for the input…
Re: lost pf state - disappeared before expiration?
On May 18, 2020 1:58:49 AM GMT+03:00, "Paul B. Henson" wrote:
>I'm trying to set a longer timeout on a udp state, and for some reason
>it
>seems to be disappearing before the expiration 8-/.
>
>There are 3 rules involved:
>
>pass in quick on vlan110 proto udp from any to port = 9430 tag VOIP_UDP
>keep state (udp.multiple 360)
>
>pass out quick on $ext_if proto udp tagged VOIP_UDP keep state
>(udp.multiple 360)
>
>match out on $ext_if from 10.128.0.0/16 nat-to { $ext_vip }
>sticky-address
>
>I turned on pf debugging, when the connection is created I see:
>
>
>May 17 15:36:39 lisa /bsd: pf: key search, in on vlan110: UDP wire: (0)
>10.128.110.73:9430 198.148.6.55:9430
>May 17 15:36:39 lisa /bsd: pf: key setup: UDP wire: (0)
>10.128.110.73:9430 198.148.6.55:9430 stack: (0) -
>May 17 15:36:39 lisa /bsd: pf: key search, out on em2: UDP wire: (0)
>198.148.6.55:9430 10.128.110.73:9430
>May 17 15:36:39 lisa /bsd: pf: key setup: UDP wire: (0)
>198.148.6.55:9430 96.251.22.157:63529 stack: (0) 198.148.6.55:9430
>10.128.110.73:9430
>
>and there are state entries:
>
>all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE
>age 00:02:21, expires in 00:05:00, 29:29 pkts, 14166:18501 bytes, rule
>63
>all udp 96.251.22.157:55205 (10.128.110.73:9430) -> 198.148.6.55:9430
>MULTIPLE:MULTIPLE
>age 00:02:21, expires in 00:05:00, 29:29 pkts, 14166:18501 bytes, rule
>48, source-track
>
>However, right after the 5 minute mark the states disappear. The last
>pf log
>entries are;
>
>May 17 15:38:47 lisa /bsd: pf: key search, in on vlan110: UDP wire: (0)
>10.128.110.73:9430 198.148.6.55:9430
>May 17 15:38:47 lisa /bsd: pf: key search, out on em2: UDP wire: (0)
>198.148.6.55:9430 10.128.110.73:9430
>
>I was hoping to see something about expiration in the pf debug logs but
>this is all that appears to be available.
>
>Any idea why these states would go away when there is 5 minutes left
>before the expiration?
>
>Thanks much...
Short googling shows me:
In the case of protocols without "start" and "end" packets, PF simply keeps
track of how long it has been since a matching packet has gone through. If the
timeout is reached, the state is cleared. The timeout values can be set in the
options section of the pf.conf file.
What is your conf having as a timeout ?
Best Regards,
Strahil Nikolov
