[vpn-help] vpn-help Digest, Vol 39, Issue 34

Thu Dec 17 14:52:51 CST 2009

Matthew,

thank you very much for focusing on the Cisco interoperability issues. I
tried to install the Linux version of the client 2.1.6-beta 2, but get
an error which is possibly due to a newer gcc version:

[ 22%] Building CXX object source/iked/CMakeFiles/iked.dir/ike.exch.config.o
/home/daniel/Downloads/Linux/ike/source/iked/ike.exch.config.cpp: In
member function ‘long int _IKED::config_xconf_set(IDB_CFG*, long int&,
long int, VENDOPTS)’:
/home/daniel/Downloads/Linux/ike/source/iked/ike.exch.config.cpp:1812:
error: invalid conversion from ‘const void*’ to ‘void*’
/home/daniel/Downloads/Linux/ike/source/iked/ike.exch.config.cpp:1812:
error: initializing argument 2 of ‘bool _IDB_CFG::attr_add_v(short
unsigned int, void*, size_t)’
make[2]: *** [source/iked/CMakeFiles/iked.dir/ike.exch.config.o] Fehler 1
make[1]: *** [source/iked/CMakeFiles/iked.dir/all] Fehler 2
make: *** [all] Fehler 2

I run openSuse 11.2 with gcc 4.4.1.

Thanks again,
Daniel

-------- Original Message --------
Subject: vpn-help Digest, Vol 39, Issue 34
From: vpn-help-request at lists.shrew.net
To: vpn-help at lists.shrew.net
Date: Thu Dec 17 2009 14:25:50 GMT+0100 (CET)
> Date: Thu, 17 Dec 2009 02:28:30 -0600
> From: VPN Client Product Support <vpn-help at lists.shrew.net>
> Subject: [vpn-help] Please Help Test Possible Cisco Interoperability
> 	Improvements ...
> To: "vpn-help at lists.shrew.net" <vpn-help at lists.shrew.net>
> Message-ID: <4B29EBAE.2000002 at shrew.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> All,
>
> I took a break from the kernel work tonight to focus briefly on Cisco 
> interoperability issues that have been reported. This manifests itself 
> primarily as a disconnect shortly after the tunnel is established. I 
> would like to say that there is a single modification that can be done 
> to the client that will allow it to work with all Cisco gateways, but 
> unfortunately that isn't the case. Its actually few edge cases that 
> cause the same result which I will attempt to describe in some detail.
>
> 1) The Cisco gateway is an older 3000 series concentrator that has split 
> tunnel policies configured. The Shrew Soft VPN client attempts to 
> negotiate individual security associations for each IPsec security 
> policy. The Cisco VPN client negotiates a single IPsec SA with the local 
> ID matching its virtual IP address and a remote ID of 0.0.0.0/0. For the 
> case where split tunneling is used ( tunnel all ), the Shrew Soft client 
> happens to use the same IDs as the Cisco Client. For the case where 
> split tunneling is not used, the Shrew Soft client will negotiate 
> multiple SAs with the local ID matching its virtual address, but with 
> the remote ID matching the distant network.
>
> In other words, if there is a single network of 10.1.2.0/24 behind the 
> gateway, the SAs get negotiated as follows ...
>
> Cisco client with or without Split Tunneling
> IN  0.0.0.0/0 -> VIP
> OUT VIP -> 0.0.0.0/0
>
> Shrew Soft client with Split Tunneling
> IN  10.1.2.0/24 -> VIP
> OUT VIP -> 10.1.2.0/24
>
> Shrew Soft client without Split Tunneling
> IN  0.0.0.0/0 -> VIP
> OUT VIP -> 0.0.0.0/0
>
> Newer Cisco Concentrators like ASAs don't mind if the Shrew Soft client 
> negotiates unique SAs for each policy. However, older Cisco 3000 series 
> concentrators reject client SA negotiation of this type.
>
> WORKAROUND: As a test in 2.1.6 Beta 2, the Shrew Soft VPN client will 
> allow the user to specify a single include network of 0.0.0.0/0.0.0.0 
> under the site configuration policy tab. This configuration will force 
> ALL traffic via the VPN tunnel, even in situations where split tunnels 
> are desired by the gateway. However, this will also force the Shrew Soft 
> client to use the same IDs as the Cisco client. This should allow 
> connectivity to resources via the VPN connection.
>
> SOLUTION: During the brief 2.1.6 development cycle, a new option could 
> be introduced that will allow SAs to be negotiated in the same manner as 
> the Cisco VPN client. However, this will depend on feedback provided by 
> users. If there are ample reports of success using the workaround 
> described in the previous paragraph, I will invest the time in adding 
> this option.
>
> 2) The Cisco gateway utilizes client "application version" access rules 
> that only allow specific versions of the client to connect. The Shrew 
> Soft VPN Client wasn't reporting version information, so gateways that 
> enforced this check would force a disconnect after authentication.
>
> SOLUTION: Beginning with 2.1.6 Beta 2, the Shrew Soft VPN client will 
> send an application version identical to the Cisco VPN client version 
> 4.8.01 which is the latest 4.x version. If that version of the Cisco VPN 
> client is allowed to connect, so will the Shrew Soft VPN client.
>
> 3) The Cisco gateway utilizes client "firewall type" access rules that 
> only allow VPN Clients that enforce local firewall security policies to 
> connect. The Shrew Soft VPN Client wasn't reporting a firewall type, so 
> any gateway that enforced this check would force a disconnect after 
> authentication.
>
> SOLUTION: Beginning with 2.1.6 Beta 2, the Shrew Soft VPN client will 
> send an unknown firewall type. This should allow the client to connect 
> although we don't actually enforce the firewall policies. I'm still 
> struggling with the ethical implications of this change so don't be 
> surprised if I revert this change before the final release.
>
> 4) Bugs in the Cisco PCF import feature??? I'm not sure if this is even 
> relevant at this point but the possibility should not be ruled out.
>
> I think that pretty much covers it. If anyone has any additional input 
> to add I would love to here it. If you are experiencing problems with 
> Cisco gateway connectivity, please try version 2.1.6 Beta 2 and let me 
> know if you have success or failure.
>
> Thanks,
>
> -Matthew
>   