Can I do a pure IPSec VPN (no L2TP) with NAT-T where the server is inside a NAT?

Question

Topology:

Client   ->       Client Router        -> CLOUD <-        Server Router          <- Server
10.0.1.5    10.0.1.1 <-NAT-> 100.1.1.1             200.1.1.1 <-NAT-> 192.168.1.1    192.168.1.100

• I have control over the server router. It has multiple routable public IP addresses - let's say 200.1.1.1 through 200.1.1.6.
• The server router provides NAT to all of the machines behind it. The IPsec server is running on one of the machines on the NAT network at 192.168.1.100. I have configured that router to forward all traffic that it sees coming to 200.1.1.2 over to the server at 192.168.1.100. Clients would connect to 200.1.1.2.
• The server router is an appliance and thus it cannot run the IPsec server itself.
• The server itself believes its IP address to be 192.168.1.100, but as I said, it is reachable at 200.1.1.2. The router forwards only on destination IP, so IKE/ISAKMP/etc packets should be able to be forwarded directly to the server from the router.
• It is not possible to move the VPN server into a configuration where it has direct knowledge of its publicly routable IP. (i.e. it cannot be moved so its network interface connects directly to the Internet, but must instead remain behind the NAT and have traffic forwarded to it.)
• I do NOT have control over the client router. It puts all clients behind a NAT. It does have IPsec VPN Passthrough enabled.
• I could likely make this work with L2TP but would prefer to do pure IPsec if it is possible.

Just to eliminate the chance that I'm completely clueless, my understanding of IPsec is as follows:

• An IPsec/L2TP VPN establishes an IPsec tunnel between two endpoints. It then passes L2TP traffic over that tunnel. L2TP traffic is not encrypted, so IPsec serves as the encryption method, while L2TP serves as the "VPN".
• A pure IPsec VPN would instead directly transmit IP packets over the IPsec tunnel. A client machine could perform a standard DHCP request over the tunnel, receive an IP address from the far end's DHCP server, and then transmit raw IP packets over the IPsec tunnel as they would appear if the client device was directly connected to the far-end LAN.
• In L2TP/IPsec, the L2TP server handles IP address assignments; in pure IPsec, it is just as if you plugged a LAN cable into the remote LAN and thus whatever infrastructure is there is what you connect to.

If I'm wrong, please correct.

So my questions are:

1. Is there anything preventing me from doing a pure IPsec VPN in this topology?
2. I'm using Linux and would be using the Swan series (Strongswan/Openswan perhaps) of IPsec servers. Is there a way to accomplish this using these tools? The clients would be iOS devices, Macs and possibly a couple of Windows PCs.

Answer 1

Nothing prevent you to do this. The NAT-Traversal is your friend, it will encapsulate (part of) IPSEC in UDP on port 4500.

You will find some information in rfc3715 and rfc3947

The tricky part is that you cannot use the peer IP address as the identity, (especially with StrongSwan where this is the default I think - unsure) so you must declare in your configuration the identity of each host (usually in the form of @id).

Answer 2

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/xe-3s/sec-conn-dmvpn-xe-3s-book/sec-conn-dmvpn-dt-spokes-b-nat.pdf

Based on that website you need at least one router that's not doing NAPT(Network Address Port Translation)/(NAT overloading), which I'm guessing both of your routers are doing.

No worries, all you need to do is add in a hub router with a Static WAN IP.
Make Client Router => DMVPN Spoke 1
Make Server Router => DMVPN Spoke 2
Provision a VyOS Router on AWS => DMVPN Hub with Static WAN IP for super cheap.

DMVPN = GRE Tunnel in IPSec Tunnel with NHRP
(The GRE tunnel allows multicast)
(Multicast means you can configure OSPF Routing Protocol over the tunnel interfaces)
Spoke 1 forms an IPSec Tunnel with DMVPN Hub
Spoke 2 forms an IPSec Tunnel with DMVPN Hub
Configure OSPF/EIGRP on DMVPN Spoke 1, DMVPN Spoke 2, and DMVPN Hub)

The end result is 
Spoke 1 = 10.0.1.1/16          Virtual Interface/Tunnel IP = 192.168.255.1 /29
Spoke 2 = 192.168.1.1/24       Virtual Interface/Tunnel IP = 192.168.255.2 /29
Hub Virtual Interface/Tunnel IP = 192.168.255.6 /29   (can support 5 spokes)

Client 10.0.1.5 can now ping Server 192.168.1.100. Client 1 is connected to Spoke 1, Spoke 1 will have a route to 192.168.1.0/24 network on its tunnel interface, and it'll just route traffic to it.

---

Note some routers can't do DMVPN or have it has a paid feature. Normal IPSec Tunnels can't pass multicast traffic (and therefore routing protocols won't work), if you're in that boat you have Plan B and Plan C. Plan B is to look into VTI's (they're a newer IPSec based VPN technology that inherently supports multicast traffic). Plan C is to have Spoke 1 form a IPSec Tunnel with a Hub, Spoke 2 to form a IPSec Tunnel with a Hub, Put GRE tunnels inside both of the IPSec Tunnels, and then enable OSPF. It's basically DMVPN but with slightly more configuration.