PF firewall rules

[Greg Hennessy]

> 
> So ultimately what your saying is PF is too clever now and 
> can never be simplified like UDP state modes for single line 

The notion of UDP keeping state is overstated. 

Basic layer 3 'keep state' for UDP is nothing more than a watchdog timer
tracking how long it was since the last packet for the reverse flow arrived.

> firewall rules using rough careless flags options on a 
> firewall rules where everything is just going out keep state 

One  cannot 'keep state' for TCP in any meaningful fashion without tracking
the flags + sequencing. 

If you want a primitive packet filtered ACL from point a to b for TCP. 

	pass out on int inet proto tcp from a to b 
	pass in  on int inet proto tcp from b to a

will match all packets and allow that flow. 

> and otherwise blocking all in.
> 
> This is fair enough, I just had to ask. To me it just seemed 
> a bit unreasonable to bit so stricted about TCP while being 
> so lean and easy going and in one sense clever with UDP and ICMP.

At layer 3 there is nothing to track in UDP to keep state except the quad in
the header.

UDP by its very nature is connectionless. 
 
> While the inherited TCP flags give you the ability to be more 
> strict about it all I just would of thought if I want to have 
> a easy/non strict going firewall I would be able to configure 
> it like that with no problems.
> While I don't understand the TCP protocol as well as you 
> guys, I do tent to see as protocol racism, making it all easy 
> for the white UDP people and being tough on the TCP black 
> people (if it was a firewall/country of largely white 
> population in the 50s)

Oh puhleeze. Get some of idea of the fundamental difference between TCP and
UDP before making such a ridiculous statement. 

In particular I recommend reading TCP Illustrated by W Richard Stevens.  

> >But if you'd just prefer to not have "translation occur before 
> >filtering", I guess you're way too late to suggest that. It was a 
> >deliberate design choice, and people grew to appreciate and rely on 
> >this order.
> >  
> >
> Darn, I had wondered about this for a bit now, so all 
> IPFilter users have to readapt their mind frame for PF, 

We all had to do it, you will find once you get used to it, that the
equivalent PF policy is about half the size of the IPF one as a consequence.


> One way to kind of add onto the syntax but still keep the 
> "out" word in there would be to place the keyword "kernel" to 
> help let the user know which direction the packet is going in 
> and out of the internal interface.

Err, that's what matching against direction in the rule base does. 

> I don't know if it is the 
> best solution but I do get to keep my "out" word even if its 
> a bit selfish.

That's what tags are for. 

> 
> block out quick on $int_if kernel proto { tcp, udp, icmp } from
> 192.168.1.17 to any
> 
> Yes, one of the issues I had against blocking so early on the 
> internal interface is it ruins the ability to run services on 
> internal NAT ip servers using RDR for internal IPs but 
> providing a single IP to all users behind the firewall and 
> for those over the Internet.


Are you saying that you cannot do a transparent redirect on the inside
interface of the form ?

rdr pass on inside $TCP from <InsideNets> -> $PublicVIP port something ->
$DMZ-RFC-ADDRESS port something


> If I want to block some IPs from reaching the Internet but 
> still be able to use the web server behind NAT firewall I 
> have to allow extra firewall rules for those IPs before they 
> hit the firewall rule above that blocks everything going out 
> on the internal interface.

If the service sits on the LAN rather than on a DMZ interface, this is most
likely going to pear shaped unless you start disabling ICMP redirects
everywhere. 

>From a design perspective hosting any external facing service directly on
the most trusted part of the network is *not* a good idea. 


Greg