From owner-freebsd-bugs Fri Apr 13 18:10:16 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 658BD37B505 for ; Fri, 13 Apr 2001 18:10:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f3E1A1u34034; Fri, 13 Apr 2001 18:10:01 -0700 (PDT) (envelope-from gnats) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 84D1037B440 for ; Fri, 13 Apr 2001 18:07:35 -0700 (PDT) (envelope-from nobody@FreeBSD.org) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f3E17ZH33920; Fri, 13 Apr 2001 18:07:35 -0700 (PDT) (envelope-from nobody) Message-Id: <200104140107.f3E17ZH33920@freefall.freebsd.org> Date: Fri, 13 Apr 2001 18:07:35 -0700 (PDT) From: gunther@aurora.regenstrief.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/26549: IPsec policies for more than one pair of SA do not work ... Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 26549 >Category: kern >Synopsis: IPsec policies for more than one pair of SA do not work ... >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 13 18:10:01 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Gunther Schadow >Release: >Organization: Regenstrief Institute >Environment: FreeBSD prometeus.regenstrief.org 4.2-RELEASE FreeBSD 4.2-RELEASE #0: Thu Apr 12 14:32:03 EST 2001 root@prometeus.regenstrief.org:/usr/NGI/KAME/kame/freebsd 4/sys/compile/PROMETEUS i386 >Description: I am trying to establish several IPsec ESP tunnels from one system. Each tunnel by itself works beautifully, but when I try using those tunnels all together, the kernel suddenly understands no incoming ESP message. The problem comes and goes with modifications in the SPD. If I delete all but one pair of SPD rules, the remaining tunnel works fine. As soon as I add a second pair of SPD rules the pair just added doesn't works. If I then delete the first pair, the pair just added suddenly works. I can go round robin with this and it is always the oldest pair that works and none of the others. This problem is critical for me as it puts my entire project into jeopardy. I will have to work around this in the next couple of days. >How-To-Repeat: 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 >Fix: Don't use IPsec :-( I will try reverting to gif tunnels with transport mode, hoping that it will work better. >Release-Note: >Audit-Trail: >Unformatted: >>>>>> 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 <