On Fri, Jan 14, 2011 at 12:17 AM, Claudio Jeker <[email protected]> wrote: > On Thu, Jan 13, 2011 at 03:38:44PM -0800, Daniel C. Sinclair wrote: >> I gave up trying to twist inside/outside to fit my situation. All my >> firewalls block in all with pass in exceptions on some interfaces, and >> pass out all with pflow. This solved my problems and is easy to >> understand. > > Please don't confuse the internal versus external LANs from in and > outgoing traffic on an interface. While you may not have a strict internal > external setup you have traffic comming in and going out of interfaces. > In case you want to have flow records for all traffic passing that box > make sure that all states created because of incomming traffic generate a > pflow state. So add keep state (pflow) to all pass in rules.
That confusion is precisely why I stopped using the words inside/outside and internal/external. I don't even try to explain to people that 'pass in' doesn't necessarily mean 'let stuff into our network' and vice versa. I find it is easier to explain that any connection that needs to go through a firewall must be 'passed into' the firewall, regardless of where it is coming from (internet, wifi, server dmz, staff subnet, etc). Once in, the firewall knows what to do with it since it knows the routes/policies/etc. >> Is Claudios idea for 'match in keep state(pflow)' really that >> different from my 'pass out keep state(pflow)'? > > Yes it is. Since match works totally different from pass. If you have other > pass rules then your pass out rule will be overruled by the later one. > Match has a sticky behaviour and will inherit the match settings to the > last pass rule. But it does not matter since match does not handle keep > state options at the moment. Oh, I didn't mean that match and pass are similar. I just meant that both of us wanted to put the 'keep state(pflow)' in a single place and have it apply to all traffic. Henning seemed to indicate that this was not a good idea for me to do, but at the same time agreed that your idea was good and that he may implement it. I don't really see a difference between the two - we have the same policy just different ways of implementing it. > Add keep state(pflow) to either all in or all out rules. Don't use any > pass rules that have no direction specifier and your double accounting is > history. Every connection beeing forwarded through a pf firewall ends up > with two states (unless you skip the outgoing interface in pf.conf). So > you need to ensure that only one of the two states has keep state (pflow) > set. I chose to put pflow on all 'pass out' rules - in my case I only have one of those. This catches all traffic that is forwarded through the firewall, and also catches traffic originating from the firewall itself (like NTP, DNS, ping, outgoing email, testing from the firewall, etc). All other rules are 'pass in'. I do add 'keep state(pflow)' on a few 'pass in' rules for connections to the firewall itself (for SSH, SNMP, ping, etc) since they won't get caught by the 'pass out' rule. Daniel
