[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    RE: to rules
From:       Vedran Bender <vedran.bender () ansys ! com>
Date:       2003-01-28 13:29:13
[Download RAW message or body]

> -----Original Message-----
> From: Remco Post
> Sent: Monday, January 27, 2003 11:21 AM
> To: Remco Post
> Cc: ipfilter@coombs.anu.edu.au
> Subject: Re: to rules
>
> Ok, this caused a problem with the state table. Thanks for 
> the hint, or
> I may have never found this one. What I did is rewrite the rules to:
> 
> block  out quick on ip.tun2 to hme0:62.194.6.1 proto tcp from 
> 145.100.55.8/29 to any port = 80
> 
> block  out quick on ip.tun2 to hme0:62.194.6.1 proto tcp from 
> 145.100.55.8/29 to any port = 21
> 
> What I don't understand is that this seems to work. I don't 
> keep state,
> the rules are quick, so they don't continue down onto the ruleset
> (right?), and still I'm able to contact websites (and ftp sites).

By default, IPF scans the entire ruleset, then applies the "last"/"best"
match, so to speak.  If the "quick" keyword is used, processing any further
rules will STOP as soon as a matching rule is found, and the firewall will
act on the packet(s) immediately, so yes, you're right.

> Unfortunately, and I don't know how this cold be solved, is that I'd
> like to make an exception for one netblock, those I do want to contact
> via my tunnel. I tried something like:
> 
> pass out quick on ip.tun2 proto tcp from 145.100.55.8/29 to 
> 145.100.0.0/18 port = 80 flags S keep state keep frags
> 
> and put that as the first rule in my ruleset. Unfortunately, that does
> not work, and I'm sort of stuck for an answer. What could I put there,
> to make http traffic for 145.100.0.0/18 go via my default gateway, and
> the rest via hme0:62.194.6.1?

Why don't you try the "block in" vs. the "block out" approach and see how it
behaves?  Situations like these often are an inbound/outbound logic error,
rather than being an IPF problem per se.

The inbound/outbound directions are relative to the interface and packet
flow.  What is inbound in one situation may be outbound in another.
[prev in list] [next in list] [prev in thread] [next in thread]