[Openswan Users] Connection against a Lucent FW success!!!! but may be there's still room for improvement

[Rolando Zappacosta]

Hi Paul,

long time since I got this working, again thank you. Now, I got in touch with someone else trying to connect against a Lucent Brick Firewall and... success too!!!

Things worth mentioning:
  1) he connects against a Brick with a vendor ID different than one I do. You can add this one too if you want, it's:
   4C5647392E312E3137303A425249434B3A392E312E313730
that stands for this version of the LVG:
    L V G 9 . 1 . 1 7 0 : B R I C K : 9 . 1 . 1 7 0
  2) Connfirmed my theory about the way Alcatel-lucent actually handles the PSK. This guy has an 8 ASCCI chars long PSK and he actually had to configure the secrets file as "<his 8 ASCCI chars long PSK>012345678901". So as you can see, it worked adding as many 0 to 9 ASCCI chars as needed to have a 20 chars long string.
  3) we still miss a way to encapsulate the traffic to the LVG under UDP port 500 packets to bypass NATing stuff in the middle.

HTH,
Rolando.



--- On Wed, 9/10/08, Paul Wouters <paul at xelerance.com> wrote:

> From: Paul Wouters <paul at xelerance.com>
> Subject: Re: [Openswan Users] Connection against a Lucent FW success!!!! but may be there's still room for improvement
> To: "Rolando J. Zappacosta" <zappacor at yahoo.com.ar>
> Cc: users at openswan.org
> Date: Wednesday, September 10, 2008, 6:39 AM
> On Tue, 9 Sep 2008, Rolando J. Zappacosta wrote:
> 
> > > If you have the logs from the lucent side, to see
> what vendorid is logged
> > > on their side, I'd be interested so we can
> add it to our own recognised
> > > vendor list (and possible take action based on
> it)
> > I discussed this subject here:
> >
> http://lists.openswan.org/pipermail/users/2008-February/014030.html
> based on
> > what I could capture under Windows, the relevant part
> of it is:
> > "I'm trying to connect OpenSwan to a Lucent
> VPN Gateway, which according to
> > its ASCII interpretation of its Vendor ID payload is:
> >
> 4C5647392E312E3235353A425249434B3A392E312E323535="LVG9.1.255:BRICK:9.1.255".
> I
> > can connect to it by means of the Lucent VPN Client
> V7.1.2 on a Windows XP
> > computer (Vendor ID=
> 4C5643372E312E323A5850="LVC7.1.2:XP")."
> 
> Thanks. Normally vendorids are md5sum's of some text,
> though in this case
> that does not seem to be the case. I added them as-is to
> vendor.c for now.
> 
> > Seems one can know the running version of the client
> and server just looking
> > on the vendor id part of an ASCII capture dump.
> > Interesting thing is, as explained to you privatelly,
> the way the PSK gets
> > handled here. Under the LVC (windows) I had to
> configure a PSK like:
> > <MyCompanysPSK> where the real PSK is 9 ASCII
> characters long. However, I
> > could find that in order to have OSW establishing
> phase 1 succesfully I had to
> > add the string "01234567890" as a trailer,
> i.e. my ipsec.secrets looks like:
> > !@#$% <MyCompanysGWipAddress> : PSK
> "<MyCompanysPSK>01234567890"
> > 
> > what gives a PSK of lenght 20. Not sure on how they
> handle it but my guess is
> > they just take the PSK the user configures, add the
> string
> > "01234567890123456789" and take the first 20
> bytes of it. Easy way to hook you
> > on their client while still keeping it simply to
> develop.
> > 
> > And I'm not sure if the user !@#$% is the one the
> GW admin configured on it or
> > if it's the way they handle it but whatever else I
> configure, the GW just
> > don't respond anything back to me.
> 
> Thanks! I put a note of this in docs/lucent-client.txt, and
> it will end up
> in the new wiki once we have it online.
> 
> > > Looks like a resend, you can ignore it.
> > Strangely, I *always* do receive the duplicate packet
> warning. Another
> > interesting thing is Lucent's VPN client
> doesn't exchange any CFG at all...
> > I'm wondering now if I need it indeed. The server
> sends it to me but seems
> > like OSW only configures the local IP address based on
> it. I supossed it was
> > going to be able to configure something else, such as
> DNS or things like that.
> 
> Openswan does support DNS/WINS via XAUTH/ModeConfig. Though
> as a client, we
> might be ignoring it, since we have no structured way of
> modifying resolv.conf
> in any modern way (eg dbus/networkmanager). I believe we
> might only pass it
> as env variables to the updown script.
> 
> > The LVC do more things with no CFG at all, configures
> the DNS and WINS servers
> > for instance, something I'll need to do manually
> via a script (or can it be
> > made automatically somehow by OSW?)
> 
> You can copy the stock _updown script and add resolv.conf
> rewriting to it,
> and configure the new script using leftupdown=
> 
> > > > and this one from pluto's debug:
> > > >  3) "Intranet" #1: XAUTH:
> Unsupported attribute: INTERNAL_ADDRESS_EXPIRY
> > > You can also ignore this. Openswan does not
> support INTERNAL_ADDRESS_EXPIRY,
> > > so it wont drop the IP address or ask for a new
> one.
> > Same for "ignoring informational payload, type
> IPSEC_RESPONDER_LIFETIME"
> > above?
> 
> Yes. the remote is telling us how long they will keep the
> SA around. Openswan
> does not really care what the remote does. If the remote
> wants to rekey, it
> will and can do it anytime. We do enforce our own SA life
> similarly.
> 
> Paul