I doubt you need to upgrade NetBSD to resolve the problem.... typically 
racoon.conf just needs to be changed to accomodate the quirks of each 
IPSec implementation.

Nothing worthwhile is being logged on the NetBSD box because you've only 
got logging set to "notify".  Set this to "debug" at a minimum and 
"debug2" if that still doesn't reveal the problem.  Also, you may have 
to figure out how to enable IPSec debugging on the peer(s).

It sounds like the rekey is the part that's failing.  Try setting 
"proposal_check obey;" in racoon.conf.  Since you don't have it 
specified in racoon.conf, it defaults to "strict".  Do you have the same 
problem no matter which peer initiates the tunnel?

> RACOON.CONF(5)            NetBSD Programmer's Manual            
> RACOON.CONF(5)


>              proposal_check level;
>                      specifies the action of lifetime length and PFS 
> of the
>                      phase 2 selection on the responder side.  The default
>                      level is strict.  If the level is;
>                      obey    the responder will obey the initiator 
> anytime.
>                      strict  If the responder's length is longer than 
> the ini-
>                              tiator's one, the responder uses the 
> initiator's
>                              one.  Otherwise it rejects the proposal.  
> If PFS
>                              is not required by the responder, the 
> responder
>                              will obey the proposal.  If PFS is 
> required by
>                              both sides and if the responder's group 
> is not
>                              equal to the initiator's one, then the 
> responder
>                              will reject the proposal.
>                      claim   If the responder's length is longer than 
> the ini-
>                              tiator's one, the responder will use the 
> initia-
>                              tor's one.  If the responder's length is 
> shorter
>                              than the initiator's one, the responder 
> uses its
>                              own length AND sends a RESPONDER-LIFETIME 
> notify
>                              message to an initiator in the case of 
> lifetime.
>                              About PFS, this directive is same as strict.
>                      exact   If the initiator's length is not equal to 
> the re-
>                              sponder's one, the responder will reject 
> the pro-
>                              posal.  If PFS is required by both sides 
> and if
>                              the responder's group is not equal to the 
> initia-
>                              tor's one, then the responder will reject the
>                              proposal.


Once you've set the logging level to debug, reply to me with the logs 
and I can give them a once-over.

~Michael Hertrick
~Network Engineering
~Neovera, Inc.
http://www.neovera.com


John Nemeth wrote:

>     I'm seeing problems with VPN connections in 1.6.1 with a variety
>of different endpoints (other NetBSD boxes, Linksys boxes, and
>SonicWalls).  The problem that I'm seeing is that for some reason
>traffic will stop flowing, then a new tunnel will be created.  'setkey
>-D' will show two (or more) tunnels to the same endpoint.  At this
>point, the only solution is to do '/etc/rc.d/ipsec reload' to clear
>everything out.  Then traffic will flow until it happens again.
>Sanitised configs are below for the connection to the Sonicwall (note
>that it likes 24 hour SA timeouts).  The NetBSD box is "<A>" and the
>SonicWall is "<B>".  When things go wrong, the SonicWall will log
>entries saying that it is dropping ESP packets coming from the NetBSD
>box, but it doesn't say why.  Other then the standard log entries for
>the establishment of a new tunnel, there is nothing logged on the
>NetBSD side. Does anybody have any idea on what causes this and how to
>fix it?  Will upgrading to 1.6.1-STABLE fix it?  This is for a critical
>business purpose and if the problem isn't solved VERY soon something
>other then NetBSD will have to terminate the tunnel and I don't want to
>see that.
>
>------------- ipsec.conf -----------
>
>spdadd -4 192.168.2.0/24 192.168.1.0/24 any -P out ipsec
>        esp/tunnel/<A>-<B>/require ;
>
>spdadd -4 192.168.1.0/24 192.168.2.0/24 any -P in ipsec
>        esp/tunnel/<B>-<A>/require ;
>
>
>------------ racoon.conf -----------
>
>path pre_shared_key "/etc/racoon/psk.txt" ;
>
>listen {
>    isakmp <A> ;
>    strict_address ;
>}
>
>remote <B> {
>    exchange_mode main ;
>    my_identifier address <A> ;
>    peers_identifier address <B> ;
>    verify_identifier off ;
>    lifetime time 24 hour ;
>    initial_contact on ;
>    passive off ;
>    support_mip6 off ;
>    generate_policy on ;
>    nonce_size 16 ;
>    proposal {
>        encryption_algorithm 3des ;
>        hash_algorithm sha1 ;
>        authentication_method pre_shared_key ;
>        dh_group modp1024 ;
>        lifetime time 24 hour ;
>    }
>}
>
>sainfo anonymous {
>    pfs_group modp1024 ;
>    lifetime time 24 hour ;
>    encryption_algorithm des, 3des ;
>    authentication_algorithm hmac_md5, hmac_sha1 ;
>    compression_algorithm deflate ;
>}
>
>log notify ;
>
>padding {
>    randomize on ;
>}
>
>
>  
>