I currently have a free VPS hosted in Oracle Cloud. This machine sits in a so-called "Virtual Cloud Network", which is just a virtual LAN with an address in the range of ( to be precise).

In order to talk to the real world, it has a public, dedicated IPv4, which let's say it's The gateway applies a full-cone, 1:1 NAT so every packet sent to this IP, regardless of protocol and port (if applicable), gets forwarded to the machine.

This NAT means, however, that the destination IP gets replaced to be, rather than the actual public IP of This is not a problem for most services such as HTTPS, SSH, etc... which do not care about the destination IP.

For IPsec however, this is a problem. IPsec expects the machine to have assigned a publicly routable IP address, and it uses the destination IP for connection requests to report clients where to connect to. This results in clients attempting to connect to, which of course fail.

Would it be possible to create some sorta of virtual adapter, such as a loopback one, and forward packets coming from the internet to it, replacing the IP with the real IP of so IPsec works?

  • IPSec has a NAT option. Does that help in this instance? Mar 20, 2022 at 13:35
  • Doesn't seem like it, as I think that's for avoiding NAT on a single side, while in my case I have NAT on both sides (at home and on this machine). Mar 20, 2022 at 14:18
  • Well I made a similar environment, and NAT-T works well with a server (responder) behind (full-cone) NAT and a client (initiator) behind double NAT with randomized source port (so ~ CGNAT), with a virtual IP assigned to the client. The client being behind NAT will anyway always force NAT-T to be selected. The issue might be about configuration (like not configuring properly the id) rather than network. You should provide the configuration for both server and client. I hope both are using strongswan because that's the only kind I know (some) about.
    – A.B
    Mar 21, 2022 at 2:27

1 Answer 1


Seemingly I was following a red herring.

In Android, the system I was using at that moment due to the lack of access to a desktop machine, the issue presented as a connection that attempts to connect, stays in that process for about a minute, and then fails. Thus, considering how long the error was taking to occur, I assumed it was down to retrying to connect and timeouts.

On a Windows machine however, the error 13801 is thrown instantly on the system log, which is caused by the certificate not being trusted by the machine.

MitM'ing this with Wireshark proved that the intermediate Let's Encrypt uses was not properly transmitted by the OpenIKED daemon, and thus machines do not trust it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .