Larry, I tired all of your suggestions one at a time and all the
iterations to see what difference they made.  the only one that made
the difference was adding keep state on the pass in/out on rl0, my
internal interface.  I thought that keep state was the way ipf kept
track of 'established' connections.  If a session was started on a
particular port, or in this case an interface, once it was allowed
through keep state would then let the session continue with no further
checking.  Why would it matter if I had keep state on rl0 since I am
passing everything be default?  It certainly had made a difference,
but why?

Thanks for your help.

On 6/9/06, Larry Moore <[EMAIL PROTECTED]> wrote:
The build of IP Filter gaurantees if no rule exists to pass traffic it will
be blocked - see your output from ipf -v

ipf: IP Filter: v4.1.8 (416)
Kernel: IP Filter: v4.1.8
Running: yes
Log Flags: 0 = none set
Default: block all, Logging: available

----- Original Message -----
From: "Trevor Osatchuk" <[EMAIL PROTECTED]>
To: "Michael Grant" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Friday, June 09, 2006 3:12 PM
Subject: Re: Problems with Azureus


> Yeah, all of the 50505 traffic from my internal ip is shown as
> blocked.  I looked at my rules, and I don't see where they are being
> blocked.  There is no specific block for that port.  Here are my
> rules:

ipfstat -iohn might be more helpful in identifying where the problem may be.

>
> #################################################################
> # No restrictions on Inside Lan Interface for private network
> # Not needed unless you have Lan
> #################################################################
>
> pass out quick on rl0 all
> pass in quick on rl0 all
>

Perhaps some rules with keep-state might help!

> # Block and log only the first occurrence of everything
> # else that's trying to get out.
> # This rule enforces the block all by default logic.
> block out log first quick on vr0 all
>
> # Block all inbound traffic from non-routable or reserved address spaces
> block in quick on vr0 from 192.168.0.0/16 to any #RFC 1918 private IP
> block in quick on vr0 from 172.16.0.0/12 to any #RFC 1918 private IP
> block in quick on vr0 from 10.0.0.0/8 to any #RFC 1918 private IP
> block in quick on vr0 from 127.0.0.0/8 to any #loopback
> block in quick on vr0 from 0.0.0.0/8 to any #loopback
> block in quick on vr0 from 169.254.0.0/16 to any #DHCP auto-config
> block in quick on vr0 from 192.0.2.0/24 to any #reserved for doc's
> block in quick on vr0 from 204.152.64.0/23 to any #Sun cluster
> interconnect
> block in quick on vr0 from 224.0.0.0/3 to any #Class D & E multicast
>
> # Block frags
> block in quick on vr0 all with frags
>

Perhaps the above could be commented out to rule out if it is contributing.

>
> # Block and log only first occurrence of all remaining traffic
> # coming into the firewall. The logging of only the first
> # occurrence stops an 'denial of service' attack targeted
> # at filling up your log file space.
> # This rule enforces the block all by default logic.
> block in log first quick on vr0 all
>

Is the above neccessary when IP Filters default operation is to block?


Reply via email to