[Openswan Users] INVALID_HASH_INFORMATION when remote peer is set to %any

Paul Wouters paul at xelerance.com
Tue Apr 28 17:51:16 EDT 2009


On Tue, 28 Apr 2009, Robyn Orosz wrote:

> I'm attempting to connect an Openswan device with a TDT R52U UMTS/EDGE/GPRS Router.  The connection works fine when a fixed IP is set for the
> TDT device however, the TDT device is behind a dynamic IP and so must be set with %any and an ID.  The TDT will only send an ID value if they
> are set to aggressive mode (this seems to differ with Openswan as I can send an ID value in main mode and aggressive mode).  The TDT support
> claims that they are following standards by only sending their ID in aggressive mode wheras it was my understanding that aggressive mode was
> only used to speed up the IKE negotiation.

You can send ID's in main mode, but it is not quick enough to determine who is who when
using PSK (instead of RSA or X.509). So for PSK, yes you need aggressive mode.

> When I have the connection set to %any on the Openswan side I get the following:
> 
> state transition function for STATE_AGGR_R1 failed: INVALID_HASH_INFORMATION

That looks bad. It might be interesting to see the plutodebug=all :)
I am tempted to believe they do something wrong....

> Quick Mode message is unacceptable because it is for an incomplete ISAKMP SA

That's because as far as they're concerned, we've established phase 1. But we
have rejected it with the above error.

> With the same exact PSK and encryption/ hash settings without %any (specifying the real IP address) the tunnel comes up immediately.

%any just means "any ip", so I am confused. Perhaps also send a plutodebug=all with
the IP in it that works. so we can compare?

Can you put those entries in a new bug item on bugs.openswan.org ?

> Any idea what would cause this?  TDT is of course claiming that Openswan has not implemented IPSec correctly but they can't tell me what
> exactly is not correct about the Openswan implementation. 

Give me the logs and I'll have a look and see who we can blame.

Paul


More information about the Users mailing list