Cloudron Forum

@taowang note that your IP is actually leaked. If you follow the MX record of your domain, you will find your server IP in the DNS. I think this is what the Cloudflare doc is trying to tell you.

@JOduMonT an email server (without email relays) requires a public IP. There is no way around this. Even if you add a second IP, the second IP will be exposed and one can always access your Cloudron dashboard via that IP address. Just have to put an entry in /etc/hosts on my laptop and point that floating IP to my.domain.com and that's it. I guess you are looking for a way to "sandbox" mail server to a specific IP somehow. We don't have a way to do this in Cloudron. I can move this to Feature Requests. But also, it might be easier to just create another VM and run mail on the other VM? Security wise , this is the easiest and cleanest instead of writing a lot of code to make sure mail server and dashboard despite being on the same server don't step on each other (networking wise).

Closed due to inactivity

I want my users to OIDC via Cloudron to Cloudflares App Launcher where I can put all avialiable softwares some are from cloudron others are just SAAS (cloudflare can do SAML for SAAS) [image: 1712858310234-screenshot-2024-04-11-at-19.57.11-resized.png] Cloudron => Cloudflare Launcher => AWS

@micmc yes, already implemented the crash fix -https://git.cloudron.io/cloudron/box/-/commit/d862f1f5b4f10b5852aed958ecc4ce42709103f7 . CF was returning an invalid response that our code was not prepared for.

I didn't uncover the cause, but I believe it was related to the VM running out of disk space. I wound up reinstalling. I let a large upload job run unattended and wound up completely filling the drive on the VM running Cloudron. I then cleared about 100 GB, rebooted for good measure, resized the partition using parted, expanded the filesystem, rebooted again, and let it run normally for a few days. That's when I noticed I couldn't install any new apps. I suspect that either the partition / filesystem resize or the disk being full broke something internally. In hindsight I wish I had taken the time to dig into the logs a little more and see what was happening. But this is likely a direct result of my unusual environment fault.

Hi, I just wanted to follow up on this. We found the relating issue in this case which resulted in several different problems. In that case, it was bug in a firmware update on a firewall and not related to Cloudron and can be marked as resolved. Thank you anyway for your help.

This is fixed now. The original issue is that the zone is added in Cloudflare but the nameservers of the domain are not set to Cloudflare. This makes Cloudflare return name_servers as empty in the response which makes our code crash.

Thank you @laurent I'll try something like that.

@robi I think the user put zone restrictions on his existing API keys. The Cloudron zone was not part of the API key.

Great write-up thanks for sharing all those insights, this will surely help users down the line

@girish said in trying to use cloudron openid connect with cloudflare0trust: @ ok i tryed that. only problem, it keeps changing the token, the zero-trust does. everytime i put it in, it puts like 34more bullets (what i hear on the screen reader when trying to enter) in the tokens field.

So I think I've found the solution. Modify the Proxy Host config > Advanced and paste the following: set_real_ip_from 03.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 104.16.0.0/13; set_real_ip_from 104.24.0.0/14; set_real_ip_from 108.162.192.0/18; set_real_ip_from 131.0.72.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 162.158.0.0/15; set_real_ip_from 172.64.0.0/13; set_real_ip_from 173.245.48.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 190.93.240.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; #use any of the following two real_ip_header CF-Connecting-IP; #real_ip_header X-Forwarded-For; this will allow True Client IP Address to be passed to Cloudron.

Are you also using the domain outside of Cloudron? I am surprised you hit any limit at all, Cloudron API usage is quite low.

Thank you for your help. Website filing is to register the services provided by this server to improve network security. When I tried to use servers in other countries, it was very successful, thank you for your help, and wish you success in your work!

@ghstandard that feature is coming in 7.5.1 which we will stage tomorrow.

ahhh, so just have to nix cloudflare altogether, thanks! confused myself because my plains.cloud is cloudflared, but mail.plains.cloud specifically is not! appreciate the clarification

Sometimes it's browser cache related as well, so make sure to use Shift-reload after major changes like this.

@imc67 said in Too many redirects when using Cloudflare DNS proxy: @Grienauer said in Too many redirects when using Cloudflare DNS proxy: I also had this problem. After researching etc, the solution is to set the SSL/TSL to Kustom -> FULL. Wow! Thanks for this very valuable information because now I’m finally able to use Cloudflare’s WAF!! (Cloudron as well as NetCup doesn’t have a WAF to ie. geoblock wp-login.php or other login pages). Certainly no equivalent to WAF but we do have blocklists to geoblock: https://docs.cloudron.io/guides/community/blocklist-updates/

Alright, I've got another update and seemed to have reworked things so this is fixed. I've removed all of the old rules and created a new one under WAF Rules using the following: (http.host eq "https://my.cloudron.tld" and ip.src eq 127.0.0.1 and http.request.uri.path contains "/filemanager/") or (http.request.uri.path contains "/api/v1/apps") Then take action: Skip Log matching requests: turned on WAF components to skip: All managed rules More components to skip: Managed rules (previous versions) Note: Edit the items in bold to reflect your Cloudron Domain and your IP Address.