From owner-freebsd-net Tue May 1 17:30:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 0EA8E37B423 for ; Tue, 1 May 2001 17:30:44 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id RAA08960; Tue, 1 May 2001 17:30:37 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAASaizr; Tue May 1 17:30:25 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA13986; Tue, 1 May 2001 17:42:43 -0700 (MST) From: Terry Lambert Message-Id: <200105020042.RAA13986@usr02.primenet.com> Subject: Re: The future of ALTQ, IPsec & IPFILTER playing together ... To: freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au Date: Wed, 2 May 2001 00:42:43 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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