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


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
GengarG

Gengar

@Gengar
About
Posts
70
Topics
5
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • [TUTORIAL] Get your Cloudron Notifications on Telegram with full details.
    GengarG Gengar

    [TUTORIAL] Get your Cloudron Notifications on Telegram with full details.

    Wanna have those kind of notifications ?
    755c6a1e-d6e6-4391-b2c2-e4ffda589caa-image.png

    Here is a tutorial that will guide you step by step how to do it.

    1) Install N8N on your Cloudron instance.

    fcb56874-be95-46b4-bacf-a024ac6518e1-image.png

    2) Create a Telegram Channel (Public or Private) and create a Telegram Bot (it's very easy)

    First, open Telegram and create a new channel. You can choose to make it public or private. Give it a name, like "Cloudron Notifications". You’ll need the channel ID later.
    6e2fcfb7-c211-40e3-b5eb-e9a95e53b5d4-image.png

    Then, search for "BotFather" in Telegram and start a chat. Type /start, then /newbot. Give your bot a name and a username (the username must end with "bot", like "cloudron_notifier_bot"). BotFather will give you a token – copy it and save it, you’ll need it in n8n.

    Now go back to your Telegram channel, open the channel settings, go to "Administrators", and add your bot as an admin. Make sure it has permission to post messages. This will allow n8n to send messages to the channel using your bot.

    TIPS : To get your channel ID, you can use Uptime Kuma (in Cloudron) , it has a way of retriving it automatically if you posted in the channel before. Here is a screen of Uptime Kuma and the "Retrive automatically" option (named "Récupérer automatiquement" in my screenshot).
    be7e7ba7-f33d-4aee-b4fd-c361078582a5-image.png

    3) n8n => THE FUN PART !

    Now let's automate everything in n8n !

    Start by creating a credential in n8n, it will be your Chat ID and bot Token generated before with the help of BotFather :
    f373b788-3c9e-4092-8720-517e9c51f4c8-image.png

    Once done, hit "Create a Workflow" :
    c7d3272c-e50f-44b5-aa43-7e77db051873-image.png

    Here is what we are going to create :
    3616bfa9-2c14-4494-ba1d-68c5f42bbd1e-image.png

    But you can skip the creation using this cheatcode => Save the following code in a .json file and import it in n8n. You will have to replace the informations starting with REPLACE_WITH_ in the json file or directly in n8n after the import :

    {
      "name": "Cloudron notifications - optimized",
      "nodes": [
        {
          "parameters": {
            "mode": "runOnceForEachItem",
            "jsCode": "const staticData = $getWorkflowStaticData('global');\nstaticData.notifiedIds = staticData.notifiedIds || [];\n\nif (staticData.notifiedIds.includes($json.id)) {\n  return null; // already sent, skip\n}\n\nstaticData.notifiedIds.push($json.id);\n\nreturn {\n  json: {\n    ...$json,\n    status: `🆕 À envoyer: ${$json.id}`\n  }\n};"
          },
          "id": "78efcc79-4982-4770-9156-e928b15da511",
          "name": "Check & Store ID",
          "type": "n8n-nodes-base.code",
          "typeVersion": 2,
          "position": [
            580,
            -600
          ]
        },
        {
          "parameters": {
            "chatId": "-REPLACE_WITH_YOUR_TELEGRAM_CHAT_ID",
            "text": "=📣 <b>Cloudron Notification</b>\n<b>Title:</b> {{ $json.title || \"Sans titre\" }}\n<b>Message:</b> {{ $json.message || \"Pas de contenu\" }}\n",
            "additionalFields": {
              "parse_mode": "HTML"
            }
          },
          "id": "aa664df7-4d0c-49b4-b356-1c4d48340e08",
          "name": "Send Telegram Message",
          "type": "n8n-nodes-base.telegram",
          "typeVersion": 1,
          "position": [
            800,
            -600
          ],
          "webhookId": "REDACTED",
          "credentials": {
            "telegramApi": {
              "id": "REPLACE_WITH_YOUR_TELEGRAM_CREDENTIAL_ID",
              "name": "Telegram-REPLACE_WITH_YOUR_DOMAIN"
            }
          }
        },
        {
          "parameters": {
            "jsCode": "return $json.notifications.map(n => ({ json: n }));"
          },
          "id": "0475daf5-1e32-4a7b-a4c7-c9d0eed00f3c",
          "name": "Split Notifications",
          "type": "n8n-nodes-base.code",
          "typeVersion": 2,
          "position": [
            360,
            -600
          ]
        },
        {
          "parameters": {
            "conditions": {
              "string": [
                {
                  "value1": "={{ $json.notifications.length }}",
                  "operation": "notEqual",
                  "value2": "0"
                }
              ]
            }
          },
          "id": "820ea8b0-98e7-46de-95e7-2a3de2f1aca8",
          "name": "Notification exists ?",
          "type": "n8n-nodes-base.if",
          "typeVersion": 1,
          "position": [
            140,
            -600
          ]
        },
        {
          "parameters": {
            "url": "https://my.REPLACE_WITH_YOUR_DOMAIN.XYZ/api/v1/notifications?acknowledged=false&page=1&per_page=2",
            "options": {},
            "headerParametersUi": {
              "parameter": [
                {
                  "name": "Authorization",
                  "value": "Bearer REPLACE_WITH_YOUR_CLOUDRON_REAN_ONLY_API_TOKEN"
                }
              ]
            }
          },
          "id": "0ae368d4-82bd-4908-855c-80aab9303079",
          "name": "Get Cloudron Notifications",
          "type": "n8n-nodes-base.httpRequest",
          "typeVersion": 1,
          "position": [
            -80,
            -600
          ]
        },
        {
          "parameters": {
            "rule": {
              "interval": [
                {
                  "field": "minutes",
                  "minutesInterval": 1
                }
              ]
            }
          },
          "id": "0483e050-46ef-4d64-9b93-e3fefd5f46c8",
          "name": "Schedule Trigger",
          "type": "n8n-nodes-base.scheduleTrigger",
          "typeVersion": 1.2,
          "position": [
            -300,
            -600
          ]
        }
      ],
      "pinData": {},
      "connections": {
        "Check & Store ID": {
          "main": [
            [
              {
                "node": "Send Telegram Message",
                "type": "main",
                "index": 0
              }
            ]
          ]
        },
        "Split Notifications": {
          "main": [
            [
              {
                "node": "Check & Store ID",
                "type": "main",
                "index": 0
              }
            ]
          ]
        },
        "Notification exists ?": {
          "main": [
            [
              {
                "node": "Split Notifications",
                "type": "main",
                "index": 0
              }
            ]
          ]
        },
        "Get Cloudron Notifications": {
          "main": [
            [
              {
                "node": "Notification exists ?",
                "type": "main",
                "index": 0
              }
            ]
          ]
        },
        "Schedule Trigger": {
          "main": [
            [
              {
                "node": "Get Cloudron Notifications",
                "type": "main",
                "index": 0
              }
            ]
          ]
        }
      },
      "active": true,
      "settings": {
        "executionOrder": "v1"
      },
      "versionId": "693afd07-69b9-4335-8dbb-6db99b7bae56",
      "meta": {
        "templateCredsSetupCompleted": true,
        "instanceId": "REDACTED"
      },
      "id": "WMS9ieiGEvYuv2TF",
      "tags": []
    }
    

    Schedule Trigger

    It's just a cron job that will run each 60 seconds.
    Setup it like this :
    6897f625-1904-461e-a194-be5cd7978947-image.png

    Get Cloudron Notifications - HTTP Request

    So the idea of this node is to get the notifications from cloudron. For this you will need a Cloudron API Token with read rights.

    To do this, go to your Cloudron > Click on your username > Profile :
    9928c8dd-0c1d-4fef-93ed-0fdb33b9330d-image.png

    Then create a new api token in "read only" (lecture seule on my screenshot) .
    d5c0ec73-6d63-477a-a253-5f143731e932-image.png

    Copy and save it somewhere , we will need it now in n8n.

    Go back to n8n, and add the next block, an HTTP Request:
    6eac6958-96da-44de-b800-9cadfdb39733-image.png

    Set it up as follow :
    00616c27-1bff-4439-8563-63bbef71c780-image.png

    URL :
    https://my.TLD.xyz/api/v1/notifications?acknowledged=false&page=1&per_page=2

    Headers :
    Name : Authorization
    Value : Bearer YOUR_CLOUDRON_API_READ_ONLY_TOKEN

    IF : Notifications exists ?

    Notifications exists is an IF block.

    Set it up as below :
    9919b0c1-eaff-401f-b0d2-5390c3cb2e2a-image.png

    Value 1
    {{ $json.notifications.length }}

    Code : Split Notifications

    Here add a code block with the following code :
    53037783-0278-43c5-9278-d0411ba9caa6-image.png

    return $json.notifications.map(n => ({ json: n }));
    

    The mode MUST BE "Run Once for All Items".

    Code : Check & Store ID

    In order to avoid spamming you each 60 seconds, we will setup a second code block that will check is the notification has already been sent. And if it has not been set il will continue to send it and it will store the ID of this notification in memory ready to compare with the next notification ID.

    70a76ca5-cfdd-4a8f-8e53-1031f12d6485-image.png

    Here is the code used in this block :

    const staticData = $getWorkflowStaticData('global');
    staticData.notifiedIds = staticData.notifiedIds || [];
    
    if (staticData.notifiedIds.includes($json.id)) {
      return null; // already sent, skip
    }
    
    staticData.notifiedIds.push($json.id);
    
    return {
      json: {
        ...$json,
        status: `🆕 À envoyer: ${$json.id}`
      }
    };
    

    Send the notification to Telegram

    And the last block, sending the notification to your telegram channel using your telegram bot. Here we are using the credentials you created before in n8n.

    Set it up as follow :
    13362fcd-0fcc-4787-b838-d988cea1ff76-image.png

    Here is the HTML text I use in the text field :

    📣 <b>Cloudron Notification</b>
    <b>Title:</b> {{ $json.title || "Sans titre" }}
    <b>Message:</b> {{ $json.message || "Pas de contenu" }}
    
    

    AND THAT's IT ! ENJOY !

    Just Save It and Activate IT :
    43a227aa-9ba6-4c52-b376-f394296f21e2-image.png

    And receive all your Cloudron notifications :
    755c6a1e-d6e6-4391-b2c2-e4ffda589caa-image.png

    Discuss

  • infomaniak IPv6 issues
    GengarG 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

    Support infomaniak ipv6

  • infomaniak IPv6 issues
    GengarG Gengar

    @robi said in Email sending broken after updating to 8.2.x (due to IPv6 issues):

    How did you end up connecting Cloudron notifications to Uptime Kuma?

    I’m using Uptime Kuma to monitor the Cloudron notifications using Cloudron API.

    The API endpoint I monitor is:

    https://my.domain.tld/api/v1/notifications?acknowledged=false&page=1&per_page=2
    

    This returns a list of unacknowledged notifications. In Uptime Kuma, I use the “Keyword exists” monitor type and set the keyword to:

    "notifications":[]
    

    When this keyword is not found, it means there are new notifications waiting to be read. Uptime Kuma then considers the service as “down” and sends me an alert to a Telegram channel. Once I acknowledge the notification in the Cloudron UI, the keyword is present again, and Kuma marks the monitor as “up”.

    To authenticate the API call, you need to add a custom header in Uptime Kuma:

    {
      "authorization": "Bearer YOUR_CLOUDRON_API_TOKEN"
    }
    

    You can generate the API token from your Cloudron account (Account > API Tokens).

    I saw this solution somewhere on the forum a while ago, but I don’t remember exactly where or who shared it.

    Support infomaniak ipv6

  • [TUTORIAL] Get your Cloudron Notifications on Telegram with full details.
    GengarG Gengar

    Hey @BrutalBirdie, Yeah I'm aware and I planned to but I was too tired yesterday evening. I started to write the tutorial and I was like "Oh hell, why did I start so late to do that, I have to wake up so early tomorrow" , and I tried to speed run the tutorial.

    I will export it today , remove my API tokens from the json and update the tutorial by adding a chapter "fast way - importing json" or something similar .

    Discuss

  • infomaniak IPv6 issues
    GengarG 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

    Support infomaniak ipv6

  • Add DNS Provider - Infomaniak
    GengarG Gengar

    Hello everyone,

    I’d like to suggest adding Infomaniak as a DNS provider in Cloudron.

    34e8a85c-38cd-4c64-8fa5-ac65c10751a9-image.png

    Infomaniak is a leading hosting provider based in Switzerland and is currently the #1 domain registrar & hosting provider in the country. They also offer a well-documented API that supports DNS record management, which seems to make the integration feasible.

    Here is the API documentation:
    👉 Infomaniak API - Developer Portal – Getting Started
    👉 Update dns record

    398a3294-7fc0-45ec-b1d7-1b2af4b249ee-image.png

    From what I’ve seen, the API seems to provide all the necessary features to manage DNS records (e.g., creating and updating them), making it a great candidate for Cloudron integration.

    Would love to hear your thoughts on this!

    Best Regards,
    Gengar

    Feature Requests domains dns

  • AppFlowy
    GengarG Gengar

    I've just discovered AppFlowy and this app seems awesome ! Would love to see it in Cloudron. I'm a notion power user, and I can't wait to ditch notion.

    But as @jadudm said, seems like docker-compose based app are not easy to convert to a single dockerfile to work with Cloudron...

    App Wishlist

  • infomaniak IPv6 issues
    GengarG 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

    Support infomaniak ipv6

  • Ability to import backups from computer disk rather than needing to SCP files
    GengarG Gengar

    I've just ran into the same issue, would be awesome to have this option !

    Feature Requests restore import

  • infomaniak IPv6 issues
    GengarG Gengar

    @BrutalBirdie Merci 🙂

    Support infomaniak ipv6

  • infomaniak IPv6 issues
    GengarG 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.

    Support infomaniak ipv6

  • Ability to import backups from computer disk rather than needing to SCP files
    GengarG Gengar

    @composer I did this exact process last week.

    For the third point, I imported it back from my S3 API compatible storage and then I've chosen the .tar backup of the app only and it restored the app correctly.

    Feature Requests restore import

  • Docs - Alternative to Notion / Outline with OIDC, GDPR compliant, PDF Export (with template) etc...
    GengarG Gengar

    @Neiluj Wow this looks incredible !
    And the image at the end of the github is priceless ,see below :

    8d9caaaf-0abe-40c3-b199-f52255ae475e-image.png

    App Wishlist

  • infomaniak IPv6 issues
    GengarG Gengar

    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!

    Support infomaniak ipv6

  • Make Cloudron SSO login more explicit
    GengarG Gengar

    I agree with @perelin , as a new user to cloudron it’s not that obvious to understand which login you have to use when .

    Would be great to have better and unified UI for login pages , it would improve the UX .

    Feature Requests

  • AppFlowy
    GengarG Gengar

    @robi Thanks for your clarification, and you're absolutely right that a docker-compose setup can be translated into a single Dockerfile. I didn’t mean to suggest it's impossible or overly complex from a technical point of view. It just seems to me, based on what I’ve read on the forum and what @jadudm pointed out, that apps originally built with docker-compose tend to require more work to adapt to Cloudron. So they don’t always feel like the easiest starting point compared to more straightforward "quick win" Dockerfile-based apps.

    App Wishlist

  • [TUTORIAL] Get your Cloudron Notifications on Telegram with full details.
    GengarG Gengar

    I've added the json template in the tutorial in chapter 3 "3) n8n => THE FUN PART !"

    Discuss

  • infomaniak IPv6 issues
    GengarG Gengar

    @nebulon Yeah, I’m aware the PTR6 record is set by my VPS provider, and I’ve double-checked that it’s configured correctly on their end. MXToolBox confirms everything looks good.

    The issue seems to be on Cloudron’s side: it occasionally shows the PTR6 record as “null”. But this only happens after some time — for example, right after a full reboot, everything works fine. Then, 24 to 48 hours later, Cloudron throws an error saying the email setup isn’t correct, and it shows the PTR6 value as “null”.

    What’s strange is that MXToolBox still shows the correct PTR6 value, exactly as set on my VPS provider’s side. So the record itself is definitely working.

    I’ve noticed this often happens after an app update. I’m not 100% sure it’s the cause, but every time the issue appears, it’s usually right after an update.

    Not sure if this is a Cloudron issue or something with Ubuntu, but for some reason, only my server fails to resolve the PTR6 correctly after a while.

    Edit @ 9:00 PM CET: MiroTalk P2P has been updated automatically at 9PM CET. And atm (9:05PM CET) my PTR6 record is still resolved correctly by Cloudron. I will monitor.
    2025-03-22 21_05_41.png

    @joseph => fyi

    Edit @ 9:40 PM CET : Cloudron doesn't resolve my PTR6 record anymore...
    2025-03-22 21_48_12.png
    2025-03-22 21_43_46.png

    But on MXToolBox Side it's still working fine :
    2025-03-22 21_54_36-PTR6.png

    It's only cloudron that returns a "null" value for PTR6.

    And I guess the value is null because when I do :

    host -t PTR <ip6> 127.0.0.150
    

    I have a time out ...
    2025-03-21 21_20_19-VPS.png

    BTW, I use Uptime Kuma to notify me on Telegram each time there is a notification in Cloudron. And usually notifications are about automatic app updates and my Cloudron will fail to resolve my PTR6 record after this. In this example it was about 40 minutes after the update / the notification. Could also be linked to notifications, idk. But there is something with updates or notifications and PTR6 record resolving on Cloudron/Ubuntu side.

    Support infomaniak ipv6

  • New Docker Hub usage and limits - Starting 1st April 2025
    GengarG Gengar

    @BrutalBirdie Oh interesting, I didn't know that but yeah makes sense. Thx for the input !

    Discuss

  • infomaniak IPv6 issues
    GengarG Gengar

    @girish I think I have very interesting new information to narrow down the possibilities for the root cause. What I did is that I tried to restart every component/service I could, starting from the most specific (mail container) to the most general (full system reboot):

    Service / Component restarted Result
    sudo docker restart mail NOK
    sudo systemctl restart box NOK
    sudo systemctl restart docker NOK – I had to restart apps manually due to bad gateway / 500 errors.
    sudo systemctl restart unbound NOK
    sudo systemctl restart systemd-resolved NOK
    sudo systemctl restart systemd-networkd NOK
    sudo netplan apply NOK
    sudo reboot OK – PTR6 works again.

    So I asked myself: what could exist between the NOK and OK state that I hadn't tried?

    I decided to target the IPv6 stack of the OS directly. I ran:

    sudo ip -6 neigh flush all
    sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
    sleep 2
    sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0
    

    ➡️ After this, it was still NOK, but interestingly it reported the PTR6 = null state instantly, instead of the usual 1–2 minute delay. That suggested something was cleared or reset => Makes sense as I flushed.

    After flushing the IPv6 neighbours and disabling / re-enabling the ipv6 module I've restarted netplan and docker :

    sudo netplan apply
    sudo systemctl restart docker
    

    ➡️ Again, after restarting Docker I had to manually restart all apps (some with bad gateway / nginx errors like n8n). But...


    IT WORKED!

    The PTR6 value was immediately resolved again and Cloudron no longer shows null. So this suggests that the root cause may lie somewhere in the interaction between the kernel IPv6 stack and Docker’s networking layer ? particularly after updates...

    What do you think @girish ? What could be the root cause ?

    Support infomaniak ipv6
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search