Re: interface groups and pf
Hi all.
And is ALTQ will work on such groups? For example, I had
altq on $ext_if_1 priq bandwidth 10Mb queue { q_pri_1, q_def_1 }
queue q_pri_1 priority 7
queue q_def_1 priority 1 priq(default)
altq on $ext_if_2 priq bandwidth 10Mb queue { q_pri_2, q_def_2 }
queue q_pri_2 priority 7
queue q_def_2 priority 1 priq(default)
So, can I dispense just one altq?
altq on $grp priq bandwidth 10Mb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)
--
engineer
Re: interface groups and pf
where do one get the the 1 litre stella bottle? /Isak tony sarendal wrote: pf is the best thing since the 1-litre stella bottle. It's good to see that it continues to improve. This is cool stuff. /Tony S
Re: interface groups and pf
Henning Brauer wrote: So, after cleaning up the interface abstraction code in pf with Ryan before the Hackathon, I worked on interface groups integration to pf. ... joining to others: great work. So for now isakmpd have not need to listen on the routing socket by itself to be truly dynamic with interfaces' changes. Instead of it, isakmpd should refer to interface groups just like refers to interface names and default route for now. It it correct understanding of the future of isakmpd in this area? Thanks.
interface groups and pf
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 :)
Re: interface groups and pf
Cool how's your new notebook?
Re: interface groups and pf
Marvelous work. Thank you. :)
Re: interface groups and pf
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 :)
Re: interface groups and pf
On Thu, 16 Jun 2005 20:55:48 +0200, 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. Henning, Ryan and all involved -Very Amazing Work. Thank You! JCR
