[strongSwan] IPAD via NATed firewall doesn't work

[Martin Kellermann]

does this iOS bug also show up when only the server's side is NATed,
or only when both sides are NATed?

Am 12.04.2011 16:53, schrieb Benoit Foucher:
> Hello,
>
> You'll find more information on this INVALID_HASH_INFORMATION in the 
> links I provided earlier on this thread, see at this link:
>
> https://lists.strongswan.org/pipermail/users/2011-February/005863.html
>
> Basically, it seems the error is caused by a bug in raccoon OS X/iOS 
> implementation. I was able to get passed it by hacking strongSwan's 
> code but ran into another issue. I didn't get further time to 
> investigate this or report the raccoon issue to Apple...
>
> Benoit.
>
> Le 12 avr. 2011 à 15:41, Florian Wolters a écrit :
>
>> Hello Martin,
>>
>> I am currently working on the same problem. The problem seems to ly 
>> with strongSwan and the IPad computing hash values on different 
>> information. The log of my strongSwan tells me:
>> --- 8<  snip ---
>> | received encrypted packet from 80.187.98.129:59786
>> | decrypting 48 bytes using algorithm AES_CBC
>> | decrypted:
>> |   0b 00 00 18  b7 1d 29 01  54 a8 d4 3e  34 83 34 7b
>> |   6e 56 9a d4  ea 41 c4 d8  00 00 00 0c  00 00 00 01
>> |   01 00 00 17  00 00 00 00  00 00 00 00  00 00 00 0c
>> | next IV:  73 7b 61 b4  66 c6 c1 60  dc 0c b0 a0  d4 d2 a9 73
>> | ***parse ISAKMP Hash Payload:
>> |    next payload type: ISAKMP_NEXT_N
>> |    length: 24
>> | ***parse ISAKMP Notification Payload:
>> |    next payload type: ISAKMP_NEXT_NONE
>> |    length: 12
>> |    DOI: ISAKMP_DOI_IPSEC
>> |    protocol ID: 1
>> |    SPI size: 0
>> |    Notify Message Type: INVALID_HASH_INFORMATION
>> | removing 12 bytes of padding
>> "iPad_psk"[1] 80.187.98.129:59786 #1: ignoring informational payload,
>> type INVALID_HASH_INFORMATION
>> --- 8<  snap ---
>> In my configuration both the iPad and the strongSwan Server are 
>> NATed. The iPad is one of the first edition but with the latest iOS. 
>> So NAT does not seems to cause the problem but instead the 
>> calculation of hashes. AFAIK there is no configuration option to 
>> change this behavior on strongSwan side.
>> Best regards
>>
>>    Florian
>>
>>
>> Von meinem iPad gesendet
>>
>> Am 04.04.2011 um 20:23 schrieb Martin Kellermann 
>> <kellermann at sk-datentechnik.com <mailto:kellermann at sk-datentechnik.com>>:
>>
>>> hello andreas,
>>>
>>> yes, you are right, but this still doesn't solve the problem. i am 
>>> still
>>> stuck...
>>>
>>> reading some current posts on APPLEs discussion forum
>>> (for ex: http://discussions.apple.com/thread.jspa?threadID=2778039)
>>> maybe this is a general problem with iOS > 4.3 ?
>>>
>>> so i'm very interested if anyone has managed to get the iPad 2 (iOS 
>>> 4.3.1)
>>> connect to strongswan with one or both sides being NATed?
>>>
>>> or maybe someone has managed to connect to open-/freeSWAN ?
>>> (server is on debian 6)
>>>
>>> any help is really appreciated!
>>>
>>> thank you
>>>
>>> Martin
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
>> https://lists.strongswan.org/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110413/51f9144e/attachment.html>