kern/42606: Netbsd-5 racoon: Multiple Phase2 SAs generated when NAT-T enabled

[d.zebralla%ape-net.com@localhost]

>Number:         42606
>Category:       kern
>Synopsis:       Netbsd-5 racoon: Multiple Phase2 SAs generated when NAT-T 
>enabled
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 11 14:45:00 +0000 2010
>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.