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
