borrow on all queues

[Travis H.]

Does putting borrow on all child queues make any sense?

The way I read it, it does, so like a child queue that isn't using its
bandwidth, can be borrowed by a sibling queue, is that correct?
--
Security Guru for Hire http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

contributions to pf FAQ/manpage whatever

[Travis H.]

What would be the appropriate way to submit additions to the PF FAQ
and/or pf.conf manpage?  Specifically, what is the source format,
where can I get the source (for the FAQ, I know where to get the
unformatted manpage), and to whom exactly should I send the diffs?

TIA
--
Security Guru for Hire http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

Re: PF and label expansion limitations

[Travis H.]

I don't see why you couldn't just feed your ruleset through a
preprocessor like m4 before passing it to pfctl.  It's just text. 
Make up your own syntactic sugar.

Back in the days before pf, I used to do shell expansions along the lines of

myhost="$(hostname)"
ipf ... -f /dev/stdin <-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484


preprocess
Description: Binary data

Re: pf -> no memory buffers

[Travis H.]

I removed all tagging and queueing and still had the problem.

Attached is the output of "vmstat -m" shortly before the system was rebooted.

If anyone has any troubleshooting ideas, I'm all ears.

The only other thing that has changed lately is that I'm now using one
of the Soekris 4-port PCI NICs.
--
Security Guru for Hire http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484


bar
Description: Binary data

Re: clarification of NAT behavior

[Daniel Hartmeier]

On Fri, Apr 07, 2006 at 12:04:23PM -0400, Gabriel Wachman wrote:

> >>>If NAT translation happens BEFORE any filter rules are evaluated
> >>>(see http://www.openbsd.org/faq/pf/nat.html), then wouldn't it be
> >>>true that an outbound packet from the internal network will be
> >>>seen by the filtering engine as a packet with source IP of the
> >>>firewall?

Yes, a packet from the internal host going out on pf's external
interface will have its source address translated already when it is
filtered.

For incoming packets of the same connection, the point is moot. Since
there always is a state entry for translated connections, the incoming
replies will match that state entry and pass without any ruleset
evaluation. Hence, it's irrelevant whether the ruleset would be
evaluated before or after the reply's destination address is translated
back, because it isn't evaluated for such packets.

> >To me, that clearly indicates that the filtering engine sees only the
> >post-translated packets, with no idea of the contents of the
> >pre-translated packets. Therefore the filtering engine should only
> >see the translated source IP and destination IP of outbound and
> >inbound packets, respectively, from the NAT'ed internal network.

On the external interface, that is true.

Each packet is filtered on both interfaces, the internal one and the
external one. On the external one you'll be seeing already translated
packets, on the internal one not-yet (or back-)translated packets.

So, if you want pf to make decisions based on the untranslated source
address, you can do so on the internal interface. You can either block
based on address there, or add a tag to the packet, which will be
recognized by rules on the external interace.

The only question from you I seem to be able to identify is "is the FAQ
correct", and the answer is "yes". If I missed the real question, or you
just didn't ask it, explain :)

Daniel

Re: contributions to pf FAQ/manpage whatever

[Daniel Hartmeier]

On Fri, Apr 07, 2006 at 09:09:30PM -0500, Travis H. wrote:

> What would be the appropriate way to submit additions to the PF FAQ
> and/or pf.conf manpage?  Specifically, what is the source format,
> where can I get the source (for the FAQ, I know where to get the
> unformatted manpage), and to whom exactly should I send the diffs?

The FAQ (its HTML source code) is maintained in the CVS repository[1], you
can check out a copy using cvs(1) from one of the public mirrors[2] like

  $ cvs -d $CVSROOT -q checkout www/faq/pf

Then edit the HTML files until they contain the changes you want to make
and render properly

  $ cd www/faq/pf
  $ vi index.html
  $ lynx index.html

and produce a unified (the -u option matters) diff

  $ cvs -q diff -u >~/my.diff
  $ more ~/my.diff

Then mail it to the public www@ list or the maintainers directly, who
are nick@ and [EMAIL PROTECTED] Note that the lists generally strip MIME
attachments, so include the diff in the body of the mail as plain text.

The man page is similar, but you'd send the diff to misc@ or tech@,
there aren't dedicated maintainers, but if you want to contact someone
personally, check the CVS history for someone who has recently commited
to the file you have a diff for.

If you plan larger changes, submit them in smaller chunks, each
containing one particular aspect entirely, those are easier to digest.

Daniel

[1] http://www.openbsd.org/cgi-bin/cvsweb/www/faq/pf/
[2] http://www.openbsd.org/anoncvs.html

Re: clarification of NAT behavior

[Gabriel Wachman]

Daniel Hartmeier wrote:


Each packet is filtered on both interfaces, the internal one and the
external one. On the external one you'll be seeing already translated
packets, on the internal one not-yet (or back-)translated packets.
  
I think that is the crux of my confusion. For example, I thought that a 
packet matching:


pass in on $int_if from $int_if:network to any keep state

and no other rules would be automatically passed out on the external 
interface. In other words, you're saying that the pf rules are evaluated 
once per interface, whereas I thought it was once, period. That clears 
up everything. Well, regarding pf, at least :)


