First off, my apologies for the speculations at the end
of my previous post. They probably don't belong on the
list. I guess I got a little bit carried away...
However, I've now got this client working with through
a combination of FreeS/WAN, l2tpd and pppd.
It seems to work but I don't know how robust l2tpd is.
Jason A. Pattie wrote:
> test810-vmware-msl2tp" #1: peer client ID payload ID_IPV4_ADDR
> specifies protocol 17; we only support 0
That's odd, I have not seen this error in my logfiles.
What version of FreeS/WAN are you using? There's not much
to configure in this Microsoft client, so I wonder
what the difference could be between our two systems.
Perhaps you could list what protocols/adapters you have
in your Network settings? I understand you use a PSK,
I have only tested with a cert. But that can't be it,
can it?
Come to think of it, when I ping the FreeS/WAN host
after the IPSEC SA has been set up, the Microsoft client
sends ICMP packets in the clear while the FreeS/WAN host
responds through the IPSEC tunnel. Reading back DHR's post
(http://lists.freeswan.org/pipermail/users/2002-January/006926.html)
I get the impression that something fishy is going on.
Perhaps the Microsoft client (in my setup) is lying that
it will tunnel all traffic while in reality it only
tunnels L2TP (UDP 1701)?
Sam Sgro wrote:
> Jacco mentions that he ignored most of the settings in the
> MS configuration, as they seemed to relate to L2TP specifically.
Correct. At the time I did not bother changing the default
settings of the 'dial-up' part because they have nothing to do
with IPSEC. There is a seperate configuration utility which
does deal with IPSEC settings but it is limited to choosing
between PSK or certs, and enabling/disabling logging.
Stephen J Bevan wrote:
> I inferred from Jacco's message that it is not necessary as
> long as you don't enable L2TP on the Windows side of things.
You cannot disable L2TP in this client. Well, perhaps you can
through registry hacking but I haven't looked into that.
Jason A. Pattie wrote:
> Do I want to use L2TP?
Preferably not, but currently the IPSEC part alone is not that
useful. It only seems to allow tunneling L2TP, as my ping test shows.
So currently, I guess you have the following options if you
want to use this free *) Microsoft client with FreeS/WAN:
- you install l2tpd/pppd and get it working
or:
- you hack the registry to disable L2TP and possibly enable
features which can otherwise be found in the full SafeNet
client.
It would perhaps be interesting to compare the registry settings
of the full SafeNet client with its crippled offspring supplied
to Microsoft. Anyone?
*) As in beer, not speech. Obviously.
> I hope to be able to also allow the Windows client(s) to connect
> to the interal network that the security gateway is part of.
> Is that possible using the L2TP/IPSec Windows client?
Yes. However, I guess L2TP adds more overhead than, say, the
virtual IP, Mode Config and DHCP options. Since L2TP is
essentially tunneling PPP, you get the overhead of both L2TP
and PPP. I haven't measured yet how much overhead this is.
The advantage of L2TP though is that you can even tunnel
IPX and NetBEUI, but I haven't tested that.
> I didn't see any sort of "remote network" configuration items
> in the Windows client.
You configure that part by creating a new "Dial-Up Networking"
entry, where you specify the "Microsoft L2TP/IPSEC adapter"
and the protocols you want to use. It works exactly as if you
are configuring a PPTP connection, only the adapter if different.
In most cases the Windows user does not have to configure much
since the L2TP/PPP server provides the settings automatically.
It's mainly the username and password address which will have
to be entered.
Sam Sgro wrote:
> Jacco's mail was able to make his connection work via X.509 certs with
> little trouble. However, he didn't test a host-to-subnet connection,
I have just finished a quick test with l2tpd. I'm actually surprised
that it worked without hacking source code or so, but I still got the
"not enough room / malformed packet" errors. I also saw some
"read errors" in l2tpd but these may or may not be the result
of the malformed packets.
I could not find a source RPM for l2tpd, but the tarball compiled
out of the box. I more or less used the sample configuration file.
Unfortunately, there was no sample PPP configuration file supplied.
It is fairly easy to create one but finetuning will take some
time.
It occurred a couple of times that the Microsoft client thought
that it was (still) connected but l2tpd/pppd didn't, and vice versa.
I made some silly errors, for example, I had not filled in
a default gateway and DNS/hostname details in the Windows
machine. l2tpd then started complaining about "Specify your
hostname". I also had to start l2tpd as a daemon using the
-D parameter, otherwise pppd ran into a problem with ttys
due to a bug in l2tpd. Another thing was that pppd kept
looking at /etc/ppp/chap-secrets for the usernames/passwords,
although I had specified a diffent secrets file in
l2tpd.conf. Still haven't solved that one.
> there doesn't seem to be any clear documentation about this
> product online. This client is new (to us, at least) so there are
> no established protocols for interoperating with it.
That's what we are here for, sharing ideas and knowledge :-).
Jacco
-- Jacco de Leeuw mailto:jacco2_at_dds.nl Zaandam, The Netherlands http://www.jacco2.dds.nl Windowsupdate: "This is done without sending any information to Microsoft". (Honest, guv!)_______________________________________________ Users mailing list Users_at_lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:24 CEST