Racoon(8) Deleting SPD Entries

Crist J. Clark cristjc at comcast.net
Sat Nov 29 23:32:52 PST 2003


Versions: Racoon(8) from ports racoon-20030826a. FreeBSD kernel
4.8-RELEASE-p13. Running with net.key.prefered_oldsa=1, but flipping
to 0 does not seem to make a difference.

I am having some problems with racoon(8). Everything works fine for
the lifetime of the initial SA, but then things die. When the initial
SA is removed, racoon(8) seems to be clearing out the corresponding
entry in the SPD. However, when we had reached the soft timeout
earlier, racoon(8) had established new SAs. Since we have good SAs,
racoon(8) doesn't try to do new negotiations. Both ends have a good
SAD, but the responder no longer has SPD entries for the pair.

Here's a more detailed timeline,

    0 s	- SAs established, SPD entry added by racoon(8) on responder.
 1440	- Soft timeout. Racoon(8) negotiates new SA. Old SAs in the
	  'dying' state. Two SAs now valid between the hosts.
 1800	- Racoon(8) deletes the old, dying SA, removes corresponding
	  SPD entry. The SAs negotiated at 1440 s are still valid in
	  the SAD.

And now we are broken. The responder can receive datagrams, but when
it tries to send, there is no entry in the SPD, so the outgoing SA is
never applied.

I can remotely fix the issue. On the initiator, I can remove the SA
entry for traffic from the initiator to the responder. This will cause
the initiator to renegotiate again which causes racoon(8) on the
responder to put an entry back in the SPD. However, manually running,

  # setkey -c <<EOF
  > delete a.b.c.d e.f.g.h esp 0x01234567;
  > EOF

Every half-hour is not practical. The fact I got disconnected three
times while trying to type this email into a remote machine is
evidence of that.

The responder has no manually added SPD entries. Here is its
racoon.conf(5),

 # Wireless network
  remote anonymous {
          exchange_mode main;
          my_identifier asn1dn;
          certificate_type x509 "buttercup_x509.pem" "buttercup_key.pem";
          peers_identifier asn1dn;
          lifetime time 1 min;
          passive on;
          generate_policy on;
          proposal {
                  encryption_algorithm 3des;
                  hash_algorithm sha1;
                  authentication_method rsasig;
                  dh_group 2;
          }
   }

  sainfo anonymous {
          pfs_group 2;
          lifetime time 30 min;
          encryption_algorithm rijndael, 3des;
          authentication_algorithm hmac_sha1, hmac_md5;
           compression_algorithm deflate;
  }

The initiator has an SPD added in the dhclient-exit-hooks script,

  spdadd $new_ip_address/32 0.0.0.0/0 any -P out
      ipsec esp/tunnel/${new_ip_address}-${router}/require;
  spdadd 0.0.0.0/0 $new_ip_address/32 any -P  in
      ipsec esp/tunnel/${router}-${new_ip_address}/require;

Where "router" is the responder. The racoon.conf(5) is,

  remote anonymous
  {
          exchange_mode main;
          my_identifier asn1dn;
          certificate_type x509 "wireless_x509.pem" "wireless_key.pem";
          peers_identifier asn1dn;
          lifetime time 1 min;
          proposal {
                  encryption_algorithm 3des;
                  hash_algorithm sha1;
                  authentication_method rsasig;
                  dh_group 2;
          }
  }

  sainfo anonymous
  {
          pfs_group 2;
          lifetime time 30 min;
          encryption_algorithm rijndael, 3des;
          authentication_algorithm hmac_sha1, hmac_md5;
          compression_algorithm deflate;
  }

This all worked until a recent reboot on the responder... I cannot
figure out what may have changed to cause this problem.
-- 
Crist J. Clark                     |     cjclark at alum.mit.edu
                                   |     cjclark at jhu.edu
http://people.freebsd.org/~cjc/    |     cjc at freebsd.org


More information about the freebsd-net mailing list