16 May
2019
16 May
'19
4:15 p.m.
On 2019-05-16 03:40, Chris Smith via users wrote:
The IPSec config I have been given (below) is for a
site-to-site connection. There is a machine on 10.99.102.92 at the remote site sending
packets to 172.30.11.2 on my end and I need the container to be both the VPN endpoint and
the destination machine (172.30.11.2). The IPSec connection is established just fine, but
I can’t figure out how to properly associate the IP address with the tunnel. I thought
this was a simple matter of configuring the IP address on the tunnel device (tunl0) but
this fails in a pretty bizarre manner: if I configure the tunnel using ‘ip addr add
172.30.11.2/30 dev tunl0’ then I receive no packets at all. However, if I configure it
for any other address in the range, I get the packets for 172.30.11.2.
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