[strongSwan] IPAD via NATed firewall doesn't work
Martin Kellermann
kellermann at sk-datentechnik.com
Fri Apr 15 10:40:32 CEST 2011
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.
since iOS 4.3.2 is now released - has anyone tested, if this "racoon
bug" is fixed now?
> 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/20110415/c0fcfbfc/attachment.html>
More information about the Users
mailing list