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

[Paul Wouters]

On Wed, 21 Feb 2024, hrusa at inmail.cz wrote:

> Subject: Re: [Swan] Possible to setup multiple connections, partly behind NAT?

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

The core problem is you need to agree on the src/dst IPs of the tunnel.
The party behind NAT only has its pre-NAT IP available, unless it
receives another IP from the other end.

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

No need to forward ESP or AH, as everything will happen over udp/500 and
udp/4500. You can give your server side an addresspool and assign IPs
from it for all roadwarriors that connect, irrespective of whether they
are NATed or not. Pick a small addresspool that does not likely clash
with regular pre-NAT IP configurations.

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

On the client you would use that along with narrowing=yes, although in
your case I guess you can give the client a leftsubnet=0.0.0.0/0 that
will get narrowed to the addresspool IP by the server, along with
rightsubnet=192.168.1.253/32 if you only need to reach that server,
or rightsubnet=192.168.1.0/24 to make the entire subnet available.
(this assumes left is local and right is remove for your client config)

On the serverside, you use leftsubnet=192.168.1.253/32 (or 192.168.1.0/24)
with rightaddresspool=192.0.2.0/32 (that is a reserved IP range not often
used by others) (this assumes left is local and right is remove for your
server config)

> So, given the above, should I instead use the setup described in
>
> 	https://libreswan.org/wiki/Subnet_to_subnet_using_NAT ?

No.

> - 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)?

left=%defaultroute or if you know it has a static (pre-NAT) IP, use
left=YourIP. You use right=%any
(assuming left is local again)

> - what leftsubnet=/rightsubnet= should I use?

See above. leftsubnet= with rightaddresspool=


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

No, the IKEv2 code no longer makes any assumptions anymore about what
are valid pre-NAT IP ranges (IKEv1 used the virtual-private= for that)

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

Since your IPs are not good identifiers because of NAT, it is better to
use either strings, eg leftid=@VPNserver and rightid=@client13 or when
using X.509 certificates, use leftid=%fromcert and rightid=%fromcert
(or leftid=@SANname if your certs have a proper SAN)

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

Yes, Tuomo pleased the gmail gods.

Paul