2013/6/20 Stuart Henderson <s...@spacehopper.org> > I suspect you may have an issue where state is not being created where > you expect it. > > It's now recommended (and we've changed the sample pf.conf to match) > to start your ruleset with an explicit "block" (or "block log") rule to > ensure that you don't accidentally allow any traffic to pass without > keeping state.
It indeed was that. I examined the state table: > 20:14:33 (0) ~ # pfctl -vvvs state | grep -A 2 8.8.8.8 | grep -A 2 icmp > all icmp 195.182.23.4:33976 (192.168.5.96:16748) -> 8.8.8.8:8 0:0 > age 00:00:01, expires in 00:00:09, 1:1 pkts, 84:84 bytes, rule 1 > id: 51c8341900244302 creatorid: b318f311 > all icmp 8.8.8.8:8 -> 192.168.5.96:16748 0:0 > age 00:00:01, expires in 00:00:19, 1:0 pkts, 84:0 bytes, rule 453 > id: 51c8341900244305 creatorid: b318f311 and it seems another rule: > 20:23:26 (0) ~ # pfctl -vvs rules -R 453 > @453 pass out all flags S/SA modulate state > [ Evaluations: 1085510 Packets: 1020472 Bytes: 534749622 States: 3995 > ] > [ Inserted: uid 0 pid 13556 State Creations: 27966 ] was creating another state that ,,hijacked'' packets preventing from NAT-ing with the first rule. Thanks for the tip! Could you also explain to me how is such a thing possible? I mean, creating a new state with another rule while one was already created. Is it related to evaluating if the NAT-ed packet can pass out on the external interface?
