Forward Nextcloud on the intranet

I have several servers running on my home internet connection, including several Nextclouds.
Currently there are problems with:

  • SSL certificate is invalid
  • In the Nextcloud (#2) internal IP address are displayed (also via access from external).
    I suspect that both problems are related.

Current situation see diagram:

My private PC (client) is connected to the Internet (itself or other router/IP like my servers). I dial a subdomain test.example.com, which first goes to my hoster (where I rented the domain) and then to my Dyn.-DNS provider, which points to my private IP address (I don’t know if this is relevant). The request is then forwarded to my main server (#1) which is running Apache, but also a Nextcloud (#1). This Nextcloud has been running for years in this configuartion without any problems.
Now I have a second server (#2) in my intranet, on this Nextcloud is installed in a Docker.

I can access and use both NC from the internet. NC #1 also works without any problems (just a note that there should be no problem until here).
However, for NC #2 in config.php, the intranet IP must be under ‘trusted_domains’, otherwise NC #2 is not recognized, even though only the domain (not IP) is selected in the browser, even from external. The domain does not have to be under ‘trusted_domains’.
If I share links, this works. But for shared folders (top right under download) the private IP address is shown (also from external).

Also, no correct SSL certificate is displayed. (I am currently using Lets Encrypt, but I want to use a different certificate later on server #2 or the corresponding sub-domain.

On server #1 I added something like here in Apache: ssl - HTTP & HTTPS Apache redirect to internal IP Virtual Machine - Server Fault

The server #2 I have set up similar to here:

I want to manage the SSL certificates only with server #1, how does this work?
How can I point to server #2 without it thinking that it is addressed via the private IP?

Systems used: Ubuntu 16/21, Apache, NC 19/21

What did you configured in Server1 in Apache for those parameters?

    ProxyPass / http://sentinel.example.net/ timeout=60
    ProxyPassReverse / http://sentinel.example.net/ timeout=60
    ProxyPass / 192.168.1.221
    ProxyPassReverse / 192.168.1.221

Then it is clear, for your server 2 client not your user accessing it via LAN or internet, but rather is Server 1, that accessing it via IP address. This drives to situation when IP address being shown instead of FQDN. To do so, you needs to make Server 2 NC aware about proxy and Host name accessing via Server 1.
There are few similar topics Search results for 'nginx apache reverse proxy' - Nextcloud community

Not sure, but it could be that you need to add this information via:

<Proxy "/">
  RequestHeader set Host server2
</Proxy>

    ProxyPreserveHost      On

    ProxyPass / http://192.168.1.221
    ProxyPassReverse / http://192.168.1.221

I believe there are few headers that you need to set. E.g. this is nice example and it is solved: Nextcloud behind Apache reverse proxy, remote.php becomes remote.phpp

Also check nextcloud config:

What I would suggest is to use one reverse proxy for both servers. Run certbot on the reverse proxy to handle both of their certificates. This will allow you to use the same public IP and ports for both as well. And you would point your DNS internally to the reverse proxy for both servers and access the proxy even when on the LAN. That way your certificates will be valid inside and out, and you won’t have any of this business with using IP addresses.

Thank you both.

Ok, I’m confused … I thought that’s exactly what I was doing!? Server #1 is the right now only reverse proxy for both servers!?

If I set this to On there is only one redirection error.

This is what my two Apache files look like on server #1

<VirtualHost *:80>
  ServerName test.example.com
  ProxyPreserveHost On
  <Proxy *>
    Order allow,deny
    Allow from all
  </Proxy>
  ProxyPass / http://192.168.1.221/
  ProxyPassReverse / http://192.168.1.221/
</VirtualHost>
# ~~~
<VirtualHost *:443>
    SSLEngine On
	SSLCertificateFile /etc/ssl/certs/apache.crt
	SSLCertificateKeyFile /etc/ssl/private/apache.key
	SSLCertificateChainFile /etc/ssl/private/apache.key
	ServerName test.example.com
	<Proxy *>
		Order allow,deny
		Allow from all
	</Proxy>
    ProxyPreserveHost Off
    ProxyRequests Off
    SSLProxyEngine On
	ProxyPass / http://192.168.1.221/
	ProxyPassReverse / http://192.168.1.221/
</VirtualHost>

I also tried this tutorial:

But I always get redirection errors.

Is it? That wasn’t what I understood from what you described. So on your server #1 you also have a vhost configured that forwards to #2?

If that’s the case then why all the IP addressing? You should always access Nextcloud via FQDN whether accessing from LAN or remote so your reverse proxy can identify the vhosts and use the correct cert.

How without IP?

I would be grateful for a solution.

The certificate can only be valid when you use a FQDN to access your server. The IP address will never match the name on the certificate.

The FQDN is also how the reverse proxy serving more than one site can tell which site the client is going to, and which certificate it should use. In Apache this is the ServerName property of the virtual host.

Yes, that’s how it is, I can only agree with you completely. I don’t want to seem rude, but I already knew that.
But I really don’t understand how that relates to my problem. You didn’t post a code line or point to anything that can help me further.

Do you understand my problem? Do you want me to describe anything else about it? Sorry, I really don’t know what you are getting at.

Again to this question, which you have answered from my point of view in no white:

How should be referred to server #2, if not by the IP? I have no clue. If I point to the name test.example.com, then it will go back to the internet, point to my router again (in a roundabout way) and you are back to the exact same place. Therefore the redirection error is clear for me.

Please give me a concrete way to solve this problem.