Cloudron installation behind NAT with multiple public IPs

[robw]

Hi there,

We're attempting to set up Cloudron in our business network behind a router/firewall using network address translation. We have NAT loopback (hairpinning) configured as per this article:

https://cloudron.io/blog/2018-04-13-home-server.html

So it is certainly possible to access everything correctly from inside the network using DNS lookups. For instance, the Cloudron web UI loads correctly when we access it from inside our network using the external DNS lookup. However, we receive this error when starting the web UI part of the installation process and there is no way to continue past it:

Domain Configuration
Configuration error: Domain resolves to ["x.x.x.x"] instead of y.y.y.y

Our configuration is:
Cloudron: 3.4 on Ubuntu 18.04
DNS: Wildcard pointing to x.x.x.x

The issue appears to be that we have multiple public IPs pointing to our Internet connection. For accessing systems on our network, NAT with hairpinning is successfully being used to process external DNS lookups both for external and internal access. However due to our router setup, all outbound requests are being routed via our business's primary Internet connection IP address (which is y.y.y.y in the error above). This works fine for all our other systems, but Cloudron doesn't seem to like it.

We'd like Cloudron to run on a different IP (one of the others pointing to our network - x.x.x.x in the error above), so that we can manage our various domain names flexibly. This is where our Cloudron DNS wildcard entry is currently pointing.

So my question is: Is there a way to make Cloudron bypass that DNS/IP validation check during setup?

A secondary question, is whether or not Cloudron (and its apps) will actually work correctly using DNS lookups for everything behind the scenes (in which case our current network setup should actually work and it's only the installation process's DNS validation that gets in our way), or if it ever really does need outbound requests to be sent on the same public IP that the server is being accessed on?

I guess in advance you might suggest we configure our router so that requests from the Cloudron server are sent on the same IP that our domain points to - e.g. using static routes. I guess that would work. However it's quite a complicated solution that we don't currently have the internal expertise to support. It would also mean setting up separate manually managed network configurations each time we want a new Cloudron server (e.g. for dev/test servers, or for some clients). So we'd prefer to avoid that complication.

Cheers,
Rob

[girish]

@robw Sorry for the delayed response, we are just coming back from vacation and catching up on support tickets.

If I understand correctly, the Cloudron server has a different outbound IP than the one it detects. We have a custom endpoint (https://api.cloudron.io/api/v1/helper/public_ip) which helps us detect the IP of a server but I guess this detection goes wrong because of your setup.

To fix/workaround this: In the domain setup wizard, you can simply choose "no-op" as the DNS provider. With this provider, all DNS checks are disabled and as long as the domain somehow is able to resolve and reach your cloudron, it should all work. Another thing is that port 80 needs to be reachable as well for Let's Encrypt to work. If this is not possible, you can select 'Self Signed Certs' in the Advanced section of the domain UI.