2

I have server connected with remote LAN1 over IPSec tunnel. Now I want to setup second tunnel to LAN2 which is connected to router in LAN1, so I need to create Ipsec tunnel inside existing ipsec tunnel:

LAN0 -- server -- internet -- GW1 -- LAN1 -- GW2 -- LAN2
            ====== IPSEC1 =====
           ============ IPSEC2 ================

IPSEC1 is working fine, I can ping GW2, but IPSEC2 is not working. I can't change GW1 configuration, but I have full control over server and GW2. In log from server, I see:

sending packet: from (server)[500] to (GW2)[500] (420 bytes)
sending retransmit 2 of request message ID 0, seq 1

The same is on GW2. I can ping both sides, but IPSec packets are not transmitted. ipsec.conf on server:

left=%defaultroute
leftid=serverip(from LAN0)
leftsubnet=LAN0/24
right=GW2
rightsubnet=LAN2/24

on GW2:

left=GW2
leftid=GW2
leftsubnet=LAN2/24
right=server(from LAN0)
rightid=%any
rightsubnet=LAN0/24

What is wrong ?

Jarek
  • 121
  • 1

1 Answers1

0

This is not possible out of the box because strongSwan installs bypass policies on its UDP sockets so IKE traffic is excluded from any IPsec processing. That's why GW2 is not reachable as IKE messages to it won't be sent via IPSEC1 but are attempted to be sent directly.

There is an option (charon.plugins.kernel-netlink.port_bypass) that causes the installation of regular, port/protocol-specific policies, instead of socket policies to exclude the IKE traffic. If you negotiate additional traffic selectors between server and GW1 for the IP addresses of server and GW2 plus the protocol and ports (UDP 500/4500) it might be possible to tunnel the IKE traffic (because the IP addresses are specified, these policies should be more specific and therefore have a higher priority than the bypass policies). I've never tried this, so not sure if it works (there might be other issues in the kernel when handling such nested tunnels).

Another approach (also untested) might be to use XFRM interfaces with an explicit route that directs packets to GW2 via the XFRM interface that is associated with IPSEC1 (that might even work with the socket policies).

ecdsa
  • 3,973
  • 15
  • 29