Statement on support of multiple clients using transport mode and
patrickn at xelerance.com
Wed May 10 13:24:41 CEST 2006
Statement on support of multiple clients using transport mode and L2TP
Currently Openswan, both with KLIPS and NETKEY, will show unexpected
behavior with the use of NAPT/NAT (IP Masquerading) at either the
source end or destination end, combined with transport mode.
Many users have reported problems on the Openswan mailing lists.
Xelerance has been aware of these issues even before the users
started experimenting with using Openswan in transport mode.
Transport mode is necessary with the use of L2TP to connect from a
Windows (or OSX) platform to an Openswan server, using Windows (or
OSX) native IPsec clients.
A few issues with NAT support and MTU problems appeared at the time
of the 2.4.x series, which muddied the waters a bit. Work arounds for
OSX and Windows had to be added to the NAT-detection in pluto code,
and some problems in "vhost" code as well as some NAT related rekey
errors showed up during at this time.
The NAT detection fixes were merged into the current 2.4 series. The
"vhost" patches are being merged into the development public code.
They will be rolled into a numbered release in the future.
Here is where the Openswan software stands at this time:
NETKEY uses the external IP as an SA identifier. Kernel magic is
used to support this. This means that multiple clients connecting
from behind the same home firewall will not work. One will, but not
multiple. This also means that multiple home users will be able to
connect from behind their respective firewalls at the same time, as
long as they are alone at their origin. Also, workarounds needed to
be added to ensure one L2TP/IPsec and other non-encrypted clients
from behind the same NAT router would work. This is an important
issue in some of the larger deployed GPRS networks.
KLIPS uses the internal IP as an SA identifier. This means that
multiple clients connecting from behind the same home firewall could
work, but a additional policy bug in the 2.4.x versions actually made
this functionality undependable, particularly when using templated X.
509 based connections.
The current KLIPS logic also meant that multiple home users could not
connect to an Openswan server if each was using the same source IP;
this is very common as Linksys routers will issue DHCP address from
192.168.1.101 and up.
Chances are that each of your 100+ home users connecting to your
Openswan server will have 192.168.1.101 as a source IP address from
behind the Linksys. Netgear and others have the same problem.
The result is that the L2TP server residing on the Openswan server
has no way of uniquely identifying multiple users using the same
source IP, regardless of which IPsec stack is used.
Our solution was to modify KLIPS, pluto, iptables and l2tpd.
There is a new API interface between KLIPS and l2tpd, mediated by the
IP and UDP socket layers.
We forked the l2tpd project, since the current l2tpd developers did
not respond to our emails nor process our patches. Our fork is named
xl2tpd. It is hosted at our site. The new option "ipsec saref"
enables the new API interface functionality. The iptables changes
have been submitted to upstream for inclusion. The pluto code was re-
factored to better handle NAT-T, and fixed some of the "vhost" bugs
related to the Virtual IP selection and rekeying.
All told, Xelerance spent $70,000US of development time to create
this functionality. We did this because a sponsor approached us to
create the functionality. The unfortunate thing was that the sponsor
could only cover a fraction of the development cost.
The functionality has been delivered to the sponsor, and is being
used at this time internal to the sponsor.
The good news is that the resulting API into userland forms the basis
of some work that is relevant to the IETF BTNS workgroup's efforts
The bad news is that Xelerance will not release this Openswan
functionality into the general code base until such time as our
development costs have been covered by sponsors.
We are looking for $55,000US from the community.
As a company, if you are interested in sponsoring this functionality,
please contact us immediately. As an individual, if you are
interested in sponsoring this functionality, you will most probably
have to approach other individual users and pool your resources.
We hope to be able to start work on our next project soon, which is
the "merging" of the KLIPS and NETKEY to provide one unified stack
that is satisfactory to both the Linux kernel maintainers and the
You can reach us at sales at xelerance.com
Chief Executive Officer, Xelerance Corporation
More information about the Users