[Openswan dev] feedback requested on Workaround for: Expecting MODE_CFG_REPLY, got ISAKMP_CFG_ACK instead
avagarwa at redhat.com
Wed Mar 17 15:00:57 EDT 2010
On 03/12/2010 10:09 AM, Paul Wouters wrote:
> While debugging a connection with a Nokia E71 VPN client using xauth, I got the
> following error:
> "xauth" 184.108.40.206 #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)
As you specify "leftxauthserver=yes" , that means Openswan is acting as
server, in that case "remote_peer_type=cisco" will not have any effect
as this parameter is only for Openswan client side.
Thanks and Regards
> 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=220.127.116.11/32, which
> I think is how this is supposed to work according to testing/pluto/xauth-pluto-09/east.conf
> Dev mailing list
> Dev at openswan.org
More information about the Dev