Ubuntu 20.4 + OpenVPN + IKE2 + IPSec + strongswan with Hetzner

PDM

Hi, it was easy to configure an IPSec IKE2 tunnel with strongswan. I can do it outside Hetzner CX Server. Hetzner CX Server uses 1:1 NAT for Public IP address to Private address. My IPSec counterpart only knows my Public IP address (not the my Hetzner private one. Hetzner support says that they couldn't not help. So, I have the IKE2 IPSec tunnel up and running, but I am not allowed to ping or access to my counterpart subnet.

My IP routing is (with IPSEc tunnel):

default via 172.31.1.1 dev eth0 proto static onlink
default via 172.31.1.1 dev eth0 proto dhcp src 123.456.789.11 metric 100
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
172.31.1.1 dev eth0 proto dhcp scope link src 123.456.789.11 metric 100

my UFW before.rules is:

*nat
-A POSTROUTING -s IPSECdestinationIP/32 -o eth0 -m policy --pol ipsec --dir out -j ACCEPT
-A POSTROUTING -s IPSECdestinationIP/32 -o eth0 -j MASQUERADE
COMMIT

*mangle
-A FORWARD --match policy --pol ipsec --dir in -s IPSECdestinationIP/32 -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
COMMIT

-A ufw-before-forward --match policy --pol ipsec --dir in --proto esp -s IPSECdestinationIP/32 -j ACCEPT
-A ufw-before-forward --match policy --pol ipsec --dir out --proto esp -d IPSECdestinationIP/32 -j ACCEPT

I am not an IP routing expert. IF I have my IPSec tunnel on, what do I have to do to access my IPSECdestinationIP/32 server. I understand that I should have a IP routing problem, but how can I move forward with this situation. With DigitalOcean (Hetzner competitor), using the same procedures, everything work fine (subnet to subnet IPSec tunnel). With Hetzner, 1:1 NAT public to private IP I cannot make it. Any help would be deeply appreciated.

Erisa

@PDM said: Hetzner CX Server uses 1:1 NAT for Public IP address to Private address.

What do you mean? Hetzner Cloud instances only have direcct public IPs and there is no NAT or private addresses involved. I created an instance just now that was assigned the IP 49.12.11.14 and on the instance I can see this:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 96:00:01:25:4b:22 brd ff:ff:ff:ff:ff:ff
    inet 49.12.11.14/32 scope global dynamic eth0
       valid_lft 86298sec preferred_lft 86298sec
    inet6 2a01:4f8:1c17:e4c0::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::9400:1ff:fe25:4b22/64 scope link
       valid_lft forever preferred_lft forever

(The instance will be deleted by the time I post this so I don't mind showing the IP)

The "Private networks" feature of Hetzner Cloud works entirely seperately, they are on separate interfaces and do not route publicly:

3: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000
    link/ether 86:00:00:07:7e:23 brd ff:ff:ff:ff:ff:ff
    inet 10.69.69.2/32 brd 10.69.69.2 scope global dynamic ens10
       valid_lft 86399sec preferred_lft 86399sec
    inet6 fe80::8400:ff:fe07:7e23/64 scope link
       valid_lft forever preferred_lft forever

The behaviour you are describing with private and public IPs is something I expect out of AWS/Azure/Google/Oracle because those do indeed have private IPs that map to public ones.

Moving on to the issue at hand - what steps did you go through to create the setup? Was there a script or did you do it all yourself?

PDM

Thank you so much to your fast answer. I follow part of this steps:

https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-20-04

I am using a shared secret, not a certificate.

Today I saw this Hetzner guide: https://community.hetzner.com/tutorials/ipsec_nat
They mention this: "To establish a secure connection between hosts IPSec is often used. During installation, one must remember that CX vServers translate the public IP via 1:1 NAT to an internal IP"

In my case, I cannot use my leftID internal IP. My partner only expects my Public IP. I don't know how to move forward from this situation. Moving from Hetzner to DigitalOcean just because of this public to internal IP is a thing that, if possible, I prefer not to do it. But I am right now without any ideas how to move forward. Any help would be deeply appreciated it.

Thanks in Advance

Erisa

@PDM said: Today I saw this Hetzner guide: https://community.hetzner.com/tutorials/ipsec_nat
They mention this: "To establish a secure connection between hosts IPSec is often used. During installation, one must remember that CX vServers translate the public IP via 1:1 NAT to an internal IP"

Ah, I understand now. That guide is outdated (2019). The "Hetzner vServers" were their monthly VPS offering before they launched Hetzner Cloud.

So, are you using Hetzner Cloud or a legacy vServer offering? Both have a concept of CX.

PDM

Hetzner Cloud Service

Erisa

@PDM said:
Hetzner Cloud Service

Then the Hetzner Community page that you found is not relevant to this, and any information within it should be disregarded.

I would follow the Strongswan guide you linked myself to fiddle with it, but I'm not really in the mood for that kind of effort investment right now, I have better things to be doing. Hope you get it sorted.

PDM

Thanks Erisa, I already tried, but I will try to do once more. Thanks so much anyway.

PDM

It seems that I really have a ip routing problem, any help would be deeply appreciate it:

iptables -t nat -L -n -v

Chain PREROUTING (policy ACCEPT 56653 packets, 5234K bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 23354 packets, 1408K bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 317 packets, 24319 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 284 packets, 22315 bytes)
pkts bytes target prot opt in out source destination
60107 6875K SNAT all -- * * 10.8.0.0/24 !10.8.0.0/24 to:123.456.789.11
0 0 SNAT all -- * * 10.8.0.0/24 !10.8.0.0/24 to:123.456.789.11
0 0 ACCEPT all -- * eth0 IPSECdestinationIP 0.0.0.0/0 policy match dir out pol ipsec
0 0 MASQUERADE all -- * eth0 IPSECdestinationIP 0.0.0.0/0
0 0 ACCEPT all -- * eth0 IPSECdestinationIP 0.0.0.0/0 policy match dir out pol ipsec
0 0 MASQUERADE all -- * eth0 IPSECdestinationIP 0.0.0.0/0