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

[VPN Client Product Support]

Hi!

I tried the 2.1.6 Beta 2 client with the 0.0.0... fix but I couldn't get 
it to work anyway.
This is a short snippet of the log, email me if you need the whole thing.

09/12/17 15:07:08 !! : unable to locate inbound policy for init phase2
09/12/17 15:07:09 ii : created IPSEC policy route for 0.0.0.0
09/12/17 15:07:09 ii : split DNS bypassed ( no split domains defined )
09/12/17 15:07:10 ii : processing config packet ( 220 bytes )
09/12/17 15:07:10 !! : config packet ignored, ( config already mature )

Thanks
Tomas


VPN Client Product Support skrev:
> 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
>