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

[Matthew Grooms]

Matthew Grooms wrote:
> 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!
> 

Heh ...

------------------------------------------------------------------------
r602 | mgrooms | 2006-08-28 23:42:05 +0000 (Mon, 28 Aug 2006) | 3 lines

Actually add the notify payload to the hash data accumulator. Fixes
phase2 negotiations when notify payload is bundled.

Fix 3 typos in the find_name function that was confusing tunnel
transport method values.
------------------------------------------------------------------------

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

Its good now.

-Matthew