[Openswan dev] feedback requested on Workaround for: Expecting MODE_CFG_REPLY, got ISAKMP_CFG_ACK instead
paul at xelerance.com
Fri Mar 12 10:09:55 EST 2010
While debugging a connection with a Nokia E71 VPN client using xauth, I got the
"xauth" 18.104.22.168 #1: Expecting MODE_CFG_REPLY, got ISAKMP_CFG_ACK instead.
The code in question:
@@ -1190,7 +1190,8 @@ xauth_inR0(struct msg_digest *md)
if (md->chain[ISAKMP_NEXT_ATTR]->payload.attribute.isama_type != ISAKMP_CFG_REPLY)
openswan_log("Expecting MODE_CFG_REPLY, got %s instead."
, enum_name(&attr_msg_type_names, md->chain[ISAKMP_NEXT_ATTR]->payload.attribute.isama_type));
I have not looked at the RFC's yet, or whether ISAKMP_CFG_ACK is a cisco-only non-ietf attribute,
but simple changing the code to allow both MODE_CFG_REPLY and ISAKMP_CFG_ACK made the connection work.
I guess this requires verification with the proper RFC's and someone should verify if I made a
configuration mistake. I used:
#remote_peer_type=cisco (tried enabling this too)
In this case, the Nokia VPN client also seems to insist on pushing its own IP, and
will not be convinced to use anything we specify as rightsubnet=22.214.171.124/32, which
I think is how this is supposed to work according to testing/pluto/xauth-pluto-09/east.conf
More information about the Dev