From owner-freebsd-net Tue May 1 9:13:19 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 4407B37B422 for ; Tue, 1 May 2001 09:13:15 -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 f41GI3X25098; Tue, 1 May 2001 11:18:03 -0500 Message-ID: <3AEEE08D.DBF7BD5C@aurora.regenstrief.org> Date: Tue, 01 May 2001 16:13:01 +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: snap-users@kame.net Cc: Shoichi Sakane , freebsd-net@freebsd.org, itojun@iijlab.net Subject: Re: (KAME-snap 4571) Re: KAME SPD bug, please try and confirm ... References: <20857.988675568@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org itojun@iijlab.net wrote: > my guess is that you have some issue with routing setup. > last time, you had some wacky static routes to help source address > selection (i do not really recommend that). do you still have them? > if so, please show them to us (to mailing list) with in the script. No, I don't think so. My routing tables are just fine, I see with tcpdump how packets are exchanged as they should and I see them come in the receiving interface and I see them being dropped an counted under "unknown/unsupported protocol." So, how can you conclude that it's my routing tables? How should my routing tables be different? The point is that the *only* place where I make changes to get tunnels working and not working is the SPD: I *delete* some SPD rules and that makes other rules work suddenly, I add the old rules in and they won't work. I delete the other rules and the old ones will work again. I am absolutely certain that the SPD rules engine is buggy. > >Since my project is in jeopardy because of this bug, I have > >now engaged plan B, which is to use IPsec in transport mode > >and one gif tunnel connecting each sattelite with the home > you are encapsulating twice with the "gif and IPsec tunnel mode" > setup, and the setup won't interoperate with other box. Well, I don't know what to say. If you can confirm to me that I am the lonly stupid nitwit here who does all kinds of wacky things, I would shut up. But so far I have not seen proof for a complex VPN setup with KAME that does work. I am sort of desperate here, trying to give as much detail as possible that will allow reproducing the problem but this all doesn't seem to get through. If I am doing things wrong, please advise how to do them right, or refer me to the documentation that does tell this (of course I read the KAME "newsletter", setkey man page and much other stuff, including several VPN HOWTO documents that *ALL* use the gif-tunnel hack!) 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. Also, if you intend to track down the problem, let me know and I can send a cleaned up set of test scripts again. I don't know what experience others have but I am trying to uphold the honor of open source computing and networking infrastructure like FreeBSD and KAME in my institution. As much as I praise all this to the outside and as much as I tell my people that "it's basically working with only minor problems", I am getting in a more and more difficult position if I can't make it work because of a bug/problem that's not being taken seriously. thank you for producing and taking care of KAME, I'm looking forward to a bright future, peace -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