1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
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 thought about adding it to
LSW 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@libreswan.org
To: Paul Wouters <paul@xelerance.com>
Subject: Re: [Libreswan Users] Connection against a Lucent FW success!!!! but may
be there's still room for improvement
Hi all,
I could finally manage to get LSW 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 LSW as usual.
> I discussed this subject here:
>
> https://lists.libreswan.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 LSW establishing
> phase 1 successfully 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 length 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 LSW 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.
>
> Libreswan 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 LSW?)
>
> 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. Libreswan does not
> support INTERNAL_ADDRESS_EXPIRY,
>>> so it won't 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. Libreswan
> 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
|
