multiple clients behind the same NAT connecting a L2TP/IPsec VPN server behind another NAT

VANHULLEBUS Yvan vanhu at FreeBSD.org
Thu May 12 09:17:56 UTC 2011


Hi.


On Wed, May 11, 2011 at 09:43:35PM -0300, Dr. Rolf Jansen wrote:
> I have setup a VPN-Server on my FreeBSD 8.2 Release i386 machine, using the following requisites:
> 
>   - customized GENERIC Kernel builded with the following
>     additional options and devices:
>     IPSEC, IPSEC_FILTERTUNNEL, IPSEC_NAT_T, crypto, enc
> 
>   - ports/security/ipsec-tools (v0.8.0)
>     compiled with NATT enabled and NATTF disabled

On a FreeBSD 8.2, NATTF enabled/disabled will change nothing, it is
just here to ensure NAT-T support is available and break compilation
if it is not.



>   - ports/net/mpd5 (v5.5)
> 
> 
> The server sits in the DMZ behind a SOHO router. Everything is
> working fine so far. I can establish connections from multiple
> external clients at the same time. Even connections from within a
> NAT'ed local network via the internet to my L2TP/IPsec server do
> work.

Which is already good news, as no one AFAIK really worked hard on such
setups...



> The only remaining problem is, that from behind the same NAT only
> one client works well. As soon as a connection between a second
> client and the server has been established, the communication of
> both break down. The racoon log shows nothing noticeable here, and
> according to the log both connections are established successfully,
> anyhow, the communication is blocked.

Sounds like something (racoon ? kernel ? both ?) handles ports in a
bad way in transport mode....

Could you send an example of such generated policies/SAs ?

Be careful to use setkey from ipsec-tools (/usr/local/sbin) and NOT
from system (/sbin/setkey) to have all NAT-T related informations.



> racoon is configured to generate unique policies.

A bit more strange.... SAs should be really hard linked with SPDs, and
even with a confusion with ports, they should be considered as NOT be
for the same tunnel.....


> When a client disconnects from the server, racoon usually purges 2
> IPsec-SA shortly after. The interesting thing in the case of 2
> clients from the same NAT is, that it purges one IPsec-SA from the
> client just disconnected, and 1 belonging to the client that is
> still connected. So, it seems that the internal SA house holding of
> racoon got confused.

See in racoon's debug (-dd to have more verbose) if decision comes
from racoon, from peer (I don't think so) or from the kernel (via a
PFKey message).

Be careful if you send such output to the ML, as it includes some
confidential datas (IPs, PSKs, etc....).


> I am investigating this already for some days, and finally I would
> like to ask to the experts, whether this is perhaps an issue of the
> ipsec-tools (racoon/setkey), and not with my setup. I am willing to
> spent more time on this only if there is some chance that this can
> be resolved.

There is "some chance", but this may involve userland and/or kernel
patching...


> 
> So, is there anybody out there, who can successfully establish VPN
> connections from multiple clients behind the same NAT to a
> L2TP/IPsec Server running ipsec-tools and mpd5?

I know that multiple NAT-T behind the same peer will work in *TUNNEL*
mode, but I never tested that in TRANSPORT mode.


> BTW: Using only mpd5, I setup also a PPTP-VPN server running in
> parallel to the L2TP/IPsec one. Multiple PPTP-VPN clients behind the
> same NAT work perfectly well with my server - So, I tend to believe
> that it is really an issue with the IPsec part and not with the L2TP
> (mpd5) part of my setup.

I don't know MPD so much, but it really does look like an IPsec
related issue.


Yvan.


More information about the freebsd-net mailing list