Date: Wed, 2 May 2001 00:42:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au Subject: Re: The future of ALTQ, IPsec & IPFILTER playing together ... Message-ID: <200105020042.RAA13986@usr02.primenet.com>
next in thread | raw e-mail | index | archive | help
You wrote:
] O.K. I've investigated some more tunneling options based on
] my reading that ALTQ supports the tun0 device. Here is what
] I came up with so far:
]
] 0) KAME IPsec tunnel mode: +STANDARD, +KAME, -ALTQ based on TOS only,
] -doesn't work for me yet, +Cisco interoperable (at least if
] I also use IKE/racoon.)
...
I guess your problem is that you want to use the QOS features
of ALTQ, but you can't do that because your payload is already
opaque, so you can't recover the information?
I suggest you tunnel the packets, like so:
Magic application
| ,--------------.
| | ,-. ...> ,-. |
| | | | | | |
| | | | | | |
| `-|-|------|-|-'
v | | | |
| | | | |
`---()----' `--()--' `-----()----> (kernel chunks)
If you transit the same application twice with the data, and the
chunk in the middle is IPSEC, and the chunk on the end is ALTQ,
then the arrow ...> can represent you peeking at the QOS information
in the unencrypted data, tunneling it so that it can be applied to
the encrypted data, before being haded to the chunk on the right
(ALTQ).
You can get away with this because your application sees the packets
twice, and can connect the requested QOS with the one you yourself
request.
This is a pretty gross hack, but it would probably let you string
the pieces you want together, using the tunneling info elsewhere
in this thread... good luck.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105020042.RAA13986>