[Ipsec-tools-devel] Road warriors with the same local IPs

[Robie B. <ro...@8n...>]

Hi,

I think this is an implementation issue, rather than standards, hence 
the post here.

I have Linux<->Windows XP Native VPN client working in a non-NAT
arrangement. I can't get it to work with NAT, and I don't quite follow
how this would work. Would there not automatically be IP address
conflicts with multiple home users connecting with local IPs of
192.168.0.2 and so forth?


This is a very common scenario for home workers and road warriors:

All addresses starting R are globally available IP addresses (R for
Real).

Client: 192.168.0.2 (behind NAT)
NAT device: 192.168.0.1, live address R.0.0.1
Server: R.1.0.1

192.168.0.2   192.168.0.1   R.0.0.1               R.1.0.1       10.0.0.1
client-------------------NAT----------Internet----------server-------LAN
  (XP)                                                   (Linux)
                                                            |
                                                           IPsec
                                                            |
                                                        L2TP daemon

Let's say that the L2TP daemon is required at the moment, or just treat
it as a UDP application that the client needs to connect to.

Where does the L2TP daemon see a connection from the client as coming
from, once IPsec is fully set up?

If it sees 192.168.0.2, then what happens when two clients connect with 
this arrangement, and both are using 192.168.0.2 at home?

If it sees R.0.0.1, then how does this work with multiple clients behind
the same NAT device that decide to use the same source port number for 
the connection?

The IPsec layer does know how to identify between different clients, as
the encapsulating UDP packet uniquely identifies this. However, how is 
this passed to the L2TP daemon? Unless the L2TP daemon is getting some
additional knowledge apart from just untunnelled packets, it cannot get
this information. Doesn't the L2TP daemon get only the contents of
sockaddr_in?

I think this is what section 2.1.e in RFC3715 is referring to.

Am I missing something?

If I'm right, then what are the possible solutions? Does anything exist
at the moment? It seems to me that the only way this could work is 
enough knowledge in whatever is demultiplexing the UDP packets to deal 
with L2TP/PPP itself. Once untunnelled from L2TP and PPP, then the 
packets will have addresses only allocated from the server's pool so 
there won't be any conflicts.

Is this why Microsoft use L2TP for this? It needs to get a local address
on the remote subnet somehow, so that other applications work seamlessly.

How do I set up a Linux gateway to be able to take connections like this?

Cheers,
Robie.