[strongSwan] StrongSwan/Racoon interop issue: IDcr mismatch

[Tobias Brunner]

Hi Rich,

> The problem:
> 
> When Racoon is the initiator and the connections go through NAT, phase 2
> negotiation fails with the following error on the Racoon side:
>   
>        ERROR: mismatched IDcr was returned.

With Transport Mode in NAT situations strongSwan will replace the
received traffic selectors with the actually observed addresses.  It's
definitely possible this causes a problem with racoon (but the same
applies to IDci, which apparently is fine).

> I'd love to have more detail here but I haven't
> yet figured out which logging levels I need to turn up, this is with NET, IKE
> and ENC all at 3.

Nope, then you'd have a lot more messages in the log (in particular ENC
will produce a lot of noise at level 3) including a message on level 2
in IKE that mentions that the traffic selectors are changed.

By the way, I pushed a commit to the ikev1-qm-fragments branch that
fixes the handling of fragments during Quick Mode (avoids the error
messages and error notify seen below:

> Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[ENC] <stg-rlafferty-base14_1|703> payload type FRAGMENT was not encrypted
> Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[ENC] <stg-rlafferty-base14_1|703> could not decrypt payloads
> Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[IKE] <stg-rlafferty-base14_1|703> integrity check failed
> Jan 29 19:07:53 stg-rlafferty-swan15 charon: 29[ENC] <stg-rlafferty-base14_1|703> generating INFORMATIONAL_V1 request 4261518401 [ HASH N(INVAL_HASH) ]

Regards,
Tobias