[Openswan Users] Openswan 2.3.1 vs Cisco 3000

[Paul Wouters]

On Tue, 21 Mar 2006, Darren Ellis wrote:

> We have a tunnel from Openswan 2.3.1 to a Cisco 3000 concentrator.  When we
> try to initiate the connection, we get as far as:

> 003 "cisco" #1: received Vendor ID payload [Dead Peer Detection]
> 004 "cisco" #1: STATE_MAIN_I4: ISAKMP SA established
> 117 "cisco" #2: STATE_QUICK_I1: initiate
>
> The connection will not get beyond this point when we initiate.  When they
> initiate, it seems to work properly.  They, however, aren't always easy to
> reach, so we'd like to be able to restore the tunnel without involving the
> other end.  Below is my config, edited to protect the guilty.

Try this patch by RedHat:

--- openswan-2.3.1/programs/pluto/ipsec_doi.c.cisco     2005-03-27 22:15:09.000000000 +0200
+++ openswan-2.3.1/programs/pluto/ipsec_doi.c   2005-04-22 11:51:14.231560872 +0200
@@ -2061,10 +2061,11 @@
     && !(id->isaid_doi_specific_a == IPPROTO_UDP && id->isaid_doi_specific_b == IKE_UDP_PORT))
     {
        loglog(RC_LOG_SERIOUS, "protocol/port in Phase 1 ID Payload must be 0/0
or %d/%d"
-           " but are %d/%d"
+           " but are %d/%d nat_traversal=%d"
            , IPPROTO_UDP, IKE_UDP_PORT
-           , id->isaid_doi_specific_a, id->isaid_doi_specific_b);
-       return FALSE;
+           , id->isaid_doi_specific_a, id->isaid_doi_specific_b, st->hidden_variables.st_nat_traversal);
+       /* id->isaid_doi_specific_b = IKE_UDP_PORT; */
+       /* st->hidden_variables.st_nat_traversal |= NAT_T_WITH_PORT_FLOATING; */     }

     peer.kind = id->isaid_idtype;

Or upgrade to 2.4.5rc4 or later, where we incorporated this fix.

Paul