From: Ico <ra...@ze...> - 2011-12-28 18:10:25
|
* On Wed Dec 28 15:31:54 +0100 2011, Frank Renwick wrote: > I was helped with exactly this issue about 3 weeks ago. I submitted my > question to the opennhrp mailing list as that is what I am implementing. > > I am not an authority in these matters, but reverting to the 0.7.0 behavior > in 0.8.0 (requires a recompile) fixed the issue. I submitted the patch to > the DPD developer and he said he would make the change going forward with > DPD. Thanks for that. We run our own build anyway so recompiling is no issue. I will try the changes you propose, I'll get back later this week (holidays, maybe next week) with the results. > -> in 0.7, the decision to add or not the vendor ID is MM2 based on a > flag being on off, driven by the remoteconf configuration (the remote peer > cfg file construct). > -> in 0.8, the same decision is based on the fact that we got before > the DPD vendor id in MM1 (and if we are configured too). Interesting. Makes me wonder if there is a reason for that? Thanks, Ico -- :wq ^X^Cy^K^X^C^C^C^C |
From: Ico <ra...@ze...> - 2011-12-29 09:00:56
|
Hi Frank, * On Wed Dec 28 15:31:54 +0100 2011, Frank Renwick wrote: > > Racoon is initiator, ASA-5505 is responder. > > > > After 2/3 of the Phase1 life time as set in racoon.conf, the > > ASA-5500 initiates a new Phase1. Racoon responds to this and a new > > Phase 1 is established. > > > > After a while, racoon deletes the old Phase1. Racoon however, keeps > > on checking the old Phase1 cookie for DPD. As the old Phase1 does > > not exist any more, DPD will declare the remote connection for > > "dead" and a completely new Phase1/Phase2 is established. This > > interrupts the tunnel. > > > > Note: although the ASA-5500 is acting as responder, it still starts > > negotiating a new Phase1 (at 2/3 of the Phase1 life time as set in > > racoon.conf). Other IPsec peers do not show this behaviour and let > > racoon do the Phase1 renegotiation. > > > > This behaviour is new to 0.8.0, we did not see this before in 0.7. > > > I was helped with exactly this issue about 3 weeks ago. I submitted > my question to the opennhrp mailing list as that is what I am > implementing. > > I am not an authority in these matters, but reverting to the 0.7.0 > behavior in 0.8.0 (requires a recompile) fixed the issue. I submitted > the patch to the DPD developer and he said he would make the change > going forward with DPD. > > Again, I am not an authority in these matters, which is why I'm only > replying to you directly. I'm sure someone else with more authority > will respond to you. Unfortunately your changes do not seem to fit in: the ISAKMP_NPTYPE_VID case is already handled in the switch, so adding a second time is not possible. -- :wq ^X^Cy^K^X^C^C^C^C |