1

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 10.0.0.0/8 (10.0.0.19 to be precise).

In order to talk to the real world, it has a public, dedicated IPv4, which let's say it's 203.0.113.1. The gateway applies a full-cone, 1:1 NAT so every packet sent to this 203.0.113.1 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 10.0.0.19, rather than the actual public IP of 203.0.113.1. 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 10.0.0.19, 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 10.0.0.19 IP with the real IP of 203.0.113.1 so IPsec works?

Improve this question
3
  • IPSec has a NAT option. Does that help in this instance?
    – Chris Davies
    Commented 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).
    – Marcos Vives Del Sol
    Commented 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
    Commented Mar 21, 2022 at 2:27

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

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