Issue #3232

tunnel in tunnel

Added by Tom Hsiung almost 2 years ago. Updated almost 2 years ago.

Affected version:


Hey, guys

I made some test. After the site-to-site tunnel had been established, I connected my client 1 to gateway B in roadwarrior mode.

client 1 is within gateway A's subnet, and according to the site-to-site configuration, its traffic would flow into the site-to-site tunnel.

Gateway A === gateway B (site-to-site)
Client 1 === gateway B (roadwarrior)

So, when the roadwarrior mode is connected, traffics from client 1 should be encapsulated twice. One encapsulation by client's own IPsec package, and another encapsulation by the gateway A. In theory, the packet would contain two sets of IPsec headers (new IP headers, ESP, etc.).

But the test showed it was not so. The new headers for roadwarrior (fake NAT enabled by force) and site-to-site (force fake NAT disabled) are 100 bytes and 54 bytes, respectively. So by sum, the new headers of packets encapsulated twice should be 100 + 54 = 154 bytes. But my test showed that with site-to-site and roadwarrior both "connected", the new "headers" in total took up 100 bytes.

So I guess it is probably that there was no twice encapsulation in this case.


Related issues

Is duplicate of Issue #542: Nesting tunnelsFeedback06.03.2014


#1 Updated by Tom Hsiung almost 2 years ago

I meant the multiple layers of tunnel. But I found this,

the Linux kernel does not allow multiple ESP encryptions or decryptions. You can have multiple layers of IPsec encryption if you terminate the individual layers on different machines, e.g. one on the physical host and one on a VM running on the physical host.Each endpoint would also have to run an IKE daemon.

So, the case is due to that they both terminate at a same machine. Thank you.


#2 Updated by Tobias Brunner almost 2 years ago

  • Category set to kernel
  • Status changed from New to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Duplicate

Nesting IPsec SAs might actually be possible on modern Linux kernels (e.g. using marks that are set after an SA is applied), however, the main issue is using IKE through a tunnel terminated on the IKE host. strongSwan uses bypass policies on its sockets to avoid that IKE traffic is affected by IPsec, so this currently can't be done (there is an option to use regular policies instead, but without tweaks that would still not allow IKE traffic to be tunneled).

#3 Updated by Tobias Brunner almost 2 years ago

  • Is duplicate of Issue #542: Nesting tunnels added

Also available in: Atom PDF