TLDR : DHCPv6 Issue comes from Cloudron ip6table rules.
TL;DR: The issue with DHCPv6 not working on Cloudron installations on Infomaniak VPS stems from the fact that the required UDP port 546 (client) is not opened in Cloudron's default ip6tables ruleset. Based on RFC 8415, this port needs to be explicitly opened for DHCPv6 to work correctly. @staff, could you please patch cloudron-firewall.sh GitLab to allow traffic on UDP port 546 (client) from port 547 (server), as required by RFC 8415 §7.2 ?
7.2. UDP Ports
Clients listen for DHCP messages on UDP port 546. Servers and relay
agents listen for DHCP messages on UDP port 547.
This ip6tables rule fixes the problem:
sudo ip6tables -I INPUT -p udp --sport 547 --dport 546 -j ACCEPT
A summary of the whole story
A few weeks ago, I started using Cloudron for the first time on an Infomaniak VPS and quickly encountered an issue with my PTR6 record. After about 24 hours, the PTR6 value would switch to null. Upon further inspection, I noticed that my server was losing its IPv6 address. According to my netplan configuration, the lease of my ipv6 address should be renewed via DHCPv6, but the only workaround I found was to reboot the server every 24 hours to renew the lease.
I contacted Infomaniak support, and they confirmed via tcpdump that their DHCPv6 server was sending the correct packets — but it looked like my client wasn't properly renewing the lease. That’s when I dove deep into DHCPv6, and eventually came across RFC 8415, the definitive spec on how DHCPv6 works.
I started capturing traffic with tcpdump, comparing behavior between my Infomaniak VPS (with Cloudron) and a Hetzner VPS. Later, I added a third machine — another Infomaniak VPS, but this time without Cloudron installed.
I quickly learned how IPv6 lease renewals work and dove into a detailed troubleshooting journey. After several emails and sharing tcpdumps, Infomaniak support eventually replied (translated from French):
Hello,
After several days of investigation, we were unable to reproduce the issue on our machines, whether under Ubuntu 24 or other Debian-based systems. We have validated that our DHCP server is not the cause, and the issue most likely originates from your operating system.
It may also be related to a specific configuration of your system, which could explain the difficulty in establishing an IPv6 connection.
Our OpenStack DHCP server (based on dnsmasq) is compliant with RFC 8415 and ignores certain fields as per section 18.3.3 of that RFC.
Since you are the first client to encounter this issue and we were unable to reproduce it, we recommend setting the IPv6 address statically to solve the problem.
This made me even more curious — especially since their initial reply seemed to imply they already knew there were some IPv6 issues?! So I created another Infomaniak VPS with the exact same OS (Ubuntu 24.04 with systemd v255) — but did not install Cloudron.
And voilà — it worked flawlessly. IPv6 was stable, leases were renewed automatically, and there were no interruptions.
That’s when I knew: the problem wasn’t Infomaniak, Ubuntu, or systemd. It was Cloudron.
Digging deeper into RFC 8415, I reviewed the relevant packet exchange logic. Section 7.3 provides a full breakdown of DHCPv6 message types:
7.3. DHCP Message Types
DHCP defines the following message types. The formats of these
messages are provided in Sections8 and9. Additional message types
have been defined and may be defined in the future; see
<https://www.iana.org/assignments/dhcpv6-parameters>. The numeric
encoding for each message type is shown in parentheses.
SOLICIT (1) A client sends a Solicit message to locate
servers.
ADVERTISE (2) A server sends an Advertise message to
indicate that it is available for DHCP
service, in response to a Solicit message
received from a client.
REQUEST (3) A client sends a Request message to request
configuration parameters, including
addresses and/or delegated prefixes, from a
specific server.
CONFIRM (4) A client sends a Confirm message to any
available server to determine whether the
addresses it was assigned are still
appropriate to the link to which the client
is connected.
RENEW (5) A client sends a Renew message to the
server that originally provided the
client's leases and configuration
parameters to extend the lifetimes on the
leases assigned to the client and to update
other configuration parameters.
REBIND (6) A client sends a Rebind message to any
available server to extend the lifetimes on
the leases assigned to the client and to
update other configuration parameters; this
message is sent after a client receives no
response to a Renew message.
REPLY (7) A server sends a Reply message containing
assigned leases and configuration
parameters in response to a Solicit,
Request, Renew, or Rebind message received
from a client. A server sends a Reply
message containing configuration parameters
in response to an Information-request
message. A server sends a Reply message in
response to a Confirm message confirming or
denying that the addresses assigned to the
client are appropriate to the link to which
the client is connected. A server sends a
Reply message to acknowledge receipt of a
Release or Decline message.
RELEASE (8) A client sends a Release message to the
server that assigned leases to the client
to indicate that the client will no longer
use one or more of the assigned leases.
DECLINE (9) A client sends a Decline message to a
server to indicate that the client has
determined that one or more addresses
assigned by the server are already in use
on the link to which the client is
connected.
RECONFIGURE (10) A server sends a Reconfigure message to a
client to inform the client that the server
has new or updated configuration parameters
and that the client is to initiate a
Renew/Reply, Rebind/Reply, or
Information-request/Reply transaction with
the server in order to receive the updated
information.
INFORMATION-REQUEST (11) A client sends an Information-request
message to a server to request
configuration parameters without the
assignment of any leases to the client.
RELAY-FORW (12) A relay agent sends a Relay-forward message
to relay messages to servers, either
directly or through another relay agent.
The received message -- either a client
message or a Relay-forward message from
another relay agent -- is encapsulated in
an option in the Relay-forward message.
RELAY-REPL (13) A server sends a Relay-reply message to a
relay agent containing a message that the
relay agent delivers to a client. The
Relay-reply message may be relayed by other
relay agents for delivery to the
destination relay agent.
The server encapsulates the client message
as an option in the Relay-reply message,
which the relay agent extracts and relays
to the client.
(Source: RFC 8415 §7.3)
What I observed in the packet capture from my Infomaniak VPS WITH Cloudron installed:
- At T1: the client (Cloudron server) sends a RENEW.
- The DHCPv6 server replies with a REPLY.
- But the client doesn't apply the reply. It’s as if it silently discards the packet.
- The client repeats the RENEW cycle until T2.
- At T2: the client sends REBIND messages — again, no response.
- The client repeats the REBIND cycle until the end of the lease.
- Finally, the client sends a RELEASE, and the IPv6 address is dropped.
Meanwhile, on my other Infomaniak VPS without Cloudron, it all works fine:
- A RENEW is sent
- A REPLY is received and applied — done.
So what was Cloudron doing differently?
I restarted reading RFC 8415 more carefully and then found this in section 7.2:
7.2. UDP Ports
Clients listen for DHCP messages on UDP port 546. Servers and relay
agents listen for DHCP messages on UDP port 547.
(Source: RFC 8415 §7.2)
That’s it! The REPLY packets from the DHCPv6 server come from port 547 to port 546 — but Cloudron's ip6tables rules don’t allow this.
I reviewed the Cloudron firewall script here:
https://git.cloudron.io/platform/box/-/blob/master/setup/start/cloudron-firewall.sh
And yes — this rule was missing.
I verified ip6tables on my Infomaniak VPS with Cloudron and found that it wasn't explicitly allowed, so it's dropped.
But on my non-Cloudron Infomaniak VPS, ip6tables was completely open and allowed this traffic.
I added this rule manually on my Infomaniak VPS with Cloudron:
sudo ip6tables -I INPUT -p udp --sport 547 --dport 546 -j ACCEPT
Boom. Everything worked. DHCPv6 leases were renewed, no more dropped IPv6, and my PTR6 issue was gone. It’s now been 72 hours and everything remains stable.
Hetzner users don’t encounter this because they’re given static IPv6 addresses, meaning no DHCPv6 exchange is needed. But any provider (like Infomaniak) that uses dynamic IPv6 with DHCPv6 will hit this issue.
The fix
To gain proper DHCPv6 support in Cloudron, add this rule:
ip6tables -I INPUT -p udp --sport 547 --dport 546 -j ACCEPT
But ideally, this rule should be added in cloudron-firewall.sh (I guess it's here ? And if not only there, then integrated into the firewall setup logic for Cloudron installations.)
Final thoughts
This was not a systemd bug nor an Infomaniak issue. This was a firewall missing configuration on Cloudron’s part — and it only becomes visible in DHCPv6 environments.
@Girish @Nebulon @joseph , could you please consider updating the Cloudron firewall to include this rule?
Now that Infomaniak works flawlessly with Cloudron (IPv6 included), perhaps you could also consider integrating them into Cloudron as a DNS provider using their API? 
Feature request: Add DNS provider Infomaniak => Please people reading this thread, upvote this feature request to have a new provider 
Thanks for reading — I hope this helps others avoid the days of debugging I went through!
Cheers!
Gengar
