Cloudron Forum

@arnej said in Problem with setting up a VPN tunnel from on premises machine to Cloudron in Cloud: there was a problem with the Cloudron internal firewall. Once he changed the settings there, the connection was established with no problem. Could you please elaborate what the issue was? Do we need to fix something? Also, useful for future readers who have a similar issue. I could bet you know the feeling of searching a solution and just finding a "I solved it, thanks" post somewhere and think yourself AND HOW?.

@BrutalBirdie think you missed Edit2: Yep its works fine now.

Solution was to connect from iPad to server using the FQDN pointing to the public IP of Cloudron. Unclear why I couldnt connect via private IP, but I was using local DNS pointing the FQDN to the private IP, so I switched that to the public ip. I think that is what fixed it. @girish thanks for the tip on the UDP scan, port was open via UDP on private IP. benneic@MacBookPro ~ % sudo nmap -sU -Pn -p 19132 192.168.1.100 Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-17 08:37 AEST Nmap scan report for # (192.168.1.100) Host is up (0.0025s latency). PORT STATE SERVICE 19132/udp open|filtered unknown Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds

@hakh looks like IPv6 connectivity in your server is not working. Does ping6 ipv6.api.cloudron.io work for you?

@SamGreenwood I would run the troubleshooting tool for a start - https://docs.cloudron.io/troubleshooting/#troubleshooting-tool

Thanks, Looks like IPv6 is not on by default on Hetzner.

@girish Yes, I no longer got the Gmail issues when I created my own system service to implement the iptables rule. So it seemed to do the trick. The IP tables rule to add is really just this: iptables -t nat -I POSTROUTING -s 172.18.0.0/16 -o enp3s0f0 -j SNAT --to-source {FLOATING_IP} Where FLOATING_IP is really just replaced with whatever the recognized IP address is that’s used in the DNS records for the MX record. I supposed it could be further improved to only be applicable to the mail container rather than all Docker traffic. And of course the interface would have to be dynamic too. I guess an alternative is for me to create additional MX records with the other IP addresses but then it’s manually done and prone to mistakes/issues. In my opinion, I think we really need an option to select the outbound IP interface using Cloudron for the mail component, in order to avoid the Gmail issues (and any other provider who will use FCrDNS for verifying or rejecting emails in the future). I recognize this may not be a common concern as most people probably only have the one IP address of each type and so the DNS records if setup automatically by Cloudron will use both the IPv4 and IPv6 address, but for those of us who use a floating/failover IP addresses that we want to be the one true IP address being used, this becomes an issue without that workaround in place.

node.js has a "happy eyeballs" quirk. This causes premature network errors when there is no ipv6 and ipv4 is slow. I have fixed this in https://git.cloudron.io/cloudron/box/-/commit/aefa481c43603d284346d58497b6ff5b462efd88

Closed due to inactivity

For the future generations: better do ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf to avoid messing with system's and cloudron settings Or use netplan's WireGuard capabilities.

Indeed, after sync I enable the IPv6, the app store works just fine as well as the current apps running, i test a few other case this also resolve issues with sometimes the manifest of the updated apps not shown From my experience, don't syn the DNS while having the IPv6 Networ Enabled in Cloudron if no AAAA records in apps or domain I don't know if it happens to anyone else using the Cloudron version 8.x but since I set my networks both work with IPv4 and 6, and it seems everything works normal

Great that you managed to resolve it quickly and thanks for the update here with the solution.

For anyone else out there that is having trouble, I was able to fix this issue by disabling ipv6 within ubuntu. First I did the curl test as mentioned by @nebulon - it worked as expected, but when adding the --ipv6 option it failed. When running "ip a" I could see an ipv6 address was present. Using the link that @playsia supplied, I carried out the steps described in section 1: Disable IPv6 using Sysctl. I didn't need to modify the /etc/rc.local file. Running "ip a" again, there was no more ipv6 addresses shown. I only had these issues after upgrading to V8.0.3 and Ubuntu 24.04.1.

@mmtrade yeah, that's the problem. IPv6 is not working on the server. Can you also try ping6? $ ping6 ipv6.api.cloudron.io PING ipv6.api.cloudron.io (2604:a880:800:10::b66:f001) 56 data bytes 64 bytes from prod.cloudron.io (2604:a880:800:10::b66:f001): icmp_seq=1 ttl=45 time=122 ms 64 bytes from prod.cloudron.io (2604:a880:800:10::b66:f001): icmp_seq=2 ttl=45 time=235 ms

Yup, you are right that Cloudron needs IPv4 currently. IPv6 only setup is coming only in Cloudron 8

@mmtrade Okay, after a thorough analysis of my account. I have a VPS the cheapest, where I could not change the IP address. It remains technical support to solve this and as you in which you manage the server you have the task of securing the server.

@girish Finally, I would like to say that I haven't quite figured out what the problem was. I had used Cloudron bare metal. In the last few days I switched to Windows Server and have Cloudron running in a Linux VM via Hyper V. I then assigned a manual IP there and the problem no longer occurs. I guess it would have been fixed before with a manual IP as well.

@estudios507 If you want to open up an arbitrary port like 8000 from your server, then you have to build a custom app for this . See https://docs.cloudron.io/packaging/tutorial/ . The custom app has to expose 8000 using https://docs.cloudron.io/packaging/manifest/#tcpports . There is no other way on Cloudron for an app to expose a custom port.

@girish Thanks for answering, I will try it and if I still face any issue, I will update by starting my own thread.