Date: Mon, 29 Dec 2008 06:18:36 -0800 (PST) From: Gabe <nrml@att.net> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA Message-ID: <847488.86907.qm@web83814.mail.sp1.yahoo.com>
next in thread | raw e-mail | index | archive | help
> From: Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net>
> To: Gabe <nrml@att.net>
> Cc: freebsd-net@freebsd.org
> Sent: Monday, December 29, 2008 5:19:16 AM
> Subject: Re: +ipsec_common_input: no key association found for SA
>
> On Mon, 29 Dec 2008, Bjoern A. Zeeb wrote:
>
> > On Mon, 29 Dec 2008, Gabe wrote:
> >
> >> Anyone know what causes this error message?
> >>
> >> +ipsec_common_input: no key association found for SA
> >> 69.x.x.x[0]/04e317a1/50
> >
> > from what I remember without looking, this means that you ahve an
> > IPsec policy for src/dst but no SA matching this pair or rather no
> > matching destination + protocol + security parameter index (see rfc2401).
> >
> > The easiest thing you can do is to check
> > setkey -Da
> > for this tripple the time the printf happens.
> >
> > The first thing in the printf is your destination IP (your local side),
> > the next is the SPI in hex and last is the protocol (50 == ESP). With
> > that you can see if what the peer sends you is what you negotiated/expected.
> >
> > Are you using static keying or an ike daemon like racoon?
> > Do this happen for all packets or just randomly or exactly every n
> > minutes/hours?
> >
> > If you find an exact match of the triplet in setkey -Da you may also
> > want to check if there is another one and/or the state of the entry/entries
> > (state=.. at the end of the fourth line).
> > If it's not "mature" check the time ralted values to see if there is
> > an expiry problem..
This is what setkey -Da returns:
box# setkey -Da
Invalid extension type
Invalid extension type
box#
I only have one peer (site to site link) and this appears to happen sporadically with no particular pattern that I can figure out. I also tried rebuilding the ipsec-tools port as a just in case and that made no change. This is some more log info:
Dec 29 05:50:37 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/03e4aece/50
Dec 29 05:50:39 box last message repeated 64 times
Dec 29 05:51:33 box kernel: WARNING: pseudo-random number generator used for IPsec processing
Dec 29 05:54:54 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/0cb33e2b/50
Dec 29 05:54:56 box last message repeated 8 times
Dec 29 06:07:32 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/0c4ccc0d/50
Dec 29 06:07:44 box last message repeated 241 times
This started happening after I patched the kernel for NAT_T and enabled NAT_T on racoon, perhaps the natt_keepalive is too long at 20 seconds?
Here is the racoon.con:
padding # options are not to be changed
{
maximum_length 20;
randomize off;
strict_check off;
exclusive_tail off;
}
timer # timing options. change as needed
{
counter 5;
interval 20 sec;
persend 1;
natt_keepalive 20 sec;
phase1 30 sec;
phase2 15 sec;
}
listen # address [port] that racoon will listening on
{
isakmp 69.x.x.x [500];
isakmp_natt 69.x.x.x [4500];
}
remote 69.x.x.x [500]
{
exchange_mode main,base;
doi ipsec_doi;
situation identity_only;
my_identifier address 69.x.x.x;
peers_identifier address 69.x.x.x;
lifetime time 12 hour;
passive off;
proposal_check obey;
nat_traversal on;
generate_policy off;
proposal {
encryption_algorithm blowfish;
hash_algorithm md5;
authentication_method pre_shared_key;
lifetime time 24 hours;
dh_group 1;
}
}
sainfo (address 192.168.10.0/24 any address 192.168.20.0/24 any) # address $network/$netmask $type addres
s $network/$netmask $type ( $type being any or esp)
{ # $network must be the two internal networks you are joining.
pfs_group 1;
lifetime time 36000 sec;
encryption_algorithm blowfish,3des,des;
authentication_algorithm hmac_md5,hmac_sha1;
compression_algorithm deflate;
Thanks in advance,
/gabe
>
> One more thing - you may want to flip the sysctl to
> net.key.preferred_oldsa=0
> and see if that makes a change. But beware - this is going to affect
> all your peers, not just one, so if you have 99 working and 1 not
> you'll most likely kill the other 99.
>
> /bz
>
> --
> Bjoern A. Zeeb The greatest risk is not taking one.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?847488.86907.qm>