NetBSD Problem Report #42592

From  Fri Jan  8 14:03:13 2010
Return-Path: <>
Received: from ( [])
	by (Postfix) with ESMTP id 6E1F863C504
	for <>; Fri,  8 Jan 2010 14:03:13 +0000 (UTC)
Message-Id: <>
Date: Fri,  8 Jan 2010 14:03:13 +0000 (UTC)
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
>Last-Modified:  Thu Aug 16 21:04:50 +0000 2012
>Originator:     Daniel Zebralla
>Release:        NetBSD-5.0-release
A.P.E. GmbH
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/ i386

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].


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.
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.


From: "S.P.Zeidler" <>
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
    and was not zeroing out the port information in the non-nat-traversal
    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

 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-When: Sun, 26 Sep 2010 23:07:37 +0000
Did the commit help?

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

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

State-Changed-From-To: closed->open
State-Changed-When: Thu, 16 Aug 2012 21:04:50 +0000
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.


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.