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

[Paul Wouters]

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