From owner-freebsd-net Tue May 1 13:44: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from rgmail.regenstrief.org (rgmail.regenstrief.org [134.68.31.197]) by hub.freebsd.org (Postfix) with ESMTP id C334A37B422 for ; Tue, 1 May 2001 13:44:04 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org (rgnout.regenstrief.org [134.68.31.38]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f41KmwX28592; Tue, 1 May 2001 15:48:58 -0500 Message-ID: <3AEF2007.5968E10D@aurora.regenstrief.org> Date: Tue, 01 May 2001 20:43:51 +0000 From: Gunther Schadow Organization: Regenstrief Institute for Health Care X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Eggert Cc: snap-users@kame.net, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp Subject: Re: The future of ALTQ, IPsec & IPFILTER playing together ... References: <3AEEEE79.8F7CC7B0@aurora.regenstrief.org> <3AEEF26B.C6850070@isi.edu> <3AEEF59D.3D5622DE@aurora.regenstrief.org> <3AEEFA06.BA0EB9FD@isi.edu> <3AEF0452.C2FD2651@aurora.regenstrief.org> <3AEF09BF.9F9A7BAB@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Lars Eggert wrote: > > Another unknown to me is whether the GIF tunnel will copy > > the TOS bits into the wrapper, and so, I can't use ALTQ at all. > > If it does not currently, this, at least, should be simple to add. 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.) 1) gif: +STANDARD (RFC 1933), +KAME, -noALTQ, +does work for me, +use KAME IPsec transport mode, ?Cisco interoperable. 2) gre-tun: +STANDARD (RFC 1702), +ALTQable (tun), +use KAME IPsec transport mode, +very simple, +Cisco interoperable. 3) ip-tun: +STANDARD (RFC 2003), -ALTQable (but use IPFW so I can use DUMMYNET), +use KAME IPsec transport mode. 4) pipsecd: +STANDARD (IPsec tunnel mode!), does NOT use KAME (which is bad for loyalty to the KAME folks, but good for simplicity), +ALTQable (tun) 5) vtun - -noSTANDARD, +ALTQable (tun), -non-standard encryption stuff built in, -rather complex 6) L2TP - +STANDARD, +ALTQable (tun/ppp), -unmaintained alpha source, -not simple, +good for non-configured (dynamic) tunnels, -risk of this using TCP which adds latency and is useless for my videoconferencing application. My objective is to stick with KAME as good as it gets. Eventually I would like to return to alternative number 0. I anticipate that KAME will eventually play best with IPFILTER, so I try to stick with IPFILTER if I can make ALTQ work. With gif I can't get ALTQ to work. So, my choice is gre-tun for now. SATELLITE HEADQUARTER | ALTQ | tun0 tunN | | tap0-gre-tun------fxp0 ... fxp0-------gre-tun-tapN +-IPSEC ESP transport-+ As an added benefit, the two network interfaces tun0 and fxp0 allow me to cope with the limited power of IPFILTER's NAT rules (as compared to IPFW). If everything goes well, I should be all set by tomorrow. But I do appreciate any comments on the above listed packages. Lars, what was your rationale for inventing the ip-tun package? Did you have good or bad experience with any of those alternatives? Are there other promising alternatives? regards -Gunther -- Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistent Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message