[Openswan dev] [Openswan Users] Sending the "Initial Contact" message

[Paul Wouters]

On Mon, 29 Mar 2010, Snitgen, John wrote:

> First I'll answer your question, and then I'll try to provide more detail on the problem... The engineers at Cisco that are working on this issue with us have told me that the problem that I am seeing would not be a problem if the VPN client that I am using complied with the "Unity" standard... more specifically, if the client I am using sent the 'initial contact' message, this problem would not be a problem.
>
> What we are seeing is that on occasion the Cisco aggregator will get 'hung' in the middle of negotiating a new session with one of the spokes (the spokes are all running Linux Openswan).  We think this happens when the connection being used to establish the session gets terminated unexpectedly during negotiation (typically the connection is PPP over wireless).  The spoke is then unable to negotiate a new session until the SA actually times out on the Cisco, or the hung session is manually cleared on the Cisco.  This is apparently tied to NAT-T on the Cisco, as the problem doesn't occur if the Cisco end is not NAT'd.  Cisco refuses to acknowledge that this problem is a bug in their code because the Linux/Openswan 'client' does not comply with the 'Unity' standard.

I'd ask them what RFC numbe rthis "Unity standard" is. A quick google search gave me no technical
details on what this is supposed to be.

> My guess is that updating the code will more than likely not fix this particular issue, unless the updated code sends the initial contact message but I will look into doing that anyway.

Check how we add the DPD vendor id, and you could add the initial message in the same way. If you
make sending it depend on remote_peer_type=cisco, we'd happilly merge in the patch.

Paul