Truely amazing work Henning. OpenBSD already leads the way (at least in my opinion) for a packet filter, whether it's commercial or open source, and these latest additions will make my life so much easier. If there is any more testing that needs to be done, I have many spare computers, almost completely unused T1 (only by me and two other co-workers), a /28 of IP addresses (6 currently used, but I could trim that down a few), and a cabinet drawer full of spare nics at work and I'm in charge of it all, so I could do some testing when I have some spare time. Again, thanks so much for this amazing work.
Jason On 6/16/05, Henning Brauer <[EMAIL PROTECTED]> wrote: > So, after cleaning up the interface abstraction code in pf with Ryan > before the Hackathon, I worked on interface groups integration to pf. > > An interface group, is, well, a group of interfaces (surprised, > anyone?). Interfaces can join and leave interface groups any time, and > can be member in an arbitary number of groups. The join and leave is > done via ifconfig: > ifconfig sk1 group dmz > makes sk1 join the group dmz, and > ifconfig sk1 -group dmz > removes sk1 from that group again. A group is removed when it does not > have any members any more and pf does not refer to it. > So far, so good. > Now, pf can use interface groups instead of interfaces basically > everywhere now. Sounds simple, but is quite powerful. > For example, you can (ab-)use interface groups as a kind of aliasing. > Just a group with one member, and refer to that. For example, hang your > dmz of an interface group called "dmz" - if you do this in a consistent > manner, your ruleset is entirely independent from the underlying > hardware, you make interfaces join the groups in their respective > hostname.if files which are machine dependent anyway. > now, if you add a second dmz interface for whatever reasons with the > same policy, you don't even have to modify (usually not even reload) your > ruleset - just make the 2nd dmz interface join the group :) that of > course makes much more sense for your "external" interface, where you > might get a second internet connection, or customer-facing interfaces > which have the same policies. > pf can refer to interfaces and interface groups which do not exist > (yet) - once the interface / the group shows up, it will be atached to > the construct pf uses and (without ruleset reloads!) things Just Work. > Moreover, you can use the brace notation for a dynamic interface name > to ip address translation, as in, > pass in on tun0 proto tcp to (tun0) port ssh keep state > and the like. Internally, pf uses a table named after the > interface inside the _pf anchor, and updates the table whenever there > are address changes on that interface. > That works for interface groups too, now - including correct handling > of interfaces joining and leaving the group in question, of course. > so, if you put all your customer-facing interfaces (vlans or physical, > or any combination... as long as it is interfaces :) ) in a group > "customers", (customers) correctly expands to all ip addresses on your > customer-facing interfaces - and (customer:network) to all networks on > them. And suddenly nice things like > block in on egress from (customer:network) > work. > > For clonable interfaces (almost all virtual ones are, tun, ppp, lo, > vlan, etc), the clones are all member of an interface class group, for > example, all loopback interfaces are part of the "lo" interface group, > all vlan interfaces are part of the "vlan" group, etc. this is > especially useful in cases where interfaces get created by a daemon on > a "next free" basis, like tun with userland ppp. > > now, we had a sick idea for a while, and since we finally had all the > parts together now I could implement it - there is an "egress" > interface group now which follows the default routes. > This interface group contains all interfaces which IPv4 and IPv6 > default routes point to - usually, that is one. It even understands > multipath routes already, despite them not being useful yet. > The group is updated (actually, rebuilt) every time there is > changes/additions/deletions of an IPv4 or IPv6 default route. > So, imagine that on your notebook, where you are sometimes on wireless > and sometimes on wired network connections - just write your pf.conf so > that it refers to the egress group instead of wi0 and em0, and it will > Just Work :)
