Racoon(8) Deleting SPD Entries
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 < 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 | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Racoon(8) Deleting SPD Entries
On Sat, 29 Nov 2003, Crist J. Clark wrote: > 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've never quite seen the point of this option; surely using the old SA just can't possibly work properly? > 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. I've come across this, too. It appears to be a bug in Racoon; I've submitted a bug report to KAME - bug fbsd4/530. When Racoon creates the security policy it gives it a timeout equal to the timeout on the SA. It doesn't renew this timeout when a new SA is negotiated and will only create a new SP if the existing SP has already timed out. My solution was to statically configure the security policies. This works OK for us because the clients have static IP addresses - but it means that their dial-up fallback won't work because their IP addresses will change. It looks like the SP timeout could be left unset as a quick fix. Ideally, though, I'd prefer to have some sort of 'security policy template' database which would allow clients with particular IDs to establish SPs tunnelling to/from only particular networks but with the remote tunnel endpoints being whatever IP addresses they have at the time. There is a possibility I'll get the chance to work on doing this. On the other hand we might just use Linux and FreeSWAN instead. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[no subject]
Hi all,
I've been trying to write some code using divert(4) sockets, but i meet the following
difficulties:
- when i get diverted packet it has both source and destination IP addresses the
same. The attached code shows:
192.168.0.2 -> 192.168.0.2
getting 84 bytes, real: 84
and the way I run it is (on 192.168.0.2):
ipfw add 100 divert 8670 ip from any to 192.168.0.1
burstd
then on 192.168.0.2 I issue "ping 192.168.0.1"
- the manual says this happens with recvfrom()/sendto(), but recv() is mentioned
to be same as recvfrom() and read()/write() sometimes fail.
After digging some kernel code I've found that around line 167 in ip_divert.c we have:
/*
* Record receive interface address, if any.
* But only for incoming packets.
*/
divsrc.sin_addr.s_addr = 0;
if (incoming) {
struct ifaddr *ifa;
/* Sanity check */
KASSERT((m->m_flags & M_PKTHDR), ("%s: !PKTHDR", __FUNCTION__));
/* Find IP address for receive interface */
TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) {
if (ifa->ifa_addr == NULL)
continue;
if (ifa->ifa_addr->sa_family != AF_INET)
continue;
divsrc.sin_addr =
((struct sockaddr_in *) ifa->ifa_addr)->sin_addr;
break;
}
}
which (as I think) changes the address of diverted packet. What is the reason for that
and are there any workarounds to get real source and destination IP addresses from a
diverted packet. I need both because I try to make connection tracking based on
src<->dst .
Any help with that is appretiated. Any divert code welcome. I've looked through natd.c
and it was helpfull.
Ivo Vachkov
P.S. Excuse my:
- English
- long pastes
- (sometimes) lack of kernel code understanding
--
___
Get your free email from http://mymail.bsdmail.com
Powered by Outblaze
Makefile
Description: Binary data
burstd.h
Description: Binary data
burstd.c
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re:
The problem is in your test program; you're calling inet_ntoa() twice in your printf() invocation, and the second call to inet_ntoa() overwrites the static buffer that's returned. louie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
