Ian Smith wrote:
I don't see why you think it's broken? Apart from obvious efficiency of
having a check-state rule earlier, to get on with matching this packet
against existing dynamic rules without wading through intervening rules,
state is still only checked once; like it says, the O_PROBE_STATE opcode
only causes a state check at the first check-state, keep-state or limit
rule (encountered); any others found then become a short-path NOP.
Personally I like to do traffic accounting before any packet is whisked
off to be dealt with (and accounted by) any keep-state rules, though as
your example shows that can be done afterwards, if not piped or such.
But I can't see why you ever wouldn't want to check the existing state
of any src-addr/src-port <-> dst-addr/dst-port packet before attempting
to add a new dynamic rule for that same session?
My firewall rules a re very complex and I could want to change the
action stored with a particular session..
trivial example:
Assuming that keep-state did NOT do a check state:
10 check-state
100 skipto 1000 tcp from any to any in $inside keep-state
[...]
1000 skipto 2000 tcp from any to any iplen 1480-9200 keep-state
[...]
2000 count log ip from any to any
[....]
now I change the action for jumbo packets for accounting purposes to
go straight to 2000
with implicit check state..
1/ I have no way of changing what to do as the keep-state on 100 will
never bee done
2/ I have no idea what happens when you effectlvely do a
"1000 skipto 1000".
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
