infomaniak IPv6 issues
-
Hey again everyone & @joseph & @girish,
Following up on my previous post regarding the IPv6 lease renewal issue on Infomaniak’s VPS — I’ve done some deeper testing by ordering a VPS on Hetzner to compare how things were set up between Hetzner and Infomaniak.
My idea was to launch a
tcpdumpon a Hetzner VPS (running Ubuntu 24.04 with systemd 255, just like Infomaniak) to observe DHCPv6 behavior — but first, I needed to know how long their IPv6 lease lasts in order to avoid capturing traffic for too many hours unnecessarily.So I started out by doing a:
ip -6 address show dev <interface>on the freshly provisioned Hetzner VPS.
And what a surprise! No lease at all. See below:
2: <interface>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet6 my_public_ipv6 scope global valid_lft forever preferred_lft forever inet6 my_ipv6_unicast_link_local_address scope link valid_lft forever preferred_lft foreverBoth
valid_lftandpreferred_lftare set toforever.To confirm how the interface was configured, I also checked Netplan:
sudo cat /etc/netplan/*.yamlAnd here is the configuration:
network: version: 2 ethernets: <interface>: match: macaddress: "my_mac" addresses: - "my_public_ipv6" nameservers: addresses: - 2a01:4ff:ff00::add:2 - 2a01:4ff:ff00::add:1 dhcp4: true set-name: "<interface>" routes: - to: "default" via: "fe80::1" on-link: trueThis confirms that IPv6 is statically configured on Hetzner. There's no
dhcp6: true, and the IPv6 address is explicitly assigned. Therefore, no lease exists, and no renewal occurs. There’s no interaction with any DHCPv6 server — noRENEW,REBIND, orRELEASE. This directly explains why the issue observed at Infomaniak never manifests on Hetzner: the client never enters the renewal cycle in the first place.In contrast, here’s what we get on Infomaniak:
ip -6 address show dev <interface>Output:
2: <interface>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 altname <interface_alt> inet6 my_public_ipv6 scope global dynamic noprefixroute valid_lft 65046sec preferred_lft 65046sec inet6 my_ipv6_unicast_link_local_address scope link valid_lft forever preferred_lft foreverThis time, we clearly see the
dynamicflag and a limited lease time (~18 hours remaining when the command was run), indicating a DHCPv6 assignment.To double-check, I also reviewed the Netplan config on Infomaniak:
sudo cat /etc/netplan/*.yamlnetwork: version: 2 ethernets: <interface>: match: macaddress: "my_mac" dhcp4: true dhcp6: true accept-ra: true set-name: "<interface>" mtu: 1500This confirms that both
dhcp6: trueis enabled — meaning the system explicitly requests an IPv6 lease from the DHCPv6 server.This explains why the issue is completely absent at Hetzner — their static configuration avoids the renewal mechanism entirely, so the "potentially" buggy part of
systemd-networkd(which fails to apply the receivedREPLYfrom a DHCPv6RENEW) is never triggered. On Infomaniak, where renewal is mandatory, the problem becomes immediately visible as soon as the system enters the lease refresh cycle.I’m now wrapping up my investigation and will send my findings to Infomaniak.
Have a good one,
Gengar -
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.shGitLab 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.shAnd 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 ACCEPTBoom. 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 fixTo gain proper DHCPv6 support in Cloudron, add this rule:
ip6tables -I INPUT -p udp --sport 547 --dport 546 -j ACCEPTBut 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
-
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.shGitLab 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.shAnd 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 ACCEPTBoom. 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 fixTo gain proper DHCPv6 support in Cloudron, add this rule:
ip6tables -I INPUT -p udp --sport 547 --dport 546 -j ACCEPTBut 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
-
@Gengar Chapeau!
@BrutalBirdie Merci
-
Hello everyone & @staff ,
After a few days I can confidently say that the only drawback of my current workaround is that it’s not persistent — I have to reapply it after each reboot.
However, once the issue is resolved within Cloudron’s firewall rules, everything should work seamlessly without further intervention.
-
G Gengar referenced this topic
-
Thanks @Gengar . I have put it in the code - https://git.cloudron.io/platform/box/-/commit/7f87af5a0827af431a3ecb8bfca4bc693c3707b0
