Date: Sat, 29 Nov 2003 23:32:43 -0800 From: "Crist J. Clark" <cristjc@comcast.net> To: freebsd-net@freebsd.org Subject: Racoon(8) Deleting SPD Entries Message-ID: <20031130073243.GA4474@blossom.cjclark.org>
next in thread | raw e-mail | index | archive | help
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@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031130073243.GA4474>