[Openswan Users]

[Paul Wouters]

On Sun, 14 May 2006, Jacco de Leeuw wrote:

> I didn't see any replies yet so I thought I'd respond.
>
> Patrick Naubert wrote:
>
> > 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.
>
> This is an issue in Openswan and not in the NAT-T standard, right?

Yes, it is a limitation in the IPsec NAT-T standards.
It is an issue with the protocol, for which a lot of code had to be written
to distinguish various "identical" IP addresses used in different locations.

> Are the Linux kernel maintainers aware of this issue? If they were to
> fix it, would this benefit Openswan?

Yes they are. We hope to merge the two stacks in the future (along with OCF)
and fix this once and for all.

> > KLIPS uses the internal IP as an SA identifier
> > 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.
>
> Doesn't this break the principle of abstraction between network layers?
> Those who are using a different L2TP implementation such as rp-l2tp or
> l2tpns would have to modify these implementations too.

There is no choice. You must distinguish 192.168.1.101 from 192.168.1.101
on another linksys box. Yes, those implementations would also need to be
fixed to support this. xl2tpd source code is out there, so anyone can port
the userland partion of the patch already if they desire to use another l2tp
daemon.

> Do other IPsec implementations such as OpenBSD, Win2003 and Mac OS X Server
> have the same NAT problem?

If they do not have code dealing with it, yes they do. It is likely Microsoft
and Cisco have done this. I am not sure about OSX. I'm pretty sure no open
source software has fixed this before us.

> And protocols such as OpenVPN and PPTP?

Those are application level packet handlers (with all the dangers that
implies as we saw in last week's openvpn vulnerability). They are not
L2TP/IPsec transport mode programs, so they do not run into transport mode
with NAT issues.

> > 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 IPsec endusers.
>
> Wouldn't it have been easier to add this NAT-T functionality after the
> merging?

Do you want to wait more then 6 months for this functionality. Besides,
the API we have designed should be the same as the one that will be adopted
by the IETF BTNS working group, so it will become a standard. So we are
not wasting our time. The merger of OCF/netkey/klips, and the acceptance
of the code will not happen overnight.

> What if the kernel maintainers don't accept the NAT-T changes?

The kernel people are just as anxious as we are to make the whole netkey
versus klips issue go away. We are working with them on this.

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155