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

[Avesh Agarwal]

On 03/12/2010 10:09 AM, Paul Wouters wrote:
> 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)
>
>
>    
Hello Paul,

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
Avesh

> 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
>
>    
_______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
>