kern/129103: [ipfw] IPFW check state does not work =(

[KES]

Здравствуйте, Ian.

 >> But now NOTICE: 11 packets for rule 6 and 9 (7+2) packets for dinamic rule
 >> with rule 6 as parent. 11 != 9, so here couter lost 2 packets =(

IS> Plus the original 2 trigger packets, shown above at rule 2, making 11 
IS> packets shown at rule 6.  I'm not entirely sure why the total of 12 
IS> packets isn't shown (6 packets, each both in and out as you've not 
IS> specified direction on your rules), but suspect it's to do with the 
IS> position of your NAT rule, and/or the fact that you're not showing 
IS> counts for 'via ng1'.
IS>

There are 11 packets because of first packet received from ng1 do not
counted. This ok here.
But dynamic rules must count packets when they are created (see plus sign on attached
picture). Actually packets are pass them but not counted (

PS. Attachment that do not pass size control in last message =(

>>I suggest you'll need to study the code of /usr/src/sbin/ipfw/ipfw2.c
>>and /sys/netinet/ip_fw*.[ch] to find out just how it works now, before
>>writing code to implement the above.  I can't see anyone else taking an
>>interest in implementing such a thing (but I've been wrong before :)
Any way check-state must have body, to control whick trafic we want to
check for dynamic rules. If you afraid of mistakes in firewall for
dynamic rules are created but never check, for this
check-state log can be added, so for expired dynamic rules, but no one
packet had pass through them log message will be added to
/var/log/security
WARNING: dynamic rule has expired and no traffic pass through it


 >> Another usefull feature is that that check-state must have body.
 >> You must allow user to check same conditions as for other rules. For
 >> example:
 >> check-state icmp via ng0
 >> It will prevent user from having unexpected maching for flows on other
 >> interfaces  (ng1 interface as in my example).
 >> Also I think it will be handy to have many tables for dynamic rules.
 >> It is like to have many routing tables. For example:
 >> ipfw add xxx check-state 1 via ng0
 >> ipfw add xxx check-state 2 via ng1
 >> ipfw add xxx skipto yyy icmp via ng0 keep-state 1
 >> ipfw add xxx skipto yyy icmp via ng1 keep-state 2

For last two days I have testing dynamic rules I notice next
for this scheme of load balancing with two connection to different ISP
03510 check-state
03511 prob 0.500000 skipto 3531 ip from any to any via ng*
03521 skipto 3522 ip from any to any keep-state
03523 setfib 0 ip from any to any
03525 skipto 3550 ip from any to any
03531 skipto 3532 ip from any to any keep-state
03533 setfib 1 ip from any to any
03535 skipto 3550 ip from any to any
03990 allow ip from any to any via ng*

Such services as ICQ does not work properly. Because of some idle time
other dynamic rule is created and so ICQ client has lost its
connection because it is actually change its IP

So here it will be use full to point how long dynamic rule will exist
03521 skipto 3522 ip from any to any 5190 keep-state 0  << stands to keep dynamic rule until TCP->FIN is received \
  or some sysctl ....MAX_TIME variable
03521 skipto 3522 ip from any to any <someport> keep-state 60  << here we want to extend/prolong dynamic rule will exists
03521 skipto 3522 ip from any to any keep-state  <<no conf, default from sysctl


-- 
С уважением,
 KES                          mailto:kes-kes at yandex.ru