Thus spake Damian Gerow ([EMAIL PROTECTED]) [27/06/03 13:14]:
> Was the first way I was doing it. I'm currently breaking it down to:
>
> block in log on rl0 from any to any head 10
> block in log on rl0 from any to 192.168.1.1 group 10 head 100
> block in log on rl0 from any to 192.168.1.2 group 10 head 101
> <and others>
>
> block in log on rl1 from any to any head 20
> block in log on rl1 from any to 192.168.1.1 group 20 head 100
> block in log on rl1 from any to 192.168.1.2 group 20 head 101
> <and others>
>
> pass in quick proto tcp from any to 192.168.1.1 port = 80 flags S keep state
> keep frags group 100
> pass in quick proto tcp from any to 192.168.1.2 port = 80 flags S keep state
> keep frags group 101
> pass in quick proto tcp from any to 192.168.1.2 port = 443 flags S keep state
> keep frags group 101
> pass in quick proto tcp from any to 192.168.1.2 port = 4333 flags S keep state
> keep frags group 101
<snip>
> Or is there anything else that anyone can think of? Or any reason why I
> shouldn't do what I'm doing above?
Well, I just answered one of my own questions:
## ipf -I -F a -f /etc/ipf.rules
201:ioctl(add/insert rule): File exists
210:ioctl(add/insert rule): File exists
211:ioctl(add/insert rule): File exists
#
ipf doesn't like it when you start a group in two different places... :(
So does anyone have any pointers/recommendations? Use a different grouping
strategy? Define all inbound packets on all other interfaces, then just use
a generic 'block in from any to any', and use it to group rl0 and rl1?
