[vpn-help] 2.1.6 Beta 10 Available ...

[Matthew Grooms]

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