Has anyone tried this and gotten it to work or even just using a VPS as an exit node without proxy?

my backups started failing (to my NAS) I manually deleted the backup history folders, and snapshot folder, then they worked ok again. I recently changed to the rysnc storage format, so maybe that upset the history keeping, as there were a lot of folders that weren't part f the backup history cloudron keeps.

Just to be on the same page, by my.cloudron.io you mean your own dashboard domain my.yourdomain.com ?
Also it should not redirect on raw IP but it should show a placeholder page after the Cloudron went through DNS setup on the very first visit of the raw IP in your browser.

Ah ok. I guess, let us know if it happens again!

Thanks, it's solved. No disk wasn't changed. It's running on AWS.

@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).

@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.

@girish I tried this one, but i get a sad no-go :
Error put object cloudron-testfile. Message: Socket timed out without establishing a connection HTTP Code: TimeoutError
I'll wait the next update 🙂
Tx for the patch

@gerard thanks for testing. A fix for this is coming next release.

The issue is fairly recent. SpamHaus made some policy change when requests come from IPv6 addresses.

@girish

My server is hosted in Singapore by Hosthatch (M247). There does appear to be a significant speed issues with an eclectic selection of hosts.

Disabling IPv6 seems to help a bit. Though, I am migrating servers as we speak.

Thanks again for working out the issue! Much appreciate the speedy support.

--------------------------------------------------------------------------- Speedtest.net (Region: EUROPE) --------------------------------------------------------------------------- Location Latency Loss DL Speed UP Speed Server ISP: HostHatch LLC Nearest 1.15 ms 0.0% 8454.38 Mbps 7303.20 Mbps MyRepublic Singapore - Singapore London, UK 243.81 ms 0.0% 475.24 Mbps 327.99 Mbps M247 Ltd - London Manchester, UK 293.50 ms N/A 273.58 Mbps 245.72 Mbps Vodafone UK - Manchester Dublin, IE 333.20 ms 0.0% 1162.39 Mbps 229.84 Mbps Three Ireland - Dublin Amsterdam, NL 343.10 ms 0.0% 1.15 Mbps 229.11 Mbps Melbicom - Amsterdam Eygelshoen, NL 336.44 ms 0.0% 1.04 Mbps 90.83 Mbps SkyLink Data Center BV - Eygelshoven Paris, FR 309.83 ms N/A 883.20 Mbps 261.13 Mbps ORANGE FRANCE - Paris Marseille, FR 307.23 ms 0.0% 2459.84 Mbps 252.28 Mbps GSL Networks - Marseille Madrid, ES 253.34 ms 0.0% 1220.94 Mbps 272.96 Mbps Orange - Madrid Barcelona, ES 320.58 ms 0.0% 1059.18 Mbps 248.52 Mbps Adamo - Barcelona Lisbon, PT 352.03 ms 0.0% 2.70 Mbps 204.72 Mbps Edgoo Networks - Lisbon Rome, IT 328.83 ms 0.0% 2288.38 Mbps 225.60 Mbps TIM SpA - Rome Milan, IT 310.19 ms 0.0% 1389.43 Mbps 258.39 Mbps Fastweb SpA - Milan Zurich, CH 345.50 ms 0.0% 2.30 Mbps 214.52 Mbps Sunrise Communication AG - Zurich Frankfurt, DE 311.55 ms 0.0% 1550.73 Mbps 252.18 Mbps Deutsche Telekom - Frankfurt am Main Berlin, DE 350.03 ms N/A 1.16 Mbps 109.76 Mbps Misaka Network, Inc. - Berlin Vienna, AT 314.64 ms 0.0% 2455.41 Mbps 251.89 Mbps A1 Telekom Austria AG - Vienna Budapest, HU 362.27 ms 0.0% 0.56 Mbps 199.73 Mbps ATW Internet Kft. - Budapest Gdansk, PL 322.86 ms 0.0% 2236.89 Mbps 251.03 Mbps T-Mobile Polska S.A. - Gdańsk Warsaw, PL 322.19 ms 0.0% 2035.88 Mbps 244.78 Mbps Orange Polska S.A. - Warsaw Lviv, UA 370.95 ms 0.0% 5.47 Mbps 204.86 Mbps Kyivstar - Lviv Kyiv, UA 370.82 ms 0.0% 7.30 Mbps 224.98 Mbps O3 - Kyiv Bucharest, RO 393.82 ms 0.0% 2.77 Mbps 220.72 Mbps Orange Romania SA - Bucuresti Timisoara, RO 352.97 ms 0.0% 0.69 Mbps 201.51 Mbps Digi Helsinki, FI 354.19 ms 0.0% 2.16 Mbps 194.89 Mbps Elisa Oyj - Helsinki Stockholm, SE 360.64 ms 0.0% 0.44 Mbps 201.32 Mbps i3D.net - Stockholm Oslo, NO 371.58 ms 0.0% 1.26 Mbps 205.46 Mbps Telia Norge AS - Oslo Moscow, RU 410.73 ms 0.0% 212.83 Mbps 193.05 Mbps MTS - Moscow Petersburg, RU 400.02 ms 0.0% 243.48 Mbps 206.53 Mbps MegaFon - Saint Petersburg Istanbul, TR 341.64 ms 0.0% 3.60 Mbps 234.38 Mbps Turkcell - Istanbul Tbilisi, GE 368.47 ms 0.0% 2047.49 Mbps 202.74 Mbps Silknet JSC - Tbilisi ---------------------------------------------------------------------------

@nichu42 This could be a reason... I think source causes should be outside of Cloudron.

Let us know 🙂

@jdaviescoates Says me, since www. tells people to expect the main brand website. naked doesn't tell them anything, eg: SaaS apps often use naked for their login, and www. for the marketing site.

Check out pretty much any big brand you can think of that ought to know, www.google.com etc.

I'm sure I read a deeper article on the whys somewhere, but I was in your shorter is better camp for a long time until I realised there were good reasons for the www. being the destination.

Cookies containment from subdomains and use of CDNs are a couple of reasons I remember off the top of my head. I'm sure there's others.

@thoresson yes. If you have a Cloud firewall, you can also whitelist just your IP for port 222.

Will be fixed with next release: https://git.cloudron.io/cloudron/box/-/commit/ec7dabc1c72c2f34c3f3474bc4b3c903bb2d693d

This was a regression in Cloudron 7.7. Thanks for reporting @AartJansen

Fixed in https://git.cloudron.io/cloudron/box/-/commit/1afa2e87ec93881ebcd1f79d83d4477467b40770

@shifty thanks for the update! Glad it got solved.

I'm impressed @fbartels! Sincerely! Your profile should be more like this:

fbartels.png

@visuex are you the same as @cpa ? What is the context of this comment? The original thread was about certs not renewing but in your comment you said it's renewing just fine. Can you open a new thread please if you have some problem?