[Openswan dev] feedback requested on Workaround for: Expecting MODE_CFG_REPLY, got ISAKMP_CFG_ACK instead

[Paul Wouters]

Hi,

While debugging a connection with a Nokia E71 VPN client using xauth, I got the
following error:

 	"xauth"[2] 1.2.3.4 #1: Expecting MODE_CFG_REPLY, got ISAKMP_CFG_ACK instead.

The code in question:

programs/pluto/xauth.c
@@ -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:

 	leftxauthserver=yes
 	rightxauthclient=yes
 	modecfgpull=no
 	modecfgdns1=...
         modecfgwins1=...
         leftmodecfgserver=yes
         rightmodecfgclient=yes
 	#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=1.2.3.4/32, which
I think is how this is supposed to work according to testing/pluto/xauth-pluto-09/east.conf