Re: packet filter : official documentation not enought, questions remain

From: Marco S Hyman (marc_at_snafu.org)
Date: 11/22/04 

Date: 22 Nov 2004 13:03:06 -0800

Guillaume Kaddouch <gkweb@wanadoo.fr> writes:

> that I understand as the NAT implicitly doing a "keep state", but I am not
> sure about what the end of the sentence "as long as the connection is passed
> by the filter ruleset" means, if someone can explain me.

pf first does nat, then does filtering. It's two separate steps that
happen to be controlled by the same config file. Just because a packet
has been natted does not mean that it will not be dropped by the filtering
rules. Example:

 nat on $pub_if from $priv_ip to any -> ($pub_if)
 ...
 block drop in quick inet from $nasty to any

Let's say 1.2.3.4 is in my nasty list. If a packet comes from 1.2.3.4
destined to an address that has been natted, it will be dropped according
to the above rules.

> However I have a problem to know which value I need to set for the root
> queue, between the modem speed of 65Kb of download or the LAN card of 100Mb
> ? Does it change anything ? Does I have to do the "altq" on the external
> interface or on the lan interface of the gateway ?

I don't claim to be an expert on queuing, but the following seems to
work for me... I'm sure if I state something in error someone will jump
in and correct me...

First queue set up. qint is for internal traffic (100 mbit/s), qext is
for external traffic going out my dsl which is limited to 512 kbit/s outgoing.

 altq on $pub_if cbq queue { qint qext }
 queue qint bandwidth 99% priority 2 cbq(default, borrow)
 queue qext bandwidth 512Kb priority 1 cbq(ecn)

In my output rules I use one of the two queues;

 pass out all keep state queue (qext, qint)
 pass out to <pubaddr> keep state queue qint

The first rule assumes that everything is going to an external address
and assigns it to qext. The second rule overrides the first rule
for my local addresses (in a table called pubaddr) using qint. This
gives traffic on the local ethernet full bandwidth.

For the input side I have rules such as

  pass in proto tcp to <pubaddr> port www flags S/SA keep state queue qext

which says that *response* packets will use qext. See below...

> (let's say I want to give priority to inbound UDP packets coming from remote
> port 10 000 and to destination of my IP).

Common misconception. You have NO control over inbound packets. All
altq can do is control outbound packets. The in/out in the rules describes
who initiated the communication, not the direction of the packets.

// marc

Relevant Pages

  • Re: Possible bug in .Net 2.0 udp sockets?
    ... You won't miss any UDP packets with a buffer that large! ... R> I called BeginReceiveFrom() several times on purpose, ... If you don't do that, indeed, UDP stack can drop packets. ... it stores it in the queue. ...
    (microsoft.public.dotnet.framework)
  • Re: Performance Intel Pro 1000 MT (PWLA8490MT)
    ... driver changed to not use the braindamaged sk interrupt moderation. ... with small 50-60 byte UDP packets. ... when the tx queue fills up, the application should stop sending, at ... For transmission, with non-broken hardware and software, ...
    (freebsd-performance)
  • Re: [PATCH] 3/3 maple: update bus driver to support Dreamcast VMU
    ... Removes unneeded locking of queue of processed packets while properly ... Under what conditions will this lock be ...
    (Linux-Kernel)
  • Re: ipfw and ipsec processing order for outgoing packets wrong
    ... non-ACK packets but the other counters for queue 2-4 doesn't move at ... ipfw pipe show and ipfw queue show would seem normal except the Source ... >> for outgoing queues with the ACK packets having the highest priority ... > - in the very beginning, a packet that was processed by ipsec didn't ...
    (freebsd-current)