
helper program to interop with non-rfc IPsec implementation of Lucent.

From Rolando:

Lucent's way to work around NATing is to change this:

   | IP | whatever L4 proto | Payload |

where IP has the (IP source; IP dest) within it into this:

   | IP | UDP:XXX | IP | whatever L4 proto | Payload |

where IP have the same (IP source; IP dest) within them and XXX is the
configurable UDP port (default=501)

In a nutshell, they "tunnelize" all the traffic to/from the client and
the gateway into a IP/UDP:XXX header

May be there are better ways to do it but using iptables QUEUE is the
one we used to encapsulate/decapsulate. I thougth about adding it to
OSW code as well as some code to make it manipulate iptables QUEUE stuff
but got lost on it. :-(


---------- Forwarded message ----------
Date: Sun, 5 Apr 2009 10:36:54 -0700 (PDT)
From: Rolando Zappacosta 
Cc: users@openswan.org
To: Paul Wouters <paul@xelerance.com>
Subject: Re: [Openswan Users] Connection against a Lucent FW success!!!! but may
      be there's still room for improvement


Hi all,

I could finally manage to get OSW to work against a Lucen VPN Gateway
even through NAT. So, in case someone else needs such connection,
compile below code and then run this:

    modprobe ip_queue
    UDP501encap &
    iptables -A OUTPUT -d IPofLucentGW -j QUEUE
    iptables -A INPUT -s IPofLucentGW -j QUEUE

before launching OSW as usual.


> 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



