[Vpn-help] Fwd: New 2.2.0 alpha available ...

[Rodrigo Ferroni]

Matthew,

I just try again the first host and works fine.


>>
> Rodrigo,
>
> Strange. I just looked a the log again and noticed that you do have DPD
> enabled on both ends. But the peer was still trying to use an old ISAKMP SA
> to communicate with the Shrew Soft Client. For example, you see a lot of
> messages that look like this in your log output ...
>
> 08/10/28 19:17:42 ww : ike packet from xx.xx.xx.xx ignored, unknown phase1
> sa for peer
> 08/10/28 19:17:42 ww : 11c8e933c98ffbfb:7b2155d1ae13bb9a
>
> ... but the ISAKMP cookie pair "11c8e933c98ffbfb:7b2155d1ae13bb9a" was not
> negotiated by the client during that session which means it was from a
> previous connection. Maybe the DPD timeout hadn't triggered yet. What do you
> have it set to in your racoon.conf file?



Is like you said the problem is related to DPD, in the racoon.conf i have
this options:
dpd_delay 20;
dpd_maxfail 50;
I suppose the second is the problem, the default value according the man
page is 5,
"this set the maximum number of proof of liveness to request before
considering the peer is dead"
for the moment i can't change this option to confirm this, because i need to
restart racoon.


>
> One good thing to note is that Timmo, another ipsec-tools developer, has
> added proper handling of the INITIAL-CONTACT notification message to the
> forthcoming 0.8 release. This means that anytime there are stale ISAKMP or
> IPsec SAs, they should get cleanup up automatically as the Shrew Soft client
> sends this notification explicitly after connecting.
>

> Thanks,
>
> -Matthew
>

The are good news, thanks.
Rodrigo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20081029/46fac731/attachment-0002.html>