From: Ard v. B. <ar...@kw...> - 2004-07-20 09:37:25
|
Hi, I have a perfect working vpn setup with kernel 2.4.24 with the ipsec backport and racoon 0.2.2 . Racoon automatically creates new SPD entries with the same lifetime of the new SAD entries. Now I am trying 2.6.8-rc2 (I've got to replace the firewall), together with racoon 0.3.3 but now racoon creates new entries in the SPD once, and never creates new ones again to replace the expired versions (Heh, it merely logs that they are expired...). I am already digging through the diffs to see what has changes. I know I can quickfix this by uncommenting the test if the policy already exists. But this test worked on 0.2.2 . So, I am just curious what has changed (I will eventually find it, but I will appreciate a kick in the right direction) to find out what causes racoon not to update the SPD's anymore. (Yes, yes, setkey -PF etc... I know, that's not really the issue, the policy is really generated, and then it expires) BTW: as a warning: don't compile 2.6.7 or 2.6.8-rc2 with PREEMPT. After the expire of the SPD, a lot of badness will happen: bad: scheduling while atomic! [schedule+1155/1160] schedule+0x483/0x488 [__do_softirq+126/128] __do_softirq+0x7e/0x80 [do_IRQ+259/310] do_IRQ+0x103/0x136 [work_resched+5/22] work_resched+0x5/0x16 (I guess there is a bug in the xfrm framework) Not the right list, I know, but it will bite you anyway :-). |
From: Ard v. B. <ar...@kw...> - 2004-07-21 11:48:26
|
On Tue, Jul 20, 2004 at 11:36:22AM +0200, Ard van Breemen wrote: > So, I am just curious what has changed (I will eventually find > it, but I will appreciate a kick in the right direction) to find > out what causes racoon not to update the SPD's anymore. > (Yes, yes, setkey -PF etc... I know, that's not really the issue, > the policy is really generated, and then it expires) Hmmm, currently testing: racoon: 0.2.2 libipsec: 0.3.3 kernel: 2.6.7-rc2 vs 2.6.8-rc2 The most interesting part: it says it is *updating* the SPD, but at the moment that appears, the SPD disappears, even though it had 32 seconds life-time left. A "patched" version of racoon 0.3.3 (the one that lies in isakmp_quick about an SPD being available) exhibits the same behaviour: as soon as it updates the SPD, it receives an X_SPDUPDATE, and the SPD's dissappear. Either something is wrong with my systems (debian sid, gcc 3.3.3 and gcc 3.3.4), or this might be the same kernel bug that has been haunting me when I compiled with PREEMPT=y. (After the spd times out, schedule is called within an atomic/spin_locked region.) Just to let me know I am not insane: does anybody else have problems with "generate_policy on" and expired SPD's? Or for that matter: problems with temporary SPD's and kernel 2.6.7 and higher? My working kernel is 2.4.24 with the backport as found in debian unstable, and ipsec-tools 0.2.2. compiled against that kernel. (No, I do not use RSA, so I don't think there were security bugs to bite me). |
From: Tobias P. <pr...@ca...> - 2004-07-21 12:11:20
|
> Just to let me know I am not insane: does anybody else have > problems with "generate_policy on" and expired SPD's? > Or for that matter: problems with temporary SPD's and kernel > 2.6.7 and higher? > My working kernel is 2.4.24 with the backport as found in debian > unstable, and ipsec-tools 0.2.2. compiled against that kernel. > (No, I do not use RSA, so I don't think there were security bugs > to bite me). Hi, finally there is someone who has the same problem like me *gg* I am using Debian unstable with kernel 2.6.6 and ipsec-tools 0.3.3. My problem is that I do can establish a tunnel connection from one roadwarrior to the fixed-ip-server once. But after reconnecting the fixed ip server claims that the ip address of the client connecting is different of the one stored in it's database. I think now it doesnt generate a new policy (as it should) but tries to use the old one with the wrong ip-address. Isn't that exactly the same problem that you have? I haven't had a lot of time to investigate though. But I think you aren't insane at all. But this issue is driving me insane ;-) I reported this behaviour several times on that list with no reply so I already thought I'm the only one with this problem. Any thoughts on how to solve this? Tobias Prousa |
From: Ard v. B. <ar...@kw...> - 2004-07-21 12:25:54
|
On Wed, Jul 21, 2004 at 02:10:05PM +0200, Tobias Prousa wrote: > > Just to let me know I am not insane: does anybody else have > > problems with "generate_policy on" and expired SPD's? > > Or for that matter: problems with temporary SPD's and kernel > > 2.6.7 and higher? > > My working kernel is 2.4.24 with the backport as found in debian > > unstable, and ipsec-tools 0.2.2. compiled against that kernel. > > (No, I do not use RSA, so I don't think there were security bugs > > to bite me). > > Hi, finally there is someone who has the same problem like me *gg* > I am using Debian unstable with kernel 2.6.6 and ipsec-tools 0.3.3. Ah, we have something in common, but I doubt that debian is the problem :-). > My problem is that I do can establish a tunnel connection from > one roadwarrior to the fixed-ip-server once. But after > reconnecting the fixed ip server claims that the ip address of > the client connecting is different of the one stored in it's > database. What is the life time of the SPD at that moment? And compared to the SAD? > I think now it doesnt generate a new policy (as it should) but > tries to use the old one with the wrong ip-address. > Isn't that exactly the same problem that you have? I think you have a different problem :-( To solve that issue I kept my life-times short (2 minutes). Using racoon 0.2.2 and 2.4.24 with the backports, that resulted in a double SPD entry. One new, and one about to be expired. After the expire, everything seems fine. > I haven't had a lot of time to investigate though. But I think > you aren't insane at all. But this issue is driving me insane > ;-) I reported this behaviour several times on that list with > no reply so I already thought I'm the only one with this > problem. Heh.... ipsec is rather complex if you compare it to other things in the kernel (eh, although traffic control might be the worst to understand). I think each of us has it's own set of problems to deal with. > Any thoughts on how to solve this? Well, for the new firewalls I am going back to 2.4.24, and at home I might take a look at that ipsec stuff in the kernel. In the mean time I just hope that someone with ipsecced brains will fix it :-). |
From: Heiko H. <he...@gm...> - 2004-07-21 13:42:44
|
> I think now it doesnt generate a new policy (as it should) but tries to > use the old one with the wrong ip-address. > Isn't that exactly the same problem that you have? > I haven't had a lot of time to investigate though. But I think you aren't > insane at all. But this issue is driving me insane ;-) > I reported this behaviour several times on that list with no reply so I > already thought I'm the only one with this problem. > > Any thoughts on how to solve this? That exactly is the dead end i'm in at the moment (as you are). racoon cannot update the SPD correctly (Ard already pointed out that this may be a kernel problem). So your connection works only as long as the first SP does not expire. I voted for a long timeout as a workaround and then ran into your problem: racoon does not delete unused SP and even reuses unexpired *wrong* SP when the roadwarrior reconnects with a different IP. |
From: Tobias P. <pr...@ca...> - 2004-07-21 13:57:45
|
>That exactly is the dead end i'm in at the moment (as you are). >racoon cannot update the SPD correctly (Ard already pointed out that this may be a kernel problem). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Well looks interesting, did you try it with 2.6.7 or with what kernel version did you have this issue? -- --------------------------------------------------------- CAETEC GbR Schlossstrasse 95a D-82140 Olching - Germany Tel.: +49 8142 / 50 13 60 Fax.: +49 8142 / 50 13 69 eMail: pr...@ca... http://www.caetec.de --------------------------------------------------------- |
From: Heiko H. <he...@gm...> - 2004-07-21 14:05:49
|
> > >That exactly is the dead end i'm in at the moment (as you are). > >racoon cannot update the SPD correctly (Ard already pointed out that this > may be a kernel problem). > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > Well looks interesting, did you try it with 2.6.7 or with what kernel > version did you have this issue? tried with SuSE 2.6.5-7.95-default and Usermode-Linux 2.6.6-uml1-1um. As Ard had the same problem with 2.6.8rc and was successful with the 2.4 backports this smells like a kernel-issue |
From: Tobias P. <pr...@ca...> - 2004-07-21 14:12:43
|
>tried with SuSE 2.6.5-7.95-default and Usermode-Linux 2.6.6-uml1-1um. > >As Ard had the same problem with 2.6.8rc and was successful with the 2.4 >backports this smells like a kernel-issue > > > > > > well, i updated to 2.6.7 today but still had no time to test it. I had that problem with 2.6.3 up to 2.6.6. Don't mix it up with ard's problem, he claims to have a different one than we have! -- --------------------------------------------------------- CAETEC GbR Schlossstrasse 95a D-82140 Olching - Germany Tel.: +49 8142 / 50 13 60 Fax.: +49 8142 / 50 13 69 eMail: pr...@ca... http://www.caetec.de --------------------------------------------------------- |
From: Ard v. B. <ar...@kw...> - 2004-07-21 14:44:55
|
On Wed, Jul 21, 2004 at 04:11:52PM +0200, Tobias Prousa wrote: > >tried with SuSE 2.6.5-7.95-default and Usermode-Linux 2.6.6-uml1-1um. > > > >As Ard had the same problem with 2.6.8rc and was successful with the 2.4 > >backports this smells like a kernel-issue > > > > > > > > > > > > > well, i updated to 2.6.7 today but still had no time to test it. I had > that problem with 2.6.3 up to 2.6.6. > Don't mix it up with ard's problem, he claims to have a different one > than we have! Roughly speaking I see two problems: 1 - SPD's are not updated correctly (either with 0.2.2 or a patched version of 0.3.3) using 2.6.7 or 2.6.8-rc2 (in my case). I am cowardly reverting to 2.4.24 with backports to temporarily circumvent this issue (ipsec is only a small part of the firewall functionality, and currently has taken up the most time) However, for home stuff I cannot revert to 2.4.24 due to agp problems, so I will have to address this issue eventually. 2 - Racoon mistakenly sees two SPD (same subnet, different endpoints) as the same. I think I might have covered that with 1. I use very short lifetimes. (unless something has really changed in functionality between 0.2.2 and 0.3.3). The ipsec "vpn" uptime between a german (due to some telecom act an IP is valid for at most 24 hours in germany. Don't know the details of the act) site and a dutch site makes a lot of "physical" "vpn" providers with big SLA's (and big prices) blush. Anyway, each night the german site changes ip... At that moment racoon is killed, S[PA]Ds are flushed, and when the new ip arrives new SPD's are created and racoon is started. |
From: Ard v. B. <ar...@kw...> - 2004-07-21 13:56:22
|
On Wed, Jul 21, 2004 at 01:47:52PM +0200, Ard van Breemen wrote: > My working kernel is 2.4.24 with the backport as found in debian > unstable, and ipsec-tools 0.2.2. compiled against that kernel. > (No, I do not use RSA, so I don't think there were security bugs > to bite me). Just tried 2.4.24 with an old backport (year old or so). Total results: kernel: 2.4.24 (debian kernel source 2.4.24-1 with ipsec patches buildt in) racoon: 0.2.2 (from debian package ipsec-tools_0.2.2-5 recompiled against 2.4.24) libipsec: 0.3.3 (from debian package 0.3.3-1) If the SA soft-expires, new SA's are created, and the SPD creation time is updated. kernel: 2.4.24 (old, as above) racoon: 0.3.3 (from debian package ipsec-tools_0.3.3-1) libipsec: 0.3.3 (from ipsec-tools_0.3.3-1) If the SAD soft-expires, new SADs are created. The SPDs expire, and are never created again (even not after SAD hard-expire, but then again I might have tested that wrong) kernel: 2.4.24 racoon: 0.3.3 + Lie about existing SPD's patch libipsec: 0.3.3 (from ipsec-tools_0.3.3-1) If the SA soft-expires, new SA's are created, and the SPD creation time is updated. kernel: 2.6.8-rc2 racoon: 0.2.2 (from debian package ipsec-tools_0.2.2-5 recompiled against 2.4.24) libipsec: 0.3.3 (from ipsec-tools_0.3.3-1) If the SA soft-expires, new SA's are created, and the SPDs are *removed* (with time left...) kernel: 2.6.8-rc2 racoon: 0.3.3 + Lie about existing SPD's patch libipsec: 0.3.3 (from ipsec-tools_0.3.3-1) If the SA soft-expires, new SA's are created, and the SPDs are *removed* (with time left...) kernel: 2.6.8-rc2 racoon: 0.3.3 (from debian package ipsec-tools_0.3.3-1) libipsec: 0.3.3 (from ipsec-tools_0.3.3-1) If the SAD soft-expires, new SADs are created. The SPDs expire, and are never created again. About the "Lie about existing SPD's patch": It is actually a kludge, because this code was unchanged between 0.2.2 and 0.3.3. But somehow it makes the thing work. Memory will probably start to leak now :-(. --- ipsec-tools-0.3.3.orig/src/racoon/isakmp_quick.c +++ ipsec-tools-0.3.3/src/racoon/isakmp_quick.c @@ -2013,7 +2013,7 @@ /* get inbound policy */ sp_in = getsp_r(&spidx); - if (sp_in == NULL) { + //if (sp_in == NULL) { if (iph2->ph1->rmconf->gen_policy) { plog(LLV_INFO, LOCATION, NULL, "no policy found, " @@ -2031,7 +2031,7 @@ plog(LLV_ERROR, LOCATION, NULL, "no policy found: %s\n", spidx2str(&spidx)); return ISAKMP_INTERNAL_ERROR; - } + //} /* get outbound policy */ { |