Url forwarding
-
OK, I might be a little impatient here... The one app seems to finished the installation (state: running) , but still the the certificate could not be installed.
Feb 12 15:55:47 box:reverseproxy ensureCertificate: renewal of <subdomain>.<domain.org> failed. using fallback certificates for <domain.org>
-
First application with certificate problem is still not running. It's OpenVPN application.
But the second one (I just clicked randomly on application SimpleTorrent) worked quite well... the certificate is there and the opens up.
So I'll check the configuration again for differences of the two subdomains and come back here....
-
The apps do install now, but there is still an issue with port 80 while Installing - Configuring reverse proxy
The problem is still that the certificate cannot be received -> 400waitForChallenge: status is "invalid" "{"type":"http-01","status":"invalid","error":{"type":"urn:ietf:params:acme:error:connection","detail":"Fetching <subdomain>.<domain.org>/.well-known/acme-challenge/S36uTg-qbTRkmYAC2Mfqoe3xN9sCa1oqhx1M9xIfhAA: Error getting validation data",**"status":400**},"url":"https://acme-v02.api.letsencrypt.org/acme/chall-v3/78076561540/hDfVPA","token":"S36uTg-qbTRkmYAC2Mfqoe3xN9sCa1oqhx1M9xIfhAA","validationRecord":[{"url":"http://vpn.paletticloud.de/.well-known/acme-challenge/S36uTg-qbTRkmYAC2Mfqoe3xN9sCa1oqhx1M9xIfhAA","hostname":"<subdomain>.<domain.org>","port":"80","addressesResolved":["<My WAN IP>"],"addressUsed":"<My WAN IP>"}],"validated":"2022-02-13T11:07:10Z"}"
But I don't get it, because at the end of installation process, the application is available over https: and the certificate looks good so far.
But then within the application log, there is always the 404 socket error_
/socket.io/?EIO=3&transport=polling&t=Nxoog7Y 404 0.973 ms - 149
So it seems an issue with the proxy, but the configuration looks good and web socket is enabled. Or what do I miss here?
Cheers!
-
This should be the problem I think...
@girish said in Cloudron and Apps Behind a Proxy:
@doodlemania2 You can just proxy_pass (https), it should work fine. I think if you have the programmatic DNS then Cloudron can gets certs with DNS automation with no problem as well (otherwise, you will have to somehow auto-magically redirect .well-known stuff required for LE).
I recall this post - https://forum.cloudron.io/topic/2094/reverse-proxy-infront-of-cloudron-gives-me-to-many-redirects . Maybe @smilebasti has a config.
Is there anything to get it 'auto-magically' work? I couldn't find anything yet.
-
So maybe to take a step back first, I am not sure if this all is leading down the best path. You have setup an nginx reverse proxy on a raspberry, which is exposed via 80 and 443 to the public. Now that reverse proxy config needs to use the domains/subdomains to then proxy to either your Cloudron or some other server in your network.
I assume this works so far. So at least on the Cloudron side, have you checked the network section of the dashboard to see if the public IP is correctly detected?
Also I don't think your kind of setup really requires any specific DNS resolution settings at all, just the reverse proxy, so maybe a fresh start on DNS/unbound might avoid some issues you are hitting.For the acme flow to get a ssl certificate, can you retry and see if the reverse proxy in fact correctly forwards
<subdomain>.<domain.org>/.well-known/acme-challenge/....
to the Cloudron server? -
Yes, the public IP is correctly detected.
I've also reverted the custom.conf of unbound except the entries pointing two the two other applications in the network.
However, it's take around 10 min to install an application because it still runs into the acme challenge timeout, but in the end most of the apps seem to work properly.
And the following picture does not help for receiving certificate:
So I guess, after timeout it the falls back to the domain certificate, but in the end the certificate that is in use comes from nginx on raspberry.
You can check on RocketChat application on chat.<domain.org> whereby the <domain.org> was sent to the support mail box.
But for application like OpenVPN it still not working properly. The application is online vpn.<domain.org>, but there is still the socket.io error within the log and therefore it cannot establish a connection to the VPN server.
Feb 14 10:12:12 GET /socket.io/?EIO=3&transport=polling&t=NxtWFkM 404 1.803 ms - 149 Feb 14 10:12:14 GET /socket.io/?EIO=3&transport=polling&t=NxtWGE5 404 1.512 ms - 149 Feb 14 10:12:20 GET /socket.io/?EIO=3&transport=polling&t=NxtWHiM 404 1.962 ms - 149 Feb 14 10:15:44 GET /socket.io/?EIO=3&transport=polling&t=NxtX3NF 404 1.124 ms - 149 Feb 14 10:15:50 GET /socket.io/?EIO=3&transport=polling&t=NxtX4s6 404 0.455 ms - 149 Feb 14 10:15:50 GET / 200 5.134 ms - 962 Feb 14 10:15:50 GET /js/index.563345b1.js 200 1.901 ms - - Feb 14 10:15:50 GET /js/chunk-vendors.e7987ea7.js 200 4.398 ms - - Feb 14 10:15:50 GET /api/profile 401 0.665 ms - 2 Feb 14 10:15:51 GET /logo.png 200 2.891 ms - 30393 Feb 14 10:15:52 GET /socket.io/?EIO=3&transport=polling&t=NxtX5Ln 404 1.404 ms - 149 Feb 14 10:15:58 GET /socket.io/?EIO=3&transport=polling&t=NxtX6py 404 3.699 ms - 149 Feb 14 10:16:00 GET /socket.io/?EIO=3&transport=polling&t=NxtX7Jb 404 0.470 ms - 149 Feb 14 10:16:06 GET /socket.io/?EIO=3&transport=polling&t=NxtX8nN 404 1.397 ms - 149
Configuring like this prevents the socket.io error from being written into the log, So I guess this is progress...
But still the OpenVPN is not able to establish connection: Connection Refused.
And this did not help to resolve the issue:
-
@Chris-0 unfortunately I don't have such a setup to test this, so this is a bit hard to guess for me. For socket.io the reverse proxy usually needs some special settings to make it work. No clue how and if the nginx gui supports this.
For the .well-known location, you I guess you can test this also without running the acme flow, by simply using curl to ensure the request gets forwarded correctly to Cloudron.
-
Yes, that is not working:
curl -k -H 'Host: <subdomain.domain.org>' http://<local cloudron IP>:80 returns: <center><h1>301 Moved Permanently</h1></center>
but this is working:
curl -k -H 'Host: <subdomain.domain.org>' https://<local cloudron IP>
This should be resolvable by setting proper x-forward-headers but I couldn't find a working setup yet.
-
Within the nginx log I've found an bind error to port 80, which i was not able to resolve, so therefore I've reinstalled the nginx server on rpi from scratch, but the same error still persists.
The curl cmd running on nginx server
pi@piHole:~/nginxmanager $ curl -k -H 'Host: <subdomain1.domain.org>' http://192.168.178.94 <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html>
And the current nginx configuration for two cloudron apps:
pi@piHole:~/nginxmanager $ cat data/nginx/proxy_host/1.conf server { set $forward_scheme https; set $server "192.168.178.94"; set $port 443; listen 80; listen [::]:80; listen 443 ssl http2; listen [::]:443 ssl http2; server_name <subdomain1.domain.org> <subdomain2.domain.org>; # Let's Encrypt SSL include conf.d/include/letsencrypt-acme-challenge.conf; include conf.d/include/ssl-ciphers.conf; ssl_certificate /etc/letsencrypt/live/npm-1/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/npm-1/privkey.pem; # Asset Caching include conf.d/include/assets.conf; # Block Exploits include conf.d/include/block-exploits.conf; # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years) add_header Strict-Transport-Security "max-age=63072000; preload" always; # Force SSL include conf.d/include/force-ssl.conf; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; access_log /data/logs/proxy-host-1_access.log proxy; error_log /data/logs/proxy-host-1_error.log warn; location / { # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years) add_header Strict-Transport-Security "max-age=63072000; preload" always; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; # Proxy! include conf.d/include/proxy.conf; } # Custom include /data/nginx/custom/server_proxy[.]conf; }
-
@Chris-0 what exactly is the mentioned bind error? Is something already listening on port 80? From you curl output, it seems nginx is actually running fine on port 80, so it is unclear what your issue now is. Also given the various includes of other config files in your posted nginx config file, it is impossible to make further suggestions or observations.
-
@nebulon Yes, there was an other port open on the raspberry - possibly from old services running on this device. But after reinstallation it was gone...
So then I just posted the default generated nginx config for two subdomains. But I get it, that those includes are quite confusing... I try to create a cleaner version.
Thank you for your patience.
-
-
-
-