NetBSD Problem Report #41757

From blymn@siren.localdomain  Tue Jul 21 08:14:07 2009
Return-Path: <blymn@siren.localdomain>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id CDA2063B898
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 21 Jul 2009 08:14:07 +0000 (UTC)
Message-Id: <20090720230810.4F23C21202BF@siren.localdomain>
Date: Mon, 20 Jul 2009 23:08:10 +0000 (UTC)
From: blymn@internode.on.net
Reply-To: blymn@internode.on.net
To: gnats-bugs@gnats.NetBSD.org
Subject: racoon in recent -current fails to establish tunnel
X-Send-Pr-Version: 3.95

>Number:         41757
>Category:       bin
>Synopsis:       recent racoon fails to correctly establish tunnel
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 21 08:15:00 +0000 2009
>Closed-Date:    Mon Dec 06 06:54:35 +0000 2010
>Last-Modified:  Mon Dec 06 06:54:35 +0000 2010
>Originator:     blymn@internode.on.net
>Release:        NetBSD 5.99.15 cvs update 18/7/09
>Organization:
Brett Lymn
>Environment:
System: NetBSD siren 5.99.15 NetBSD 5.99.15 (SIREN.ACPI.MP) #12: Sun Jul 19 19:44:40 UTC 2009 toor@siren:/usr/src/sys/arch/amd64/compile/SIREN.ACPI.MP amd64
Architecture: x86_64
Machine: amd64
>Description:
	I have a permanent vpn connection configured from a NetBSD machine
to a Checkpoint FW-1 firewall.  With a racoon binary circa june 2007 the
tunnel comes up fine and I can vpn without problems.  With the racoon from
netbsd-current circa 18/7/09 racoon just seems to keep negotiating phase 2
and not actually bring the tunnel up even though it says it succeeded:

Jul 19 19:50:53 siren racoon: INFO: IPsec-SA request for 10.10.10.10 queued due
 to no phase1 found. 
Jul 19 19:50:53 siren racoon: INFO: initiate new phase 1 negotiation: 192.168.3.
1[500]<=>10.10.10.10[500] 
Jul 19 19:50:53 siren racoon: INFO: begin Identity Protection mode. 
Jul 19 19:50:53 siren racoon: INFO: ISAKMP-SA established 192.168.3.1[500]-10.10.10.10[500] spi:f2ad2cff4c5be202:bc55f175ec793b2d 
Jul 19 19:50:54 siren racoon: INFO: initiate new phase 2 negotiation: 192.168.3.
1[500]<=>10.10.10.10[500] 
Jul 19 19:50:54 siren racoon: INFO: IPsec-SA established: ESP/Tunnel 192.168.3.1
[500]->10.10.10.10[500] spi=139984226(0x857fd62) 
Jul 19 19:50:54 siren racoon: INFO: IPsec-SA established: ESP/Tunnel 192.168.3.1
[500]->10.10.10.10[500] spi=2727670883(0xa294f463) 
Jul 19 19:52:16 siren racoon: INFO: initiate new phase 2 negotiation: 192.168.3.
1[500]<=>10.10.10.10[500] 
Jul 19 19:52:16 siren racoon: INFO: IPsec-SA established: ESP/Tunnel 192.168.3.1
[500]->10.10.10.10[500] spi=204092163(0xc2a3303) 
Jul 19 19:52:16 siren racoon: INFO: IPsec-SA established: ESP/Tunnel 192.168.3.1
[500]->10.10.10.10[500] spi=1960358005(0x74d8b075) 

it seems like the negotiation happened for each packet.  Using setkey -D and
setkey -DP I could see valid SA's in the list and the SPD's looked correct
but no traffic went over the tunnel.

I was able to get the tunnel working again by recovering the /usr/sbin/racoon
binary from a backup taken prior to the upgrade of the machine. The machine
is still running netbsd-current, only the racoon binary has been replace with
one known to work for me.

>How-To-Repeat:
	Get racoon to negotiate a tunnel to a checkpoint fw-1 firewall.
>Fix:
	The problem can be worked around by using an old racoon binary.

>Release-Note:

>Audit-Trail:
From: "S.P.Zeidler" <spz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41757 CVS commit: src/sys
Date: Sun, 5 Sep 2010 06:52:54 +0000

 Module Name:	src
 Committed By:	spz
 Date:		Sun Sep  5 06:52:54 UTC 2010

 Modified Files:
 	src/sys/net: pfkeyv2.h
 	src/sys/netipsec: key.c
 	src/sys/netkey: key.c

 Log Message:
 fix two bugs in the PFKEY interface:

 1) RFC2367 says in 2.3.3 Address Extension: "All non-address
    information in the sockaddrs, such as sin_zero for AF_INET sockaddrs,
    and sin6_flowinfo for AF_INET6 sockaddrs, MUST be zeroed out."
    the IPSEC_NAT_T code was expecting the port information it needs
    to be conveyed in the sockaddr instead of exclusively by
    SADB_X_EXT_NAT_T_SPORT and SADB_X_EXT_NAT_T_DPORT,
    and was not zeroing out the port information in the non-nat-traversal
    case.
    Since it was expecting the port information to reside in the sockaddr
    it could get away with (re)setting the ports after starting to use them.
    -> Set the natt ports before setting the SA mature.

 2) RFC3947 has two Original Address fields, initiator and responder,
    so we need SADB_X_EXT_NAT_T_OAI and SADB_X_EXT_NAT_T_OAR and not just
    SADB_X_EXT_NAT_T_OA

 The change has been created using vanhu's patch for FreeBSD as reference.

 Note that establishing actual nat-t sessions has not yet been tested.

 Likely fixes the following:
 PR bin/41757
 PR net/42592
 PR net/42606


 To generate a diff of this commit:
 cvs rdiff -u -r1.26 -r1.27 src/sys/net/pfkeyv2.h
 cvs rdiff -u -r1.63 -r1.64 src/sys/netipsec/key.c
 cvs rdiff -u -r1.177 -r1.178 src/sys/netkey/key.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 26 Sep 2010 23:05:25 +0000
State-Changed-Why:
Did that fix it?


From: Brett Lymn <blymn@internode.on.net>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, dholland@NetBSD.org
Subject: Re: bin/41757 (recent racoon fails to correctly establish tunnel)
Date: Sun, 5 Dec 2010 19:44:12 +1030

 On Sun, Sep 26, 2010 at 11:05:27PM +0000, dholland@NetBSD.org wrote:
 >
 > Did that fix it?
 > 

 Unfortunately, I can no longer test this - work shut down the VPN
 concentrator I was using.  Unless someone else can test I guess we will
 just have to assume it is fixed until further notice.

 -- 
 Brett Lymn

State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 06 Dec 2010 06:54:35 +0000
State-Changed-Why:
cannot test, assume fixed.


>Unformatted:

Home	PR Database Search