[vpn-help] Please Help Test Possible Cisco Interoperability Improvements ...

[Kang Sun]

Thank you for spending time working on Cisco interoperability issues. Here is my report:
As I said before, 2.1.6Beta2 works perfectly on Windows NT SP3 with Cisco Easy VPN.

Today I tested it on 64-bit Windows 7 with no luck. I used the same Shruw configuration as I did on XP.

When I run Access Manager, I got
"Detached from Key daemon"

Windows pop up: IKED.EXE Stopped working
Files that help describe the problem:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_iked.exe_f71c26ecb7586aee31dd2a9c67f827f543f2f164_cab_0778da18\WERD77A.tmp.appcompat.txt
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_iked.exe_f71c26ecb7586aee31dd2a9c67f827f543f2f164_cab_0778da18\WERD865.tmp.WERInternalMetadata.xml
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_iked.exe_f71c26ecb7586aee31dd2a9c67f827f543f2f164_cab_0778da18\WERD9DD.tmp.mdmp

I turned on debug, the Trace Utility said:
09/12/19 15:45:02 !! : unable to connect to pfkey interface.

Please help! Meanwhile, have a nice weeked.

-- Kang Sun


> Date: Thu, 17 Dec 2009 02:28:30 -0600
> To: vpn-help at lists.shrew.net
> From: vpn-help at lists.shrew.net
> Subject: [vpn-help] Please Help Test Possible Cisco Interoperability Improvements ...
>
> 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
> _______________________________________________
> vpn-help mailing list
> vpn-help at lists.shrew.net
> http://lists.shrew.net/mailman/listinfo/vpn-help


 		 	   		  
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/