On 10/13/06, Daniel Hartmeier <[EMAIL PROTECTED]> wrote:

> You let the ping pass in. The stack tries to forward it. When it
> tries to send the ping out through an interface, pf blocks it
> without generating any packet itself. However, the function call to
> send out the packet failed (the packet couldn't be sent out, pf
> prevented it), and the stack reacts to that failure by issuing an
> ICMP error to the sender of the ping, similar to how it would do if
> it had found no route to the destination, or if you had unplugged
> the cable of the interface the packets should be sent out through.

Thanks very much for the clear explanation. Now it all makes sense. :-)

> Generally, you should try to block the packets as early as possible,
> i.e. on the input path. With static routing, you should be able to
> tell which packets will end up going out on what interface based on
> the destination address...

Somehow I had wrapped my brain around the concept that blocking on the
*egress* interface was the cool way (in my mind) to implement simple
policies like "if traffic from interfaceA to interfaceB then pass, but
if traffic from interfaceA to interfaceC then block" by using tags. I
thought this would permit me to avoid having to actually specify IP
blocks in most of my rules, thereby saving on the number of rules and
their evaluation cost.

Because each interface represents a different "type" of traffic (i.e.
normal users, programmers, remote VPNs) I thought it would be possible
for me to base the policies solely on the combination of
ingress/egress interface and direction of flow, and then create
matching pf rules where I didn't have to specify actual IP ranges (I
hoped that would save me from having to change my pf rules any time a
new "allowed" subnet was added to one of the interfaces).

The way I understand it now I guess I have two options: either use
simple ingress/egress interface + direction policies (like a
NetScreen) but learn to live with the fact that I'll get back ICMP
errors if something is blocked, or else use filters on the ingress
interface based on destination addresses, but at least the packet drop
will be "incognito". :-)

Thanks again,
-Martin

-- 
"Suburbia is where the developer bulldozes out the trees, then names the streets
after them."

                                                   --Bill Vaughan

Reply via email to