Client   ->       Client Router        -> CLOUD <-        Server Router          <- Server <-NAT->    <-NAT->
  • I have control over the server router. It has multiple routable public IP addresses - let's say through
  • 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 I have configured that router to forward all traffic that it sees coming to over to the server at Clients would connect to
  • The server router is an appliance and thus it cannot run the IPsec server itself.
  • The server itself believes its IP address to be, but as I said, it is reachable at 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.
  • 1
    ESP only. AH signs the entire packet so NAT will break things.
    – Ricky
    Commented Apr 21, 2016 at 21:28
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Commented Jan 5, 2021 at 18:35

2 Answers 2


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



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 =          Virtual Interface/Tunnel IP = /29
Spoke 2 =       Virtual Interface/Tunnel IP = /29
Hub Virtual Interface/Tunnel IP = /29   (can support 5 spokes)

Client can now ping Server Client 1 is connected to Spoke 1, Spoke 1 will have a route to 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.

  • "PAT'd NATing" Please, RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations explains the proper terminology: NAPT. "NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address."
    – Ron Maupin
    Commented Jun 4, 2018 at 5:56
  • Thanks never knew the correct terminology, updated the answer to include correct terminology.
    – neoakris
    Commented Jun 4, 2018 at 8:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.