ALTQ on incoming interface

Sometimes there is really need for ALTQ on incoming traffic:

--------
| SRV1 |
| ftp |
--------
|
| ------------ ------------
+------| |$ext_if | |
$int_if| BSD1 box |---IP sec only---| BSD2 box |----Clients
+------| | | |
| ------------ ------------
|
--------
| SRV2 |
| smtp |
--------

Example:
If ftp traffic to the client is large, then smtp traffic
will be blocked. There is obviously need to queue the
traffic in some a way. (All SRV, BSD and clients
are in company, they are not "strange" internet machines).

ALTQ on enc0 is not possible (it is well known).
There is problem on queue on $ext_if (it is only IP sec traffic).

Is there any Idea/Solution how to solve this?


My Idea is as follows: Use route-to loopback interface
on incoming traffic to internal interface.
Then apply queue on outgoing traffic from lo0.

Part of /etc/pf.conf is something like:

pass in on $int_if route-to lo0
pass out quick on lo0 from $SRV1 to any queue ftpque
pass out quick on lo0 from $DRV2 to any queue smtpque
pass out on lo0 all

Is it reasonable? Any comment will be appreciated.

Igor

Hi,

On Thu, 23 Nov 2006 11:48:34 +0100, igy
wrote:

> Sometimes there is really need for ALTQ on incoming traffic:

ALTQ on incoming traffic won't work -- obviously.

> If ftp traffic to the client is large, then smtp traffic
> will be blocked. There is obviously need to queue the
> traffic in some a way. (All SRV, BSD and clients
> are in company, they are not "strange" internet machines).
>
> ALTQ on enc0 is not possible (it is well known).
> There is problem on queue on $ext_if (it is only IP sec traffic).

I've had the very same problem a while ago (need to priorize VoIP traffic
accross my well saturated VPN connection) and tried a lot of things to no
avail.

Suprisingly, tags (as in the pf "tag" statement) survive IPSEC encryption.
I've done something like this:

# define queues
altq on $dsl_if priq bandwidth 384Kb queue { STD, TCPACK, UDP }
queue STD priority 0 priq(default)
queue UDP priority 14
queue TCPACK priority 15

# sort tagged packets to queues
pass out quick proto esp tagged TCPACK queue TCPACK keep state
pass out quick proto esp tagged UDP queue UDP keep state

# tag packets
pass in from { , } to keep state
pass in proto tcp from { , } to flags A/A tag TCPACK
keep state
pass in proto udp from { , } to tag UDP keep state

It actually works. If I don't tag the packets I've got a pretty much
stuttering VoIP connection, if I do everything's clear.

YMMV, however.

Regards, Danilo

Danilo Kempf wrote:
>
>> Sometimes there is really need for ALTQ on incoming traffic:
>
> ALTQ on incoming traffic won't work -- obviously.

It works when pf (and ALTQ) is running in the other side of the communication
channel. :-)

Someone should be able to implement some ALTQ-like traffic control for
incoming traffic selectively dropping packages to simulate network
congestion but it will be certainly ugly -and I will certainly never
recommend something like that to be implemented!- and rulesets will become
a nightmare (what machines should be added? the end points of the
communication channels -local machines-)?. ;-)

> I've had the very same problem a while ago (need to priorize VoIP traffic
> accross my well saturated VPN connection) and tried a lot of things to no
> avail.
>
> Suprisingly, tags (as in the pf "tag" statement) survive IPSEC encryption.
> I've done something like this:

Is packet tagging done before or after encryption? If it is done before
encryption and traffic is decrypted before tags are analyzed on the
other end, it should work, though.

Igor.