Re: pfctl rtlabel expansion
* sfp <[EMAIL PROTECTED]> [2006-07-06 08:22]: > Using bgpd to apply labels to prefixes using rtlabel. Given the pf.conf > statement: > > pass in on $int_if02 from route "test" to any keep state > > How can I see the (rt)labelled prefixes that are actually being acted upon > using pfctl? you cannot. > When the same statement is (pf)labelled, pfctl fails to expand > the prefixes as well. I cannot parse that sentence ;( > > Eg > > pass in on $int_if02 from route "test" to any keep state label > "V115PERMIT:$proto:$srcaddr:$dstaddr:$dstport" > > [EMAIL PROTECTED] ~]# pfctl -sl > V115PERMIT:ip:?:any: 2 37 6334 21 2781 16 3553 > > I would prefer not to use a table in pf as prefixes are not removed when > they are withdrawn by bgpd. so you want to label teh routes, and be able to see the route label in the pf label for accounting purposes? > Outside of pf, the man pages for route(8) & netstat(1) do not indicate flags > for displaying the kernel routing table based on the label alone. I may > have missed it. In the absence of route show synxtax, is there a valid > wildcard for 'route get'? no. you can't get a list of prefixes by label right now. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: pfctl rtlabel expansion
"Henning Brauer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > * sfp <[EMAIL PROTECTED]> [2006-07-06 08:22]: > > Using bgpd to apply labels to prefixes using rtlabel. Given the pf.conf > > statement: > > > > pass in on $int_if02 from route "test" to any keep state > > > > How can I see the (rt)labelled prefixes that are actually being acted upon > > using pfctl? > > you cannot. Hmmm > > > When the same statement is (pf)labelled, pfctl fails to expand > > the prefixes as well. > > I cannot parse that sentence ;( Sorry if that was ambiguous. If a packet that is identified using 'from route "test"' is subsequently labelled in pf with 'label V115PERMIT:$proto:$srcaddr:$dstaddr:$dstport"', there is still no way to tell which prefix that packet originated from; as evidenced by pfctl -sl: V115PERMIT:ip:?:any: 2 37 6334 21 2781 16 3553 Is this normal, or have I made a syntactical error? > > > > > Eg > > > > pass in on $int_if02 from route "test" to any keep state label > > "V115PERMIT:$proto:$srcaddr:$dstaddr:$dstport" > > > > [EMAIL PROTECTED] ~]# pfctl -sl > > V115PERMIT:ip:?:any: 2 37 6334 21 2781 16 3553 > > > > I would prefer not to use a table in pf as prefixes are not removed when > > they are withdrawn by bgpd. > > so you want to label teh routes, and be able to see the route label in > the pf label for accounting purposes? No. I want to be able to make certain that pf is filtering on prefixes that are valid according to bgpd, and that prefixes that have been withdrawn by the bgp process are no longer going to be permitted in the ruleset. While it's true that pf won't necessarily see such packets since the box wouldn't have a route, it makes troubleshooting more difficult, particularly in the reverse case of dropped packets. How do I know that a prefix is being acted on? pf cannot tell me. It's not that I don't trust pf's mechanisms, but this seems to be a bit of a shortcoming - not being able to identify which prefixes 'from route ' actually refers to. > > > Outside of pf, the man pages for route(8) & netstat(1) do not indicate flags > > for displaying the kernel routing table based on the label alone. I may > > have missed it. In the absence of route show synxtax, is there a valid > > wildcard for 'route get'? > > no. you can't get a list of prefixes by label right now. Cool. Is support for this planned in the near or distant future? The 3.7 release notes (http://www.openbsd.org/plus37.html) make mention of route(8) being able to show labels: Display route labels with route(8)'s show command. Are these not the same labels, or is the above referring to something else (route get?). No mention in 3.8 or 3.9 release notes. I'm running 3.9. Thx for the info & nice work on OpenBGPD Henning. > > -- > Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] > BS Web Services, http://bsws.de > OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: pfctl rtlabel expansion
* sfp <[EMAIL PROTECTED]> [2006-07-06 17:32]: > > "Henning Brauer" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > * sfp <[EMAIL PROTECTED]> [2006-07-06 08:22]: > > > Using bgpd to apply labels to prefixes using rtlabel. Given the pf.conf > > > statement: > > > > > > pass in on $int_if02 from route "test" to any keep state > > > > > > How can I see the (rt)labelled prefixes that are actually being acted > upon > > > using pfctl? > > > > you cannot. > > Hmmm > > > > > > When the same statement is (pf)labelled, pfctl fails to expand > > > the prefixes as well. > > > > I cannot parse that sentence ;( > > Sorry if that was ambiguous. If a packet that is identified using 'from > route "test"' is subsequently labelled in pf with 'label > V115PERMIT:$proto:$srcaddr:$dstaddr:$dstport"', there is still no way to > tell which prefix that packet originated from; as evidenced by pfctl -sl: > > V115PERMIT:ip:?:any: 2 37 6334 21 2781 16 3553 > > Is this normal, or have I made a syntactical error? the rule label macros are expanded at ruleset load time, so the information in tehm is pretty static. > > > pass in on $int_if02 from route "test" to any keep state label > > > "V115PERMIT:$proto:$srcaddr:$dstaddr:$dstport" > > > > > > [EMAIL PROTECTED] ~]# pfctl -sl > > > V115PERMIT:ip:?:any: 2 37 6334 21 2781 16 3553 > > > > > > I would prefer not to use a table in pf as prefixes are not removed when > > > they are withdrawn by bgpd. > > > > so you want to label teh routes, and be able to see the route label in > > the pf label for accounting purposes? > > No. I want to be able to make certain that pf is filtering on prefixes that > are valid according to bgpd, and that prefixes that have been withdrawn by > the bgp process are no longer going to be permitted in the ruleset. While > it's true that pf won't necessarily see such packets since the box wouldn't > have a route, it makes troubleshooting more difficult, particularly in the > reverse case of dropped packets. How do I know that a prefix is being acted > on? pf cannot tell me. > > It's not that I don't trust pf's mechanisms, but this seems to be a bit of a > shortcoming - not being able to identify which prefixes 'from route ' > actually refers to. that doesn't make sense, sorry. when you have a rule that refers to a route label pf does a route lookup for the src or dst IP on the routing table, looks for the label and if it is there see if there's a match, then moves on. since the routing table and the packet flows are highly dynamic there pretty much is no way of manually verifying pf does things correctly, you have to trust it here. btw, in your case, a block in from no-route block out to no-route should suffice. > > > Outside of pf, the man pages for route(8) & netstat(1) do not indicate > flags > > > for displaying the kernel routing table based on the label alone. I may > > > have missed it. In the absence of route show synxtax, is there a valid > > > wildcard for 'route get'? > > no. you can't get a list of prefixes by label right now. > Cool. Is support for this planned in the near or distant future? The 3.7 > release notes (http://www.openbsd.org/plus37.html) make mention of route(8) > being able to show labels: > > Display route labels with route(8)'s show command. > > Are these not the same labels, or is the above referring to something else > (route get?). No mention in 3.8 or 3.9 release notes. I'm running 3.9. route show shows labels. you cannot use a label as filter criteria for which routes to display right now. it would make sense tho. I have no plans to implement this in the near future, but a patch would be welcome :) > Thx for the info & nice work on OpenBGPD Henning. as always, we're looking for more success stories for http://www.openbgpd.org/users.html ;) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...