Re: pfctl rtlabel expansion

2006-07-06 Thread Henning Brauer
* 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

2006-07-06 Thread sfp

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 label'
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

2006-07-06 Thread Henning Brauer
* 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 label'
 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, ...