Pass through packets

[Guillaume]

>> With iptables
>> we can set a rule: iptables -t filter -A FORWARD -i eth0 -o 
>> eth1 etc....
>>
>> With packet filter how can I have a such way of processing my packet ?
>>
>> If a setup a rule pass in on $if_internal inet proto tcp \
>> 	from $internal_networks to any \
>> 	flags S/SA modulate state
>>
>> The packet from my internal networks can also exit on my DMZ 
>> interfaces !
> 
> Not if you run a default block policy it wont. 
> 
I've seen my problem

I have a rule with is something like opendoor for outgoing packet from
the firewall...

And NAT rules are applied before filtering rules.
SO for traffic going from internal to external, I only have to setup a
pass rule on the internal interface !

But for packet going from internal to dmz
I have to setup 2 rules.... one with pass in on the internal interface
and another one with pass out on the dmz interface !

> The 1st packet filtering rule of every pf policy should be
> 
> 	block log all
> 
> From there only permitted ingress & egress flows will be permitted. 
> 
Yep... that's what I have done now.

So if I want a very accurate filtering for forwarding packets, I must
setup 2 rules every time... one pass in on the incoming interface and
another with pass out on the outgoing interface...


>> Is the only way to setup that is to specify a destination 
>> with ! { $dmz_networks1, $dmz_networks2 } ?
> 
> 
> There's a number of ways to skin this particular cat. 
> 
> I am partial to using generic egress rules in combination with tagging
> myself. 
> 
I'll check the egress rules...

> My personal PF policy style is to code '1st' match by using 'quick' on every
> rule. 

Mee too

> Whether that's a consequence of being infected with the Checkpoint and Pix
> virus at an early age, I know not :-). 
> 
LOL

i'm infected with Linux netfilter/iptables... :-)

> I would also counsel against the use of 'any'. 
> Negation is a mite more logical and less error prone on larger policies
> IMHO. 
Ok... I'll think about that too

> Tables will also reduce macro expansion. 
> 
Ok... the same :-)

Thanks
> 
> Greg
> 
Guillaume

-- 
Guillaume
E-mail: silencer_<at>_free-4ever_<dot>_net
Blog: http://guillaume.free-4ever.net
----
Site: http://www.free-4ever.net