infomaniak IPv6 issues

[Gengar]

Hey everyone & @joseph & @girish ,

I wanted to share an update regarding the IPv6 lease renewal issue I'm experiencing on my VPS hosted at Infomaniak, in case others are hitting similar problems.

After reaching out to Infomaniak support a few days/weeks ago, they acknowledged the issue and suggested a temporary workaround: running a cron job every 12 hours to trigger a DHCPv6 renewal. While I appreciated the suggestion, I’ve run a series of tests and unfortunately none of the commonly available methods for forcing a lease renewal actually work reliably on my system.

The instance runs Ubuntu 24.04 Server, which uses systemd-networkd via Netplan. Here's a quick summary of what I tried:

• networkctl renew <interface>: No effect, no logs, no renewal.
• systemctl restart systemd-networkd: Breaks IPv6 completely (no address is reacquired).
• systemctl reload systemd-networkd: No effect.
• Full IPv6 stack reset (disable/enable IPv6 + netplan apply + Docker restart): Works, but too disruptive.
• Reboot: The only consistently working method, but not viable on a 24/7 system.

Interestingly, I found this systemd bug on their GitHub Issues which describes very similar symptoms—systemd-networkd seems to not renew IPv6 lease even with networkctl renew <interface> .

After a long tcpdump session (about 17:30 CEST to 09:20 the next day) on my VPS, I confirmed the following:

• My server sends DHCPv6 RENEW messages.
• Infomaniak’s OpenStack-based infrastructure replies correctly with a REPLY containing a new lease (24h, with valid preferred/valid lifetimes).
• Despite that, my client doesn’t apply the lease, continues renewing until T2 expires, then sends multiple REBIND messages.
• Eventually, the client sends a DHCPv6 RELEASE.

So far, Infomaniak’s support has been excellent. They confirmed via a tcpdump on their OpenStack DHCPv6 server that the REPLY messages are correctly formed and sent in response to my RENEW requests. From their logs, my client also appears to receive these replies — but doesn't act on them properly. I was able to confirm the same behavior with a tcpdump I ran locally on my VPS: RENEW is sent, REPLY is received, yet the lease is not renewed, leading to a fallback to REBIND and eventually a RELEASE.

Based on what other forum members mentioned, this behavior does not seem to occur on providers like Hetzner. That might be because Hetzner's DHCPv6 implementation handles edge cases like REBIND with lifetime=0 more gracefully even when lifetimes are set to zero — whereas Infomaniak’s current setup might not interpret these ambiguous packets well (even though they are technically valid per RFC 8415).

According to RFC 8415 §21.6, clients should set preferred-lifetime and valid-lifetime to 0 in RENEW and REBIND messages. Servers must ignore these values. This means my client is doing things correctly, but perhaps the server isn’t ignoring the values as it should.

---

Request to the community:
If anyone is using a VPS at Hetzner with Ubuntu 24.04, could you please run a short tcpdump capture and open it in Wireshark?
Apply the filter dhcpv6 and check if your IPv6 lease is successfully renewed after a RENEW / REPLY exchange — or if it only happens after REBIND.

That would help understand why it works with Hetzner and doesn't work with Infomaniak.

I suspect there is a general issue with systemd that doesn't takes into account the REPLY. And if it's the case it would means it works on Hetzner only because the REBIND packet is answered differently by their DHCPv6 than how Infomaniak handles it.

Thanks in advance!

Cheers,
Gengar

[joseph]

@Gengar great write up! Thanks for the follow up . I don't know much about DHCPv6 internals but excellent material for me read up.

[Gengar]

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 tcpdump on 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 forever

Both valid_lft and preferred_lft are set to forever.

To confirm how the interface was configured, I also checked Netplan:

sudo cat /etc/netplan/*.yaml

And 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: true

This 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 — no RENEW, REBIND, or RELEASE. 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 forever

This time, we clearly see the dynamic flag 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/*.yaml

network:
  version: 2
  ethernets:
    <interface>:
      match:
        macaddress: "my_mac"
      dhcp4: true
      dhcp6: true
      accept-ra: true
      set-name: "<interface>"
      mtu: 1500

This confirms that both dhcp6: true is 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 received REPLY from a DHCPv6 RENEW) 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

[jdaviescoates]

@Gengar

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

[BrutalBirdie]

@Gengar Chapeau!

[Gengar]

@BrutalBirdie Merci

[Gengar]

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.

[Gengar]

@joseph Do you know if it will be patched in cloudron to support DHCPv6 ?

[girish]

Thanks @Gengar . I have put it in the code - https://git.cloudron.io/platform/box/-/commit/7f87af5a0827af431a3ecb8bfca4bc693c3707b0

[Gengar]

@girish thank you 🤩

[Gengar]

@girish will it be applied in version 8.3.2 of Cloudron ?

[girish]

It's not, no. 8.3.2 only has a single change to fix postgres to support immich .