I originally spun up my DynFi Manager behind an nginx reverse proxy to make it simple to use acme.sh. I've recently decided to go all in on Cloudflare Zero Trust and DynFi has been the only service I've had a hard time setting up with a tunnel.
My manager is dynfi-23.0.3-all.jar on Ubuntu 20.04.6 LTS.
I've configured the CF tunnel to resolve https://localhost:9090 to https://dynfi.myhostname.tld. It loads the login page, but many of the elements on the login page are directed to https://127.0.0.1:9090
I also see this error when the page loads:
and this error when attempting to login:
The CF tunnels have an "HTTP Host Header" setting that I've tried set to "dynfi.myhostname.tld" in combination with "corsAllowOrigin=*", "corsAllowOrigin=", and "corsAllowOrigin=dynfi.myhostname.tld".
I've lost track a bit about which I've tried and not but I'm pretty darn sure I've tried all permutations.
I'd very much like to have DynFi Manager behind the security Cloudflare Zero Trust provides. Thoughts?
Thanks.Peet
Cloudflare Zero Trust Tunnel (reverse proxy)
Moderator: gregober
Re: Cloudflare Zero Trust Tunnel (reverse proxy)
I would first make sure where your DynFi Manager is listening on using such tool as "netstat":I originally spun up my DynFi Manager behind an nginx reverse proxy to make it simple to use acme.sh. I've recently decided to go all in on Cloudflare Zero Trust and DynFi has been the only service I've had a hard time setting up with a tunnel.
My manager is dynfi-23.0.3-all.jar on Ubuntu 20.04.6 LTS.
I've configured the CF tunnel to resolve https://localhost:9090 to https://dynfi.myhostname.tld. It loads the login page, but many of the elements on the login page are directed to https://127.0.0.1:9090
Code: Select all
# netstat -an -net4 | grep 9090
tcp 0 0 192.168.240.253:35234 192.168.240.253:9090 TIME_WAIT 0 0
A safe value could be to listen on all available interfaces using this setting:
Code: Select all
ipAndPort=0.0.0.0:9090
Then configure your other settings using the reverse proxy nginx or other reverse proxy solutions of you choice.
CleanShot 2023-03-28 at 12.24.06@2x.png
I also see this error when the page loads:
CleanShot 2023-03-28 at 12.12.41@2x.png
and this error when attempting to login:
CleanShot 2023-03-28 at 12.21.15@2x.png
The CF tunnels have an "HTTP Host Header" setting that I've tried set to "dynfi.myhostname.tld" in combination with "corsAllowOrigin=*", "corsAllowOrigin=", and "corsAllowOrigin=dynfi.myhostname.tld".
I've lost track a bit about which I've tried and not but I'm pretty darn sure I've tried all permutations.
I'd very much like to have DynFi Manager behind the security Cloudflare Zero Trust provides. Thoughts?
Thanks.Peet
Re: Cloudflare Zero Trust Tunnel (reverse proxy)
So for posterity's sake I'll run through this ...
It had been a long while since I'd looked at my working nginx reverse proxy:
What I failed to realize was this is rewriting all calls to "/config.js".
I'm new with 'cloudflared' and their zero trust platform, but I don't think there's anyway to handle that sort of reverse proxy.
All that said, it was easy enough to ensure my "dynfi.domain.tld" was resolving to a loopback address "127.0.1.1".
I ensured that I could and then setup the cloudflared tunnel origin to https://dynfi.domain.tld instead of https://127.0.0.1:9090.
Don't get me wrong setting up a nginx reverse proxy isn't rocket science but it does seem to be a pretty heavy lift especially when DynFi could "simply" respect the HTTP Host Header and not build api links back to the "ipAndPort=127.0.0.1:9090" setting. I'm sure there's something that makes that a technical lift, but it is most definitely a barrier to entry.
Yes, I know I could sign up for SaaS, but then I wouldn't have my instance fully protected by SAML, MFA and CloudFlare's Zero Trust.
Not a dig on DynFi, I'd just like to see it as easy to deploy as possible!.
It had been a long while since I'd looked at my working nginx reverse proxy:
Code: Select all
server {
server_name dynfi.domain.tld;
root /var/www/dynfi.domain.tld;
index index.html;
location /.well-known {
alias /var/www/dynfi.domain.tld/.well-known;
}
location /config.js {
proxy_pass https://127.0.0.1:9090;
sub_filter 'https://127.0.0.1:9090' 'https://$server_name';
sub_filter_types "*";
}
location / {
proxy_pass https://127.0.0.1:9090;
# try_files $uri $uri/ =404;
}
}
Code: Select all
sub_filter
Code: Select all
sub_filter 'https://127.0.0.1:9090' 'https://$server_name';
sub_filter_types "*";
All that said, it was easy enough to ensure my "dynfi.domain.tld" was resolving to a loopback address "127.0.1.1".
I ensured that I could
Code: Select all
curl https://dynfi.domain.tld/api/ui-theme/logo
Don't get me wrong setting up a nginx reverse proxy isn't rocket science but it does seem to be a pretty heavy lift especially when DynFi could "simply" respect the HTTP Host Header and not build api links back to the "ipAndPort=127.0.0.1:9090" setting. I'm sure there's something that makes that a technical lift, but it is most definitely a barrier to entry.
Yes, I know I could sign up for SaaS, but then I wouldn't have my instance fully protected by SAML, MFA and CloudFlare's Zero Trust.
Not a dig on DynFi, I'd just like to see it as easy to deploy as possible!.