<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello,<div><br></div><div>You'll find more information on this INVALID_HASH_INFORMATION in the links I provided earlier on this thread, see at this link:<div><br></div><div> <a href="https://lists.strongswan.org/pipermail/users/2011-February/005863.html">https://lists.strongswan.org/pipermail/users/2011-February/005863.html</a><br><div><br></div><div>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...</div><div><br></div><div>Benoit.</div><div><br><div><div>Le 12 avr. 2011 à 15:41, Florian Wolters a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div>Hello Martin,</div><div><br></div><div>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:</div><div><span class="Apple-style-span" style="font-family: Times; -webkit-border-horizontal-spacing: 5px; -webkit-border-vertical-spacing: 5px; "><pre>--- 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 ---
</pre></span>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.</div><div>Best regards</div><div><br></div><div> Florian</div><div><br></div><div><br></div><div>Von meinem iPad gesendet</div><div><br>Am 04.04.2011 um 20:23 schrieb Martin Kellermann <<a href="mailto:kellermann@sk-datentechnik.com">kellermann@sk-datentechnik.com</a>>:<br><br></div><div></div><blockquote type="cite"><div><span>hello andreas,</span><br><span></span><br><span>yes, you are right, but this still doesn't solve the problem. i am still </span><br><span>stuck...</span><br><span></span><br><span>reading some current posts on APPLEs discussion forum</span><br><span>(for ex: <a href="http://discussions.apple.com/thread.jspa?threadID=2778039">http://discussions.apple.com/thread.jspa?threadID=2778039</a>)</span><br><span>maybe this is a general problem with iOS > 4.3 ?</span><br><span></span><br><span>so i'm very interested if anyone has managed to get the iPad 2 (iOS 4.3.1)</span><br><span>connect to strongswan with one or both sides being NATed?</span><br><span></span><br><span>or maybe someone has managed to connect to open-/freeSWAN ?</span><br><span>(server is on debian 6)</span><br><span></span><br><span>any help is really appreciated!</span><br><span></span><br><span>thank you</span><br><span></span><br><span>Martin</span><span><br></span><span></span><br></div></blockquote></div>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>https://lists.strongswan.org/mailman/listinfo/users</blockquote></div><br></div></div></div></body></html>