Date: Tue, 01 May 2001 20:43:51 +0000 From: Gunther Schadow <gunther@aurora.regenstrief.org> To: Lars Eggert <larse@ISI.EDU> 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 ... Message-ID: <3AEF2007.5968E10D@aurora.regenstrief.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AEF2007.5968E10D>