NetBSD Problem Report #42592

From www@NetBSD.org  Fri Jan  8 14:03:13 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 6E1F863C504
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  8 Jan 2010 14:03:13 +0000 (UTC)
Message-Id: <20100108140313.32FE663C503@www.NetBSD.org>
Date: Fri,  8 Jan 2010 14:03:13 +0000 (UTC)
From: d.zebralla@ape-net.com
Reply-To: d.zebralla@ape-net.com
To: gnats-bugs@NetBSD.org
Subject: PFkey interface causing problems with recent racoon
X-Send-Pr-Version: www-1.0

>Number:         42592
>Category:       kern
>Synopsis:       PFkey interface causing problems with recent racoon
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jnemeth
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 08 14:05:00 +0000 2010
>Closed-Date:    
>Last-Modified:  Thu Aug 16 21:04:50 +0000 2012
>Originator:     Daniel Zebralla
>Release:        NetBSD-5.0-release
>Organization:
A.P.E. GmbH
>Environment:
NetBSD GW-B 5.0_STABLE NetBSD 5.0_STABLE (GW-B) #11: Mon Jan  4 11:50:37 CET 2010  zebralla@sirrug:/home/zebralla/GW-B/obj.build/sys/arch/i386/compile/GW_B_NB5 i386

>Description:
We've tried to work with racoon-current (as from 2009-12-14) in combination with NetBSD-5.0-release Kernel and encountered problems in establishing an IPsec-connection in tunnel mode between two GWs (both with racoon-current and NetBSD-5.0-release Kernel). 

When the initiator (GW-A) tried to establish an IPsec-tunnel, racoon on the responder-side (GW-B) stated that both, Phase1 (ISAKMP-SAs) and Phase2 (IPsec-SAs) were established successfully, and the resulting SAD- and SPD-entries looked like expected. However, trying to ping a machine inside GW-B's LAN out of GW-A's LAN, we saw that racoon on GW-B always stated "initiate new Phase2 negotiation ..." and that new Phase2-SAs for the same connection were established. This behavior repeated itself every ~20 seconds without a established tunnel being ever usable.

We saw a mailing list entry by Brett Lymn on ipsec-tools-devel stating the same issue but with NetBSD-current and racoon-current as of July 2009 and a slightly different config (Checkpoint FW-1 FW as initiator instead of NetBSD/racoon and NAT-T activated) [1]. 
Judging by Yvans' reply, the problem seems to be inside the kernels PFkey-interface [2] and also affects NetBSD-current: apparently racoon was changed to require some changes in the PFkey interface.
While this change was made on Linux and FreeBSD, it was never done on NetBSD.

In effect, NetBSD-current's raccoon is probably non-working today due to the lack of this PFkey change.

Even a PR (#41757) was opened back then which is still open [3].

We've also posted this issue onto tech-net mailing list recently [4].

[1] http://sourceforge.net/mailarchive/message.php?msg_id=20090725215420.GA3745%40internode.on.net
[2] http://sourceforge.net/mailarchive/message.php?msg_name=20090729195853.GA5366%40zeninc.net
[3] http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=41757
[4] http://mail-index.netbsd.org/tech-net/2009/12/18/msg001803.html

>How-To-Repeat:
Use NetBSD-5.0-release kernel and racoon-current (as from 2009-12-14) on two GWs and let them establish an IPSec-connection in tunnel mode.
>Fix:
The problem can be worked around by using racoon from NetBSD-5.0-release but the newer racoon features that we wanted to use (having dedicated remote sections In racoon.conf for separate peers identified by something different than the peers' IP addresses) are not available there.

>Release-Note:

>Audit-Trail:
From: "S.P.Zeidler" <spz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42592 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:07:37 +0000
State-Changed-Why:
Did the commit help?


State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 13 Aug 2012 20:44:19 +0000
State-Changed-Why:
in feedback for almost two years + feedback mail has started bouncing.
presume fixed.


Responsible-Changed-From-To: kern-bug-people->jnemeth
Responsible-Changed-By: jnemeth@NetBSD.org
Responsible-Changed-When: Thu, 16 Aug 2012 21:04:50 +0000
Responsible-Changed-Why:
Assign to myself to remind me to test this and fix it if necessary.


State-Changed-From-To: closed->open
State-Changed-By: jnemeth@NetBSD.org
State-Changed-When: Thu, 16 Aug 2012 21:04:50 +0000
State-Changed-Why:
Something in the back of my mind is telling me that this hasn't been fixed.
I'll have to do a build for my test machine.


>Unformatted:

Home	PR Database Search