[Openswan Users] Openswan 2.3.1 vs Cisco 3000
paul at xelerance.com
Tue Mar 21 22:01:12 CET 2006
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
- " 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.
More information about the Users