On Tue, Jan 25, 2005 at 03:28:23PM -0500, Peter Fraser wrote:
> The reason I attached the tag to the block was so I didn't have to
> repeat the
> "inet proto icmp" and "icmp-type $icmp_types"
> for each following line. That still doesn't explain why my way doesn't
> work.
The reason why it isn't working is not your use of tag/tagged. That
scheme should work as intended. And it does here, in a test setup:
# pfctl -vvsr
@0 block drop in inet proto icmp all icmp-type echoreq tag icmp
[ Evaluations: 6 Packets: 0 Bytes: 0 States: 0 ]
@1 pass in quick all keep state tagged icmp
[ Evaluations: 3 Packets: 0 Bytes: 0 States: 0 ]
(ping the host)
# pfctl -vss
self icmp 10.2.2.6:22945 <- 10.1.1.1:22945 0:0
age 00:00:07, expires in 00:00:05, 3:3 pkts, 252:252 bytes, rule 1
# pfctl -vvsr
@0 block drop in inet proto icmp all icmp-type echoreq tag icmp
[ Evaluations: 94 Packets: 0 Bytes: 0 States: 0 ]
@1 pass in quick all keep state tagged icmp
[ Evaluations: 46 Packets: 6 Bytes: 504 States: 1 ]
So the first ICMP echo request is matching rule number 0, gets the tag
attached, then matches rule number 1 including the tag check, then
creates state. The tag is added when rule 0 matches, even if it isn't
the last matching rule. That's the key point in this scheme.
If it doesn't work in your case, the explanation must be one of the
filter criteria you're using (check $icmp_types, echo request/reply is
type 8). Reduce your ruleset until it works like the example above, then
re-add rules and criteria until you spot where it breaks.
Daniel
