[Openswan Users]

[Jacco de Leeuw]

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?

> 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.

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

> 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.

> 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.

That's a considerable amount of money. Most individuals and companies
on this list probably won't be able to afford it.

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

> 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? What if the kernel maintainers don't accept the NAT-T changes?
Or are the NAT-T changes withheld from merging with the Linus kernel
as long as the money has not been raised?

Jacco
-- 
Jacco de Leeuw                         mailto:jacco2 at dds.nl
Zaandam, The Netherlands           http://www.jacco2.dds.nl