[vpn-help] Please Help Test Possible CiscoInteroperability Improvements ...

Sat Dec 19 05:41:21 CST 2009

** I'm new here so if I've committed some form of list-etiquette crime then 
please, be nice!

Matthew -

Special thanks from me too!  This work couldn't have come at a better time 
for me.  I have clients with Netgear and Cisco gear and use Win7/x64 myself 
so if I can get it working then this is looking like the ideal solution for 
me.

Without wanting to continue being a "me too", I'm getting similar log 
results in 2.1.6 b2...

09/12/19 10:03:55 ii : rebuilding vnet device list ...
09/12/19 10:03:55 ii : device ROOT\VNET\0000 disabled
09/12/19 10:03:55 ii : network process thread begin ...
09/12/19 10:03:55 ii : pfkey process thread begin ...
09/12/19 10:03:55 !! : unable to connect to pfkey interface

In the first connection attempt, I get config pull response with an IP etc 
but then the connection immediately drops and any subsequent connection 
attempts give a "failed to attach to key daemon ..." message in the connect 
window.

Under 2.1.5 release I imported a PCF which works on the Cisco client they 
use and it appears to connect but we never get traffic over the wire, the SA 
fail count would just keep going up.

At this point, my noobs are showing and I'm not sure if the Cisco 857 I'm 
trying to connect to is PIX or ASA, so I don't know which if any of those 
workarounds I should be testing.

Thanks in advance...
~James

--------------------------------------------------
From: "Kang Sun" <sun_kang at hotmail.com>
Sent: Friday, December 18, 2009 10:06 PM
To: "VPN Shrew" <vpn-help at lists.shrew.net>
Subject: Re: [vpn-help] Please Help Test Possible CiscoInteroperabilityImprovements...

>
> 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/
> _______________________________________________
> vpn-help mailing list
> vpn-help at lists.shrew.net
> http://lists.shrew.net/mailman/listinfo/vpn-help
> 