On 7/6/2010 8:12 PM, Aaron Sarazan wrote: > Hey didn't see a published bug report address, so I'll just send to you > directly, let me know if I should be sending this elsewhere. > > Win7 64-bit > Shrew 2.1.6 beta10 > Netgear FVS338: PSK+XAuth > Use existing adapter > > phase 2 fails to connect, and eventually times out. First upon > connection it says "unable to locate inbound policy for init phase2" -- > then when attempting to ping the secured/remote network it will > apparently attempt at phase 2, and almost get there (it would succeed in > 2.1.5) -- it evenutally gives up. > > Attached are the debug logs, let me know if there's anything else you > need, or if I should be sending this elsewhere. >
Hi Aaron, Thanks for the bug report and the debug output. I hope you don't mind me replying to the list as well ( without your debug output ) so that this information can help others. The change that causes this behavior is related to the new policy level feature introduced in beta 9. It is intended to improve interoperability with Cisco VPN gateways by adding a new policy level that allows a single IPsec SA to be shared between all policies. This cisco'ish policy level differs from the previous behavior ( or unique policy level ) and is selected when the client receives a CISCO-UNITY vendor ID during phase1 negotiation. However, if your clients connect to an ipsec-tools based VPN gateway, which also advertises itself as CISCO-UNITY, you may need to take one of the following actions ... 1) Adjust your client configuration to always use the unique policy level which is selectable under the policy tab of the site config. This forces the client to use the old behavior. 2) Adjust your racoon.conf to match the new behavior. The client will send a remote ID of 0.0.0.0/0 during phase2 negotiation. Your sainfo section must be written to allow this. So if you already had things working using the unique policy level, I would recommend option (1). In my opinion, unless you curtail client access using firewall policies, option (1) is the more secure method when using ipsec-tools. However, if you have many networks to protect behind your gateway, using option (2) in conjunction with firewall rules that curtail client access will allow you to increase client connection scalability by an order of magnitude. Only a single policy and SA are generated for each connection using the shared level vs multiple policies and SAs for each target network behind the gateway using the unique level. Deficiencies in the PF_KEY layer ( at least with some systems ) will limit the number of SA/SP entries that can be managed by a key daemon. Using fewer entries per client connection has a direct positive impact on scalability. For users connecting to Cisco gateways, the new shared policy level will improve compatibility substantially. Older Cisco gateways ( such as 3000 series concentrators ) are incompatible with clients that don't offer a shared policy level. This causes many of the 'disconnects a few seconds after the tunnel says enabled' issues that have been reported. In other cases, it may allow you to talk to multiple networks behind a gateway where before only a single network was accessible. It also allows folks to remove the 0.0.0.0/0 include network entry that was a required work-around in some cases. In other words, things should 'just work' better with real Cisco gateways. Hope this helps and thanks for testing! -Matthew _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
