From owner-freebsd-net Fri Apr 13 18:16:32 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 B639937B449 for ; Fri, 13 Apr 2001 18:16:21 -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 f3E1HcA31813; Fri, 13 Apr 2001 20:17:39 -0500 Message-ID: <3AD7A4E0.B29B1100@aurora.regenstrief.org> Date: Sat, 14 Apr 2001 01:16:16 +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, freebsd-net@freebsd.org Subject: Can someone confirm this problem ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, below is what could be a cookbook recipe for IPsec tunnels. However, unfortunately it's a bug report. I would like some of you to try this out and confirm the problem for me, may be find the error on my part, or make suggestions on how to work around this problem. If you have an older KAME release, you may not see this bug instantaneously, instead you will notice a kernel panic when running the network for some time under higher load (~ 2 Mb/s). On KAME-SNAP as of last March no kernel panic occurs but this problem can be seen instantaneously. Here is how it goes: You need three machines A and B, and C. We begin with A and B: On machine A run: if=ed0 aip=10.10.10.1 bip=10.10.10.2 aipsec=10.99.10 bipsec=10.99.20 ifconfig ${if} inet alias ${aip} netmask 0xffffff00 ifconfig lo0 inet alias ${aipsec}.1 netmask 0xffffff00 route add -net ${bipsec}.0/24 ${aipsec}.1 setkey -c < 10.10.10.3: ESP(spi=2000,seq=0x14) 19:51:30.945915 10.10.10.3 > 10.10.10.1: ESP(spi=2001,seq=0x24) 19:51:31.953169 10.10.10.1 > 10.10.10.3: ESP(spi=2000,seq=0x15) 19:51:31.953300 10.10.10.3 > 10.10.10.1: ESP(spi=2001,seq=0x25) as it should, and remember, the C-tunnel works now. Let's go to B and ping ${aipsec}.1 tcpdump shows: 19:55:21.963950 10.10.10.2 > 10.10.10.1: ESP(spi=1001,seq=0x42) 19:55:22.975435 10.10.10.2 > 10.10.10.1: ESP(spi=1001,seq=0x43) see how A never sends an icmp echo reply? It is because it never gets the icmp messages to the upper layer. Instead netstat -s -p ip ip: 2313 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 2033 packets for this host >>>>>> 267 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 13 packets received for unknown multicast group 0 redirects sent 1374 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header As you see, the unknown/unsupported protocol counter goes up with every icmp request sent. But, the "packets for this host" counter doen not go up. This means, the packets are not even seen as belonging to this host!!! Now let's turn this around once again. Disabling SPD entries for C and you'll see how B comes back on line: setkey -c <