Kajetan Staszkiewicz wrote: > > A quick question about pf from an ipfw user. > > > > Suppose I have three interfaces: $outside, $inside and $dmz. If I want > > to block any traffic from $dmz to $inside, unless it is > > > > 1. Return traffic from $inside to $dmz
I think I actually meant "return traffic from $dmz_net to $inside_net". > > pf is a stateful firewall and you can't really skip its statefullness. > It will always allow return traffic if you allowed outgoint connection. I know that, the question is rather how to *create* the state when traffic passes from $inside_net to $dmz_net because it's permitted by default. So I just need a "pass" rule to create state, even if otherwise this rule does nothing? > > > 2. ICMP traffic in any direction > > Sounds like a bad idea. Why would you do it? Well, for example, if a host in $inside_net sends a UDP datagram to a host in $dmz_net which generates an ICMP port unreachable message, I want the host in $inside_net to actually receive the message. If pf is THAT stateful and smart, then this rule is not necessary. > > > would these rules be sufficient? > > > > block in on $dmz To be more precise, it would be block in on $dmz from any to $inside_net pass in on $dmz proto icmp from any to $inside_net pass out on $inside ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The last rule will actually create the state for return traffic, is it correct? > > For me this rather looks like you allow from $dmz to $inside but block > from $dmz to $outside. Corrected above. > Rules are not "quick" so the last one matching > applies. However somebody else should verify this, I'm always only using > quick rules so I'm not 100% sure. As a person with some ipfw background, I try to take advantage of pf's features, e.g. "last match wins." Maybe it allows for more concise rules. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
