NetBSD Problem Report #42606
From www@NetBSD.org Mon Jan 11 14:43:22 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 0751763C503
for <gnats-bugs@gnats.NetBSD.org>; Mon, 11 Jan 2010 14:43:22 +0000 (UTC)
Message-Id: <20100111144321.99DEC63B844@www.NetBSD.org>
Date: Mon, 11 Jan 2010 14:43:21 +0000 (UTC)
From: d.zebralla@ape-net.com
Reply-To: d.zebralla@ape-net.com
To: gnats-bugs@NetBSD.org
Subject: Netbsd-5 racoon: Multiple Phase2 SAs generated when NAT-T enabled
X-Send-Pr-Version: www-1.0
>Number: 42606
>Category: kern
>Synopsis: Netbsd-5 racoon: Multiple Phase2 SAs generated when NAT-T enabled
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: jnemeth
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Jan 11 14:45:00 +0000 2010
>Closed-Date:
>Last-Modified: Sun Sep 23 19:15:03 +0000 2012
>Originator: Daniel Zebralla
>Release: NetBSD-5.0-release
>Organization:
A.P.E. GmbH
>Environment:
NetBSD GW-A 5.0_STABLE NetBSD 5.0_STABLE (GW-A_NB5) #11: Mon Jan 4 11:50:37 CET 2010
zebralla@sirrug:/home/zebralla/GW-A/obj.build/sys/arch/i386/compile/GW_A_NB5 i386
>Description:
We tried to establish an IPsec-connection in tunnel-mode using two
netbsd-5 branch machines as gateways and racoon set for two scenarios:
Scenario 1: GWs directly connected via cross-link-cable, NAT-T forced
on in both racoons (option "nat_traversal force;")
Scenario 2: NAT-Box in between doing source-NAT on initiators' IP, NAT-T
set to on in both racoons (option "nat_traversal on;")
Before, we used IPsec in aggressive mode without NAT-T. It works without problems.
As such, we think that NAT-T has a problem.
In both scenarios, when pings are sent from initiators' LAN to
responders' LAN, Phase1 (ISAKMP) is completed successfully, but Phase2
(IPsec) is "looping". This means that after a timeout, a (additional)
pair of Phase2-SAs is generated. The tunnel itself never gets usable for
data traffic.
This is also what we see with a more recent racoon (from NetBSD-
current) and without NAT-T, see PR kern/42592.
For config-files and some debug output please see the posting at ipsec-
tools-devel mailing list [1].
[1]
http://sourceforge.net/mailarchive/message.php?msg_name=83DEBFABE007144FB16E7C68C6E2E1FD164EC15A0D%40ape-server11.ape-net.local
>How-To-Repeat:
Use two netbsd-5 branch-systems for building an IPsec-connection in
tunnel-mode. One system is the passive responder, the other the active
initiator.
Scenario 1:
Connect both systems via cross-link. Force NAT-T on in racoon and use
aggressive-mode.
Scenario 2:
Connect both systems with a NAT-device in between, applying source-NAT
on initiators' IP. Set NAT-T to on in racoon and use aggressive-mode.
See our racoon.conf- and ipsec.conf-files at [1].
>Fix:
No fix found, instead of not using NAT-T.
>Release-Note:
>Audit-Trail:
From: "S.P.Zeidler" <spz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/42606 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:08:05 +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:53 +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:10:01 +0000
Responsible-Changed-Why:
Assign to myself to remind me to test this.
State-Changed-From-To: closed->open
State-Changed-By: jnemeth@NetBSD.org
State-Changed-When: Thu, 16 Aug 2012 21:10:01 +0000
State-Changed-Why:
Something in the back of my mind is telling me it hasn't been fixed.
From: jnemeth@victoria.tc.ca (John Nemeth)
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/42606
Date: Tue, 21 Aug 2012 23:33:27 -0700
I tested NAT-T with a NetBSD-current built yesterday against a
Cisco router. I can confirm that NAT-T still doesn't function.
From: Chuck Zmudzinski <brchuckz@netscape.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/42606
Date: Sun, 23 Sep 2012 14:11:16 -0500
I did some tests today by forcing nat-t on a direct connection between
two netbsd 5.0.2 virtual machines. First, I verified both tunnel mode
and transport mode worked without nat-t, and then when I tried to do
nat-t on transport mode, it worked fine and did not generate multiple
SA's and I got a useful connection. It was only when I tried nat-t in
tunnel mode that I saw this problem of multiple phase 2 SAs.
Chuck Zmudzinski (an occasional NetBSD user)
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.