Hello everyone, I'm new to this forum (and to Cloudron) and wanted to share that I'm also having issues with IPv6, specifically the PTR6 record. For some reason, my PTR6 record is in a non-working state (red) and shows a null value. BUT, I found a workaround.: Rebooting the server. It temporarily fixes the issue, but after approximatly 12 to 48 hours, the PTR6 record turns red again. I’m not sure why this happens, but I think it might be linked to the IPv6 issues discussed in this thread. My PTR6 record is correctly set on my VPN provider’s side, so the issue seems to come from either Cloudron or Ubuntu 24.04. Interestingly, when I check with MXToolbox, the PTR6 record has the correct value, even though Cloudron reports it as null. My VPS provider has two name servers, and I noticed that MXToolbox retrieves the PTR4 record from the first NS and the PTR6 record from the second NS. This shouldn't normally cause any issues, but I’m mentioning it just in case it’s relevant. After rebooting my server, everything is green again and working as expected. Both Cloudron and MXToolbox now show the correct PTR6 record. Interestingly, this time, the PTR6 response is coming from the first NS instead of the second (in MXToolBox). No idea if there could be a link with cloudron getting a null value maybe when ptr4 and ptr6 answers are note coming from the same NS server ? … ️ Yeahh naaah it seems too weird. Shouldn't be the case. Has anyone else experienced this? Any ideas for a more permanent solution? Thanks!

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

Cloudron Forum

Apps | Demo | Docs | Install

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

infomaniak IPv6 issues

Solved Support

61 Posts 9 Posters 672 Views

This topic was forked from Email sending broken after updating to 8.2.x (due to IPv6 issues) girish

G 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
J Offline
J Offline
jdaviescoates

wrote last edited by

#61

@Gengar
I use Cloudron with Gandi & Hetzner
1 Reply Last reply

3

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

infomaniak IPv6 issues