[vpn-help] pulling the rug out...

[Matthew Grooms]

Peter,

As usual, very good catch. Thanks!

> The racoon.conf hasn't really changed, well it shouldn't have.
> 

Your ipsec sa lifetime is mismatched. Racoon does not consider this a 
fatal error if you use obey or claim ...

claim -

If the responder's length is longer than the initiator's one, the 
responder will use the initiator's one.  If the responder's length is 
shorter than the initiator's one, the responder uses its own length AND 
sends a RESPONDER-LIFETIME notify message to an initiator in the case of 
lifetime (phase 2 only). For PFS, this directive behaves the same as strict.

... it just generates a notification message and bundles it in the 
phase2 exchange. I'm glad it did!

> Anyway, attached is the logfile of something that would be nice to avoid if
> possible.
> 

There appears to have been two problems here ...

1) Racoon includes the notify payload data when generating its phase2 
hash value. I used to do this but changed it in the client a while back 
because another vendors gateway was excluding the notify payload.

Anyhow, I just looked checked the RFC ...

HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

With the exception of the HASH, SA, and the optional ID payloads,
there are no payload ordering restrictions on Quick Mode. HASH(1) and
HASH(2) may differ from the illustration above if the order of
payloads in the message differs from the illustrative example or if
any optional payloads, for example a notify payload, have been
chained to the message.

... which clearly states the notify payload should be included when 
generating the hash. Since the calculated hash value was mismatched, the 
phase2 echange was not completing. Obviously this shouldn't hang up 
ipsecd ;)

2) There was an issue with cleaning up the SADB when phase2 hash value 
was rejected. I threw in a quick hack to force this condition and it 
turned out to be simple matter of setting the wrong flag in the state 
bitmap. Since the incomplete phase2 sa was still referencing the tunnel 
object, the tunnel could not be deleted and caused the duplicate tunnel 
error condition to be triggered.

I believe both of these are now fixed but was only able to test (2).

Good people testing and log files rock!

http://www.shrew.net/vpn/changelog.php?ver=1.1-beta-1
http://www.shrew.net/vpn/vpn-client-1.1-beta-1.exe

Thanks again!

-Matthew