[Swan] Possible to setup multiple connections, partly behind NAT?

[hrusa at inmail.cz]

> If you have NAT, then you no longer have a host-to-host connection. What
> internal IPs should be used? Some end has to hand out an IP address for
> the other end to use.

Just to be sure: does NAT between the participants imply net-to-net even if:

- none of the boxes involved is itself doing the NAT,
AND
- none of the boxes involved is routing traffic for others?

(my intended setup meets these criteria)

> If you have two subnets that you want to have "meshed", you should build
> a net-to-net connection between the two gateways of those subnets, so

I do not need a full mesh between two subnets, at least not now. Currently, 
I only need various clients to connect to a server. On a LAN without NAT, 
this works flawlessly. I ran into problems when trying to access the server 
from behind a (multiple) NAT.

The client is behind a usual ISP NAT (10.0.1.x natted to a single public 
203.0.113.55). On the respoder end, the server has 192.168.1.253, which is 
then natted to a public 198.51.100.33 (not by the server itself). In 
addition to a regular NAT on the server end, udp/500, udp/4500, esp and ah 
are forwarded to 192.168.1.253 (the server internal IP).

I was actually thinking that this was basically a common roadwarrior setup, 
and the setup from

	https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

would work (hence the left|rightsubnet=0.0.0.0/0 options applied before). 
Now this assumption seems to be wrong.

So, given the above, should I instead use the setup described in

	https://libreswan.org/wiki/Subnet_to_subnet_using_NAT ?

And if so,

- what should I use in left= for the server (its interface does not use the 
public IP (I have just the port/protocol forwards described above)?
- what leftsubnet=/rightsubnet= should I use?

Or am I perhaps completely missing the point?

> that all the mesh nodes are not even aware of the NAT in the middle.
> 
> > pluto[22373]: "headq" #2: dropping unexpected IKE_AUTH message containing TS_UNACCEPTABLE notification; message payloads: SKF; encrypted payloads: IDr,CERT,AUTH,N; unexpected payloads: IDr,CERT,AUTH
> 
> Because the nodes are now using their pre-NAT IP which cannot be
> trusted. Eg I could say I am 8.8.8.8 pre-NAT and steal your google DNS
> traffic. One end is suggsting a connection of internalIP1-PubIP1, and
> the other end is suggestion internalIP2-PubIP2 and thus they won't agree.

Both of the pre-NAT IPs are within RFC-1918. Doesn't that make any 
difference?

One more idea: would perhaps using leftid=<server.pub.ip> on the server end 
do the trick (AWS-like setup)? And if so, can I keep the (my) standard 
%fromcert on the remote (initiator/client) side?

Finally, as a side note: the list messages seem to reach me much more often 
recently. Thanks.

Best regards,

Phil