I do not understand why Michael write his question in this thread, with an specified problem for an specified gateway of Lucent-Alcatel and his client only for Windows, because his question is completely different with my question and the problem in this thread...<br />Anyway, thanks, but my problem is here, and I can&#39;t work in Linux.<br /><br />El , &quot;Michael H. Warfield&quot; &lt;mhw@wittsend.com&gt; escribió:<br />&gt; On Sat, 2010-02-20 at 23:11 -0500, Michael H. Warfield wrote:<br />&gt; <br />&gt; &gt; On Sat, 2010-02-20 at 18:18 -0500, Paul Wouters wrote:<br />&gt; <br />&gt; &gt; &gt; On Sat, 20 Feb 2010, Michael H. Warfield wrote:<br />&gt; <br />&gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; &gt;&gt; So, AFAICT, there seem to be two problems for me to solve here.  One is<br />&gt; <br />&gt; &gt; &gt; &gt;&gt; to give the server a block of acceptable proposals from which it will<br />&gt; <br />&gt; &gt; &gt; &gt;&gt; select one.  Two, I need to get that Key ID correct.<br />&gt; <br />&gt; &gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; &gt; Hmmm...  Not comfortable with just diving too deeply into that<br />&gt; <br />&gt; &gt; &gt; &gt; init_am_st_oakley stuff there in spdb_v1_struct.c even though that<br />&gt; <br />&gt; &gt; &gt; &gt; appears to be where we need to be building a set of proposals.  I<br />&gt; <br />&gt; &gt; &gt; &gt; understand that aggressive mode can not renegotiate and all but we can<br />&gt; <br />&gt; &gt; &gt; &gt; (obviously from the vpnc trace), at least, initiate with a list of them,<br />&gt; <br />&gt; &gt; &gt; &gt; like vpnc does, and it&#39;s up to the server to then pick one and only one.<br />&gt; <br />&gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; Yes, so you have to at least get the DH group right on the first packet<br />&gt; <br />&gt; &gt; &gt; you send. Openswan forced you to set a single proposal in those cases,<br />&gt; <br />&gt; &gt; &gt; because AFAIK it could not send more then one in aggressive mode. I<br />&gt; <br />&gt; &gt; &gt; guess I might be wrong and it can send multiple, as long as the DH group<br />&gt; <br />&gt; &gt; &gt; for all of those is the same (and the size being used on that first packet)<br />&gt; <br />&gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; &gt; Ouch...  This does not look good.  If that Cisco is looking for my group<br />&gt; <br />&gt; &gt; &gt; &gt; name in the Identification Payload with a type of &quot;KEY_ID&quot;, that&#39;s a<br />&gt; <br />&gt; &gt; &gt; &gt; problem.  I finally found that in lib/libopenswan/id.c around line 136<br />&gt; <br />&gt; &gt; &gt; &gt; in atooid().  So if the leftid begings @[ you&#39;re going to take the rest<br />&gt; <br />&gt; &gt; &gt; &gt; of that parameter as an ascii key id with type ID_KEY_ID conditionally<br />&gt; <br />&gt; &gt; &gt; &gt; removing the closing &#39;]&#39;.  Tried that.  Lookee there, I got the right<br />&gt; <br />&gt; &gt; &gt; &gt; KeyID but the wrong payload length.  It&#39;s off by 2 if the string ends<br />&gt; <br />&gt; &gt; &gt; &gt; with a &#39;]&#39; and off by one if not.  So it doesn&#39;t look like it&#39;s trimming<br />&gt; <br />&gt; &gt; &gt; &gt; anything when I add that &#39;]&#39;.  And that code just does not look right...<br />&gt; <br />&gt; &gt;<br />&gt; <br />&gt; &gt; &gt; I have never seen a leftid/rightid syntax with [] in them. Perhaps Hugh<br />&gt; <br />&gt; &gt; &gt; remembers if that syntax is used anywhere?<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; Maybe Hugh remembers me from the FreeSWAN days when I couldn&#39;t<br />&gt; <br />&gt; &gt; contribute anything except hassle them (US / Canada ITAR / EAR<br />&gt; <br />&gt; &gt; regulations days) with testing.  Hopefully he remembers this.  But it<br />&gt; <br />&gt; &gt; looks like there are some other syntaxs in there including @# (Key ID<br />&gt; <br />&gt; &gt; type ID_KEY_ID and hex encoded data) and @~ (Key ID type<br />&gt; <br />&gt; &gt; ID_DER_ASN1_DN).  They must have been put in there for a reason.<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; &gt; &gt; ==<br />&gt; <br />&gt; &gt; &gt; &gt;    else if (*(src+1) == &#39;[&#39;)<br />&gt; <br />&gt; &gt; &gt; &gt;    {<br />&gt; <br />&gt; &gt; &gt; &gt;        /* if there is a second specifier ([) on the line<br />&gt; <br />&gt; &gt; &gt; &gt;         * we interprete this as a text ID_KEY_ID, and we remove<br />&gt; <br />&gt; &gt; &gt; &gt;         * a trailing &quot;, if there is one.<br />&gt; <br />&gt; &gt; &gt; &gt;         */<br />&gt; <br />&gt; &gt; &gt; &gt;        int len = strlen(src+2);<br />&gt; <br />&gt; &gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; &gt;        id-&gt;kind = ID_KEY_ID;<br />&gt; <br />&gt; &gt; &gt; &gt;        id-&gt;name.ptr = (unsigned char *)src+2;<br />&gt; <br />&gt; &gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; &gt;        if(src[len+2]==&#39;]&#39;)<br />&gt; <br />&gt; &gt; &gt; &gt;        {<br />&gt; <br />&gt; &gt; &gt; &gt;            src[len+2-1]=&#39;\0&#39;;<br />&gt; <br />&gt; &gt; &gt; &gt;            len--;<br />&gt; <br />&gt; &gt; &gt; &gt;        }<br />&gt; <br />&gt; &gt; &gt; &gt;        id-&gt;name.len = len;<br />&gt; <br />&gt; &gt; &gt; &gt;    }<br />&gt; <br />&gt; &gt; &gt; &gt; ==<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; &gt; I am not sure how removing a trailing &#39;&quot;&#39; becomes removing a closing bracket.<br />&gt; <br />&gt; &gt; &gt; I&#39;d have to look at more context on the ID_KEY_ID case.<br />&gt; <br />&gt; &gt; &gt; Are you sure you cannot use leftid=@somestring?<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; I think that comment about the &#39;&quot;&#39; is merely a screw-up in the comments,<br />&gt; <br />&gt; &gt; but I&#39;m not entirely sure.  It may have, in the early FreeSWAN days been<br />&gt; <br />&gt; &gt; intended to be a &#39;&quot;&#39; but the changed it to square brackets and didn&#39;t<br />&gt; <br />&gt; &gt; update the comments.  THAT&#39;S where my money&#39;s at.  Knowing the history<br />&gt; <br />&gt; &gt; of the FreeSWAN 1.x early days, it would NOT be the first time.  IAC,<br />&gt; <br />&gt; &gt; that code don&#39;t look right.<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; I&#39;m fairly thorough in testing the documented combinations.  If I use<br />&gt; <br />&gt; &gt; &quot;Fobar&quot; it gives a type of &quot;IPv4 address&quot; data &quot;Fubar&quot;.  If I use<br />&gt; <br />&gt; &gt; &quot;@Fubar&quot; it gives me type &quot;FQDN&quot; data &quot;Fubar&quot;.  Looking at that code,<br />&gt; <br />&gt; &gt; that appears to be the only way to get the Key ID type right.<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; &gt; &gt; Now wait a minute here...<br />&gt; <br />&gt; &gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; &gt; You&#39;re checking &quot;src[len+2]&quot; if it&#39;s a closing bracket and, if it is,<br />&gt; <br />&gt; &gt; &gt; &gt; NULLing the character before the bracket?  That doesn&#39;t look right and<br />&gt; <br />&gt; &gt; &gt; &gt; it doesn&#39;t appear to be working either.<br />&gt; <br />&gt; &gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; &gt; That &quot;leftid=@[literal_key_id]&quot; needs to be documented somewhere.<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; &gt; Once I know of a valid use, I can.....<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; I&#39;ve followed the cold paths.  I have to get the key ID type = ID_KEY_ID<br />&gt; <br />&gt; &gt; and I don&#39;t seen any other path.<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; &gt; &gt; I couldn&#39;t find it in the documentation anywhere and I think that&#39;s going<br />&gt; <br />&gt; &gt; &gt; &gt; to be required for some configurations.  Maybe I&#39;m being blind and<br />&gt; <br />&gt; &gt; &gt; &gt; overlooking it somewhere but I&#39;m just not seeing it.  Should be in the<br />&gt; <br />&gt; &gt; &gt; &gt; man pages for ipsec.conf for leftid/rightid along with the rest of that<br />&gt; <br />&gt; &gt; &gt; &gt; archaine syntax supported in id.c.<br />&gt; <br />&gt; &gt; &gt; &gt;<br />&gt; <br />&gt; &gt; &gt; &gt; I still see a difference in that Identification payload that the one<br />&gt; <br />&gt; &gt; &gt; &gt; that works is specifying a &quot;Protocol ID&quot; of UDP and a &quot;Port&quot; of 500 and<br />&gt; <br />&gt; &gt; &gt; &gt; both are &quot;Unused&quot; in the case that fails.  That could account for<br />&gt; <br />&gt; &gt; &gt; &gt; remaining offset of the payload length.  I&#39;m looking into getting that<br />&gt; <br />&gt; &gt; &gt; &gt; right now.<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; &gt; That might be related to cisco&#39;s non-standard use of UDP 10000. There is<br />&gt; <br />&gt; &gt; &gt; some code in contrib/ that tries to deal with that.<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; Working on that now.  Looks like setting leftprotoport might do the<br />&gt; <br />&gt; &gt; trick but I haven&#39;t tried it yet.  However, in this case, we are not<br />&gt; <br />&gt; &gt; using the vpnc option of cisco-udp (port 10000).  We&#39;re using the vpnc<br />&gt; <br />&gt; &gt; option of force-natt, which uses the standard 500/udp 4500/udp which is<br />&gt; <br />&gt; &gt; what we want to be doing.  Nobody expects OpenSWAN to support 1000/udp<br />&gt; <br />&gt; &gt; or the Cisco IPSec over TCP.  Just trying to get the stock and trade<br />&gt; <br />&gt; &gt; working.<br />&gt; <br />&gt; <br />&gt; <br />&gt; Well, so much for THAT theory.  If I set leftprotoport or rightprotoport<br />&gt; <br />&gt; to ANYTHING, it won&#39;t load the conn and gives me no error in the logs<br />&gt; <br />&gt; what so ever and the conn does not show up in ipsec auto --status at<br />&gt; <br />&gt; all.  I tried setting rightprotoport=17/500 and leftprotoport=17/500 and<br />&gt; <br />&gt; 17/4500 and even the example from the man page of 17/1701 for l2tp and<br />&gt; <br />&gt; the connection just no longer appears.  No error, no connection.<br />&gt; <br />&gt; Sigh...<br />&gt; <br />&gt; <br />&gt; <br />&gt; &gt; Let me know if you think of anything you want me to try and test while I<br />&gt; <br />&gt; &gt; poke at this some more.<br />&gt; <br />&gt; &gt;<br />&gt; <br />&gt; &gt; &gt; Paul<br />&gt; <br />&gt; &gt;<br />&gt; <br />&gt; &gt; Mike<br />&gt; <br />&gt; <br />&gt; <br />&gt; --<br />&gt; <br />&gt; Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw@WittsEnd.com<br />&gt; <br />&gt;    /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/<br />&gt; <br />&gt;    NIC whois: MHW9          | An optimist believes we live in the best of all<br />&gt; <br />&gt;  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!<br />&gt;