Url forwarding
-
So this is what i am trying....
https://pagekite.net/wiki/Howto/TlsClientAuthentication/
but it's just not working.
- Port forwarding on router for 80 and 443 is disabled.
- The (two) certificates are within folder /hass/proxy/certs/ (Also mapped in docker-compose file to nginx proxy). But for now, I just try to get it done for the first services which runs on port 8123.
executing this:
python3 /usr/bin/pagekite.py --clean --frontend=hass3.mydomain.com:80 --tls_default=ssl --tls_endpoint=ssl:/hass/proxy/certs/hass3.mydomain.com.crt --proxy=ssl:/hass/proxy/certs/hass3.mydomain.com.crt@hass3.mydomain.com,commonName:443 --proxy=http:hass3.mydomain.com:443 --backend=http:hass3.mydomain.com:8123 --logfile=stdio --debugio
returns this, but I do not know if this is correct. Removing the debugging parameters prevents the output and I think I should save this.... but I also can not find the frontend.rc config file.
ts=620507e5; t=2022-02-10T12:41:09; ll=0; started=/usr/bin/pagekite.py; version=1.5.2.201011; platform=linux; python=3.6.12 (default, Dec 02 2020, 09:44:23) [GCC]; argv=--clean --frontend=hass3.mydomain.com:80 --tls_default=ssl --tls_endpoint=ssl:/hass/proxy/certs/hass3.mydomain.com.crt --proxy=ssl:/hass/proxy/certs/hass3.mydomain.com.crt@hass3.mydomain.com,commonName:443 --proxy=http:hass3.mydomain.com:443 --backend=http:hass3.mydomain.com:8123 --logfile=stdio --debugio; ca_certs=/etc/ssl/ca-bundle.pem; send_always_buffers=False; tunnel_socket_blocks=False
Where is the directory for the .rc file. PageKite is installed within /usr/bin/pagekite.py
I have also tried executing something like this:
sudo pagekite.py --clean --isfrontend \ --ports=80 --protos=http,raw \ --domain=http,raw:EXAMPLE.COM:yourpassword \ --tunnel_acl=allow:localhost
but then the shell also remains open and a text message tells: 'Waiting for back end...' which never ends because I was not able to execute the back-end command yet.
I think this is the list of question I have:
- Does this even theoretically work with docker-compose which contains two services behind an nginx with letsencrypt?
- Where are the .rc files and how to use it?
- Are the paths to the certificates correct? And do I need that ca certificate, because within the certs folder there are exclusively subdomains?
Cheers,
ChrisLet me know, if I should take this topic to a different forum.
-
@chris-0 Usually, this kind of setup is done via using a reverse proxy. Please see these posts:
- https://forum.cloudron.io/topic/4463/cloudron-and-apps-behind-a-proxy
- https://forum.cloudron.io/topic/5898/nginx-in-front-of-cloudron-install
- https://forum.cloudron.io/topic/4726/cloudron-as-reverse-proxy-for-non-cloudron-apps (this is the request to integrate this on Cloudron itself)
I have tried to setup nginx proxy manager in the past and it does work well. Basically,
router <---> nginx proxymanager VM <------> Cloudron VM |---> Some external app1 |---> Some external app2
(Hope that text diagram doesn't get smudged... !)
-
-
@girish Thanks a lot, I did not know about the nginxmanager. Great gui tool.
I've managed to install it on a raspberry and the forwarding to the first 'external app' is working
Access to the second 'external app' is not yet working - but this is Ok for now.The Cloudron instance is also reachable over https from anywhere, which is fantastic.
But there are still two other issues:
- Cloudron instance is not reachable from its own machine.
- Installing an app, will not finish successful - installation is always stuck at ~80%, which is possibly same reason as issue 1.
Issue 1 SOLVED after finding the error message:
DNS Error: DNS Record is not synced yet: queryNs ENODATA <domain.org>and then adding lines into /etc/hosts
192.168.1.55 <domain.org>
But adding subdomains did not help resolving issue 2
192.168.1.55 <subdomain>.<domain.org>
.... -
Installation of an app ends with error:
An error occurred during the install operation: DNS Error: DNS Record is not synced yet: queryNs ENODATA <domain.org>
but as stated before the domain.org is known within the DNS.
-
Executing the curl -k -H 'Host: <subdomain>.<domain.org>' https://<local cloudron IP>
does work from the cloudron instance and it returnsYou are seeing this page because this domain points to Cloudron server IP but no app is installed on that domain.
but also from same machine, the DNS resolution does not work
host: <subdomain>.<domain.org> Host <subdomain>.<domain.org> not found: 3(NXDOMAIN)
-
I've just checked the unbound config again and added the stub-zone which was missing:
local-data: "app1.<domain.org>. in A 192.168.178.42" local-data: "app1Url2.<domain.org>. in A 192.168.178.42" local-data: "app2.<domain.org>. in A 192.168.178.42" local-data: "app2Url2.<domain.org>. in A 192.168.178.42" server: private-domain: "<domain.org>" domain-insecure: "<domain.org>" stub-zone: name: "<domain>" stub-addr: 192.168.178.94 stub-first: yes
This led to successful domain name resolution for newly installed apps.
But now the installation is stuck ~90% saying
Installing - Configuring reverse proxy Error while trying to receive the certificate: Feb 12 15:51:13 box:cert/acme2 waitForChallenge: status is "invalid" "{"type":"http-01","status":"invalid","error":{"type":"urn:ietf:params:acme:error:unauthorized","detail":"Invalid response from https://<Subdomain>.<domain.org>/.well-known/acme-challenge/0mxQYSMcrMZ-KWRxdnjJT5FluM1Z65fD5xJ62KJpXwI [<My WAN IP>]: \"<html>\\r\\n<head><title>404 Not Found</title></head>\\r\\n<body>\\r\\n<center><h1>404 Not Found</h1></center>\\r\\n<hr><center>openresty</cente\"","status":403},"url":"https://acme-v02.api.letsencrypt.org/acme/chall-v3/77807981670/rzRRug","token":"0mxQYSMcrMZ-KWRxdnjJT5FluM1Z65fD5xJ62KJpXwI","validationRecord":[{"url":"http://<Subdomain>.<domain.org>/.well-known/acme-challenge/0mxQYSMcrMZ-KWRxdnjJT5FluM1Z65fD5xJ62KJpXwI","hostname":"<Subdomain>.<domain.org>","port":"80","addressesResolved":["<My WAN IP>"],"addressUsed":"<My WAN IP>"},{"url":"https://<Subdomain>.<domain.org>/.well-known/acme-challenge/0mxQYSMcrMZ-KWRxdnjJT5FluM1Z65fD5xJ62KJpXwI","hostname":"vpn.<domain.org>","port":"443","addressesResolved":["<WAN IP>"],"addressUsed":"<My WAN IP>"}],"validated":"2022-02-12T14:50:50Z"}"
So it fails with Error 404 calling the .well-known/acme endpoint.
but the <subdomain>.<domain.org> is still available but of course without revealing the cloudron app at the moment.I'll send a mail with domain information. Thanks @nebulon
-
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.
-
-
-
-