Maybe it would be helpful to have an ASCII diagram or one or two 
sentences with an example in the FAQ showing exactly how a packet 
traverses a multi-interfaced host (or is this already explained?); I'm 
sure I can't be the first person to stumble on this issue.


Thank you,
Gabriel

Re: borrow on all queues

[Bill Marquette]

On 4/7/06, Travis H. <[EMAIL PROTECTED]> wrote:
> Does putting borrow on all child queues make any sense?
>
> The way I read it, it does, so like a child queue that isn't using its
> bandwidth, can be borrowed by a sibling queue, is that correct?

That's how it appeared to work in my tests.

--Bill

pf+ftp-proxy / pf "company" example questions

[Michal Soltys]

Hello

I have two (unreleated) questions - the first one regarding new
ftp-proxy (the one using anchors) and the other regarding "company"
example in official obsd faq
(http://www.openbsd.org/faq/pf/queueing.html#example2) 

1)...

This is how I understand pf + ftp-proxy functionality:

First, two simple rules (one to pass traffic going from ftp-proxy, the
other to redirect the internal traffic to proxy) must be added - it's
all clear and they are provided as example at the bottom of the man
page: 


rdr pass on $int_if proto tcp from $lan to any port 21 -> \ 
127.0.0.1 port 8021 

pass out proto tcp from $proxy to any port 21 keep state


Now, in case of passive connections - ftp-proxy negotiates port to which
the client should connect, and installs 2 rules: 

- a snat rule, that rewrites internal address to proxy's one:

nat from $client to $server port $port -> $proxy

- and a filter rule to actually allow this connection leave the
firewall: 

pass out quick inet proto tcp \
   from $proxy to $server port $port flags S/SAFR keep state

And as far as I understand, that covers everything that should be done -
2 anchored rules (nat, filter) cover ftp data connection. Earlier
explicitely added rdr and filter rules cover initial control connection. 

So why is the following rule anchored as well :

pass in quick inet proto tcp \
   from $client to $server port $port flags S/SAFR keep state

I can't really find the situation during which it would be needed.
Especially that anchored nat rule (as nat/rdr are always executed before
filtering, as per faq and man pages) seems to make it never actually
happen. 

What do I miss ?


2)...

My second question concerns "company" example in pf queuing section. It
seems that this example completely ignores nat/rdr issues. Of course
it's stated at the beginning, that they were left intentionally, but
then let's consider two rules from the example: 

# filter rules for fxp0 outbound
pass out on fxp0 from $int_nets to any keep state
pass out on fxp0 from $boss to any keep state queue boss_ext

AFAIR, those two situations would have to be nated first - to
succesfully go public from fxp0, but then - according to faq - all
translations happen before the filter rules, so there would be no
$int_nets or $boss anymore - just firewall's external address. 

So what did I miss again here ?