On 2019-05-16 03:40, Chris Smith via users wrote: IPsec is not like other VPNs you might be used to; there is no explicit tunnel device, and the act of encrypting and encapsulating data is handled in the kernel network stack and is essentially invisible otherwise. The left and right addresses which are the existing addresses of the endpoints are the tunnel addresses, unless there is NAT involved which is only supported at one end of an IPsec tunnel unless that has changed recently. If both systems have a public IP address then things are much easier; having a NAT at one end is the classic "road warrior" client configuration where the server has a fixed address. IPsec also has 2 modes, transport and tunnel, which are akin to only the endpoints talking to one another in an encrypted way through their public addresses (transport) or also carrying routed traffic between subnets at each end (tunnel) which you are using by default. The combination of the two on the same SA can sometimes lead to exciting debugging opportunities as different IPsec implementations behave in slightly different ways, but if you have Strongswan at both ends and the same configuration it will be just fine. If you have NAT in effect on the endpoint system(s), e.g. if your container is not using host networking or if it is an internet gateway for other systems on a LAN, then you will also need to configure NAT exemptions for the private subnets on each side of the VPN. It's confusing enough in itself to configure and debug if you're not familiar with it, but adding containers on top of that with the likely NAT is a recipe for it being absolutely horrible. I'd suggest you get it working in a basic routed configuration first. If you are successfully negotiating the IKE (phase1) and IPsec encryption parameters (phase2) SAs, that's the worst of the IPsec battle over already :) Ant