Hello, After setting src.track to 0 I could reproduce the situation, but this time both entries disappeared after a short while (as per “interval” timer setting).
— Babak On 2 May 2017, at 16:26, Max wrote: > Could you set "src.track" to zero and check if the issue persists? > > > 02.05.2017 10:01, Babak Farrokhi пишет: >> Hello, >> >> Here it is: >> >> # pfctl -vvsS >> No ALTQ support in kernel >> ALTQ related functions disabled >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >> age 00:00:53, expires in 00:59:52, 6 pkts, 504 bytes, nat rule 0 >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >> age 00:01:21, expires in 00:59:20, 16 pkts, 1344 bytes, nat rule 0 >> >> # pfctl -vvss >> No ALTQ support in kernel >> ALTQ related functions disabled >> >> I am running 11-STABLE r317643. Please note that this is only reproducible >> when you reload your pf configuration and tables. >> >> — >> Babak >> >> >> On 2 May 2017, at 10:41, Max wrote: >> >>> Hello, >>> Can you show "pfctl -vsS" output? And what version of FreeBSD are you >>> running? >>> >>> >>> 01.05.2017 17:59, Babak Farrokhi пишет: >>>> Hello, >>>> >>>> I was running an experiment with pf in which I encountered an unusual case. >>>> >>>> In a nat setup, is this okay to have multiple similar entries in source >>>> tracking table? >>>> >>>> # pfctl -sS >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>>> >>>> There are actually three similar binding stuck in source tracking table. >>>> vmstat output also confirms separate memory allocation for three entries in >>>> source tracking table: >>>> >>>> # vmstat -z | egrep 'ITEM|^pf' >>>> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >>>> pf mtags: 48, 0, 0, 0, 0, 0, 0 >>>> pf states: 296, 8000005, 0, 1313, 2279, 0, 0 >>>> pf state keys: 88, 0, 0, 2655, 4558, 0, 0 >>>> pf source nodes: 136, 1500025, 3, 142, 7, 0, 0 >>>> pf table entries: 160, 800000, 4, 121, 47, 0, 0 >>>> pf table counters: 64, 0, 0, 0, 0, 0, 0 >>>> pf frags: 112, 0, 0, 0, 0, 0, 0 >>>> pf frag entries: 40, 100000, 0, 0, 0, 0, 0 >>>> pf state scrubs: 40, 0, 0, 0, 0, 0, 0 >>>> >>>> >>>> I can reproduce this behavior by reloading pf.conf and running traffic >>>> through >>>> the box and get a new entry added to source tracking table. >>>> >>>> Here is the nat rule: >>>> >>>> # pfctl -vsn >>>> nat on em0 inet from <internal-net> to any -> <external-net> round-robin >>>> sticky-address >>>> [ Evaluations: 368 Packets: 50 Bytes: 2084 States: >>>> 0 ] >>>> [ Inserted: uid 0 pid 6418 State Creations: 28 ] >>>> >>>> and timers: >>>> >>>> # pfctl -st >>>> tcp.first 10s >>>> tcp.opening 10s >>>> tcp.established 4200s >>>> tcp.closing 10s >>>> tcp.finwait 15s >>>> tcp.closed 10s >>>> tcp.tsdiff 30s >>>> udp.first 60s >>>> udp.single 30s >>>> udp.multiple 60s >>>> icmp.first 20s >>>> icmp.error 10s >>>> other.first 60s >>>> other.single 30s >>>> other.multiple 60s >>>> frag 30s >>>> interval 30s >>>> adaptive.start 0 states >>>> adaptive.end 0 states >>>> src.track 3600s >>>> >>>> Any ideas if this behavior is expected? >>>> >>>> — >>>> Babak >>> _______________________________________________ >>> freebsd-pf@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-pf >>> To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
signature.asc
Description: OpenPGP digital signature
