[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strongswan-users
Subject:    [strongSwan] strongswan 4.1 and some probably windows ipsec server
From:       "=?ISO-8859-2?Q?Maciej_=AFenczykowski?=" <zenczykowski () gmail ! com>
Date:       2007-07-26 11:22:37
Message-ID: 55a4f86e0707260422t4fea731an9062138bb060afef () mail ! gmail ! com
[Download RAW message or body]

Just thought you guys might like to know that sending the XAUTH Vendor ID
during connection initiation causes at least one ipsec server to fail to
respond to the packet
(ie. tcpdump shows an outgoing packet to establish the connection and
absolutely no reply).  If Strongswan 4.1.4 is modified to not send the XAUTH
VID it receives a reply and later correctly establishes a connection (still
having issues with occasional drops, but that's probably just a matter of
tweaking other configuration options).

I believe this is probably a Windows 2003 Server built-in IPsec server or
something like that (I don't actually know what it's running) - it works
fine with both mac and windows ipsec clients and works with the ipsec-tools
package as well (or rather, the failure for ipsec-tools happens much later
during the connection, and is more likely a misconfiguration on my part).

The following patch (more for reference really, ideally there should be a
config option) makes it work with the exact same configuration in all other
aspects:
--- strongswan-4.1.4/src/pluto/ipsec_doi.c.orig 2007-04-10 15:53:
20.000000000-0700

+++ strongswan-4.1.4/src/pluto/ipsec_doi.c      2007-07-17 14:24:
16.000000000-0700

@@ -899,8 +899,6
@@


vids_to_send++;

     if (c->spd.this.cert.type ==
CERT_PGP)


vids_to_send++;

-    /* always send XAUTH Vendor ID
*/

-
vids_to_send++;

     /* always send DPD Vendor ID
*/


vids_to_send++;

     if
(nat_traversal_enabled)

@@ -992,14 +990,6
@@


}


}



-    /* Announce our ability to do eXtended AUTHentication to the peer
*/

-    if (!out_vendorid(vids_to_send-- ? ISAKMP_NEXT_VID :
ISAKMP_NEXT_NONE

-    , &rbody,
VID_MISC_XAUTH))

-
{

-
reset_cur_state();

-       return
STF_INTERNAL_ERROR;

-
}

-

     /* Announce our ability to do Dead Peer Detection to the peer
*/


{

        if (!out_vendorid(vids_to_send-- ? ISAKMP_NEXT_VID :
ISAKMP_NEXT_NONE

@@ -3114,8 +3104,6
@@


vids_to_send++;

     if
(md->openpgp)


vids_to_send++;

-    /* always send XAUTH Vendor ID
*/

-
vids_to_send++;

     /* always send DPD Vendor ID
*/


vids_to_send++;

     if (md->nat_traversal_vid &&
nat_traversal_enabled)

@@ -3181,13 +3169,6
@@


}


}



-    /* Announce our ability to do eXtended AUTHentication to the peer
*/

-    if (!out_vendorid(vids_to_send-- ? ISAKMP_NEXT_VID :
ISAKMP_NEXT_NONE

-    , &md->rbody,
VID_MISC_XAUTH))

-
{

-       return
STF_INTERNAL_ERROR;

-
}

-

     /* Announce our ability to do Dead Peer Detection to the peer
*/

     if (!out_vendorid(vids_to_send-- ? ISAKMP_NEXT_VID :
ISAKMP_NEXT_NONE

     , &md->rbody,
VID_MISC_DPD))



[problem isolated and located by comparing wireshark packet dump between
ipsec-tools initial packet and strongswan initial packet]


also a further patch is necessary (again probably the wrong way to go about
it) otherwise connection fails later on in the process (this is something
that has I believe been reported before) (and even more obviously the
logging in this patch is even more of a hack):
--- strongswan-4.1.4/src/pluto/ipsec_doi.c.orig 2007-07-17 15:36:
33.000000000-0700

+++ strongswan-4.1.4/src/pluto/ipsec_doi.c      2007-07-17 15:39:
41.000000000-0700

@@ -2730,6 +2730,9
@@

     if (!samesubnet(net,
&net_temp)

     || *protoid != id->isaiid_protoid || *port !=
id->isaiid_port)


{

+       loglog(RC_LOG_SERIOUS, "[ip] %08X:%04X/%d == %08X:%04X/%d -> %d",
net->addr.u.v4.sin_addr, net->addr.u.v4.sin_port, net->maskbits,
net_temp.addr.u.v4.sin_addr, net_temp.addr.u.v4.sin_port, net_temp.maskbits,
!samesubnet(net, &ne
+       loglog(RC_LOG_SERIOUS, "[proto] %d == %d -> %d", *protoid,
id->isaiid_protoid, *protoid != id->isaiid_protoid
);

+       loglog(RC_LOG_SERIOUS, "[port] %d == %d -> %d", *port,
id->isaiid_port,    *port != id->isaiid_port
);

        loglog(RC_LOG_SERIOUS, "%s ID returned doesn't match my proposal",
which);

-       return
FALSE;

+       return
TRUE;


}


The precise comparison which fails is the first one (samesubnet) [the other
2 are ok], where the IP reported is that of the server instead of the client
(or the other way round - can't remember, can check if needed).  But, I'm
assuming you already know about this one.

If you need any more precise info, please feel free to ask.

Cheers,
Maciej
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
[prev in list] [next in list] [prev in thread] [next in thread]