Nextcloud on Ubuntu VM/Truenas behind Nginx Proxy with duckdns.org

Nextcloud version: 7 (28.0.1)
Operating system and version: Ubuntu 22.04
Apache or nginx version: 2.4.52
PHP version: 8.1

Hi there, a few days ago I installed Nextcloud on VM into my Truenas Scale. Since that time I’ve been struggling with the correct setting as I’m Unix noob :-(. Could any good soul help me? Any hint will be greatly appreciated.

My Nginx is placed on 192.168.0.12 and its setting is correct (at least I hope so cause I use it for other machines in the inner net without any problem).
Nginx on Ubuntu/Nextcloud is not used.
Nextcloud/Ubuntu is installed on Truenas VM with IP 192.168.0.14/nextcloud.

My nginx proxy configuration and next.conf with config.php of nextcloud are inserted here … (I know, I added a lot of trusted domains in the hope of getting it on)

This is all my “flow”
duckdns.org domain is bonded with my fixed public IP address
inner IP of the first router (I was given this HW by my ISP) is 192.168.88.1 with opened ports xxxx1 to xxxx5
my second DHCP router IPs are 192.188.88.253/192.168.0.1 and there is NAT from xxxx1 to 443 of Nginx Proxy on mentioned 192.168.0.12
Finally Nginx proxy points to 192.168.0.14/nextcloud

but, when I put mydomain.duckdns.org:xxx1 (my NAT port) I get this answer :frowning: :frowning: :frowning:

So where the glitch is? Not to pretend I completely understand what I put into the config.php and next.conf :confused:

Your overwrite.cli.url does not use https, also your redirects and proxy hosts are not https, even though you set the overwriteprotocol to https.
I’d also set the overwrite webroot:

With the logs of your webservers and redirects, and perhaps curl, you can try to find out where it hangs. In the current case, I’d check if you have everything with https forwarded correctly …

1 Like

So, I did a small investigation and this is the result:

  1. I changed config.php (cause my attempts with overwriting of webroot didn’t resolve anything - at least in the sense of changes I tried). This is the current one:

  2. Now, in case I fill https://mydomain.duckdns.org:NATport in the address row in any browser, the row is overwritten by the correct login webpage of nextcloud - mydomain.duckdns.org/nextcloud/index.php/login. Unfortunately, the page still depicts a message “The site is unavailable, etc. …”

I have packets caught btw my proxy server and the internal IP of Ubuntu/Nextcloud during a session opened from outside:

Is there any magician, who can find where my problem is?
Thanks

After your initial request, you get a 302 redirect message (No 6), it would be interesting to which URL you get redirected… (perhaps https? and if you haven’t set this up correctly it wouldn’t be a surprise to fail).

Well, I thought now you use everything with just http? If you open the standard ports, you don’t need to specify them in the URL. And use http to test and understand, if you want to authenticate and transfer data, without https, this is a no go.

client internet <-------> (OPEN_PORT) router <-----> (port webserver) NC webserver

http://yourdomain.dyndns.org:OPEN_PORT
if OPEN_PORT is not 80 for http, or 443 for https. If it is not the case, you might want to add it to the trusted domains as well as ‘yourdomain.dyndns.org:OPEN_PORT’

Besides of that, for the trusted domain, only the first two should be enough.

1 Like

https://mydomain.duckdns.org:NAT is used from outer Internet, and transfers from https to http are done by proxy, which uses Encrypt SSL certificate (at least I hope so - the same way as it does for other my “engines” behind the proxy). Communication btw proxy and Nextcloud is done on http.
Am I right?

I don’t use standard 80/443 ports from outside (it’s a long and boring story with my ISP) thus I use a different open port and NAT it on my router to 443 of my proxy.

According to the packet on row 6 - is there any hint hidden for noobs like I’m?

You see the Location: line, so you are redirected to SSL, to the standard port 443. Which by default is not bad to have traffic encrypted to your router. If you use a different https port, you need to redirect to this different port:

https://yourdomain.dyndns.org:PORT/nextcloud

In this case, the the trusted domains should contain:
yourdomain.dyndns.org:PORT

and the overwritehost as well: yourdomain.dyndns.org:PORT

In your router configuration snapshot, I don’t see how you set up the different ports to forward (only how you forward locally). But if you have scheme http or https this will just use the default port, no?

1 Like

And what helps in such cases, your internal proxy, if you can access the logs (or even log the packages there), just to see which service is sending this, if it is already the proxy or the router or your Nextcloud webserver. That can be a bit confusing from outside, and to know how to do it can be helpful, e.g. if you later experience timeouts, they can also originate at different points.

1 Like

Thank you for your answer - this is my router NAT table. The https “fake” port I use from outside is in the router forwarded to the 443 of the proxy where the SSL traffic is terminated, and the proxy operates transferring of data traffic in http to port 80 of ubuntu/nextcloud IP address.

There are the names of 443 and 80 fake ports swapped in the picture, but don’t worry, these are just the names with no effects on real NAT service.

Anyway, I changed the trusted domains array at row 1 => of config.php by adding the outer port I mentioned in the previous paragraph to my duckdns domain, and allowed overwritehost parameter with the same address and port. Something pretty crazy happened because if I put the address mydomain.duckdns.org:outer_fake_https_PORT, I can see my complete config.php file content in the browser window ?!?!

What shall I do now? Bullet or hammer?

Wow, the problem is probably hidden in next.conf file. If I understand it correctly, the “magic gate” of nextcloud is already opened to me from outside now, but instead of a login page, the server offers me something that should be hidden under the skirt forever …
So I have hidden the key in the form of setting overwritehost and trusted_domains under the rug again and gonna investigate more tomorrow.

How is your nginx configuration ?

because with 28.0.1 everything works fine for me, well I think something is wrong with the logout but it doesn’t matter lmao.

1 Like
"id": 6,
  "created_on": "2024-01-21 14:57:22",
  "modified_on": "2024-01-30 22:54:06",
  "owner_user_id": 1,
  "domain_names": [
    "xxx.duckdns.org"
  ],
  "forward_host": "192.168.0.14",
  "forward_port": 80,
  "access_list_id": 0,
  "certificate_id": 10,
  "ssl_forced": true,
  "caching_enabled": false,
  "block_exploits": true,
  "advanced_config": "",
  "meta": {
    "letsencrypt_agree": false,
    "dns_challenge": false
  },
  "allow_websocket_upgrade": true,
  "http2_support": true,
  "forward_scheme": "http",
  "enabled": 1,
  "locations": [
    {
      "path": "/",
      "advanced_config": "",
      "forward_scheme": "http",
      "forward_host": "192.168.0.14/nextcloud/",
      "forward_port": 80
    }
  ],
  "hsts_enabled": false,
  "hsts_subdomains": false
}