Date: Tue, 01 May 2001 09:50:34 -0700 From: Lars Eggert <larse@ISI.EDU> To: Gunther Schadow <gunther@aurora.regenstrief.org> Cc: snap-users@kame.net, Shoichi Sakane <sakane@ydc.co.jp>, freebsd-net@freebsd.org, itojun@iijlab.net Subject: Re: (KAME-snap 4571) Re: KAME SPD bug, please try and confirm ... Message-ID: <3AEEE95A.9ED98368@isi.edu> References: <20857.988675568@itojun.org> <3AEEE08D.DBF7BD5C@aurora.regenstrief.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Gunther Schadow wrote: > I would shut up. But so far I have not seen proof for a complex > VPN setup with KAME that does work. We use our X-Bone software (http://www.isi.edu/xbone/) to frequently create and remove complex overlays (tens of nodes in various topologies) with dynamic routing and IPsec. It can be done with KAME, but it is tricky. > If anyone on this list has successfully set up a VPN with multiple > remote sites, please contact me so I can ask you questions about > how you've done it. I promise to write a HOWTO as soon as I could > make it work. But so far, multiple IPsec tunnels to subnets just > don't work together well. The trick is to use IPsec transport mode + IPIP tunnels (gif devices) *or* IPsec tunnel mode. If you start to mix them, you get into all kinds of grey areas, where things depend on the order of instantiation, for example. For simple VPNs, IPsec tunnel mode is easiest. Its main shortcoming (in the current state of implementation) is that IPsec tunnels are not represented in or synchronized with the routing table - i.e. they are invisible to routing. Some people use gif tunnels to force routing to route packets into an IPsec tunnel. This is a bad hack IMO, since you basically create a duplicate (non-IPsec) tunnel between to endpoints, which as a side-effect adds a routing table entry. Packets for that route get intercepted and IPsec'ed, and never really go over the gif tunnel. The IMO cleaner approach is to use IPsec transport mode on a gif tunnel. All tunneling is handled by the gif device, and IPsec is completely optional (i.e. you can set up the gif tunnels without any IPsec first, and add transport mode SAs later once your VPN gif tunnel topology works). There's an ID with more details: ftp://ftp.isi.edu/internet-drafts/draft-touch-ipsec-vpn-01.txt Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California [-- Attachment #2 --] 0# *H 01 0 + 0 *H 00A#0 *H 01 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.160 000824203008Z 010824203008Z0T10 UEggert1 0 U*Lars10U Lars Eggert1 0 *H larse@isi.edu00 *H 0 \p9 H;v r∩6"C?mxfJ f7I[3CF́L I - zHRVA怤2]0-bL)%X>nӅ w0u0*+e!0 00L2uMyffBNUbNJJcdZ2s0U 0 larse@isi.edu0 U 0 0 U #0`fUXF a#Ì0 *H _3 F=%nWY-HXD9UOc6ܰw f@uܶNԄR?Pr} E1֮23 mFhySwM_h|d yR= $P 00} 0 *H 01 0 UZA10U Western Cape10U Cape Town10U Thawte Consulting1(0&U Certification Services Division1$0"UThawte Personal Freemail CA1+0) *H personal-freemail@thawte.com0 990916140140Z 010915140140Z01 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.1600 *H 0 iZ z]!#rLK~r$BRW{azr98e^eyvL>hpu t ,O 1ArƦ]D.Mօ>lx~@эWs0FO 7050U 0 0 U #0rIs4U vr~wƲ0 *H kY1rr`HU{gapm¥7؝(V\uoƑlfq|ko!6- -mƃRt\~ orzg,ks n Νc) ~U10001 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.16#0 + 0 *H 1 *H 0 *H 1 010501165034Z0# *H 1Tj*]Ws7UAbȌ0R *H 1E0C0 *H 0*H 0+0 *H @0 *H (0 *H 5 =8 T%?{ԣ&K֎+ eB֗uW_qnꝙD )@>F!1}y; #-~ iXDz"a<̶ח|rآo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AEEE95A.9ED98368>