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
  1. Cloudron Forum
  2. Support
  3. Email sending broken after updating to 8.2.x (due to IPv6 issues)

Email sending broken after updating to 8.2.x (due to IPv6 issues)

Scheduled Pinned Locked Moved Solved Support
ipv6emailupdate8.2.3
74 Posts 13 Posters 7.4k Views 13 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A AartJansen

    So with a self hosted install I would need to ask the ISP to set up the ipv6 PTR like they ip4 record ?

    J Online
    J Online
    joseph
    Staff
    wrote on last edited by
    #41

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

    So with a self hosted install I would need to ask the ISP to set up the ipv6 PTR like they ip4 record ?

    yes

    1 Reply Last reply
    3
    • avatar1024A avatar1024

      I've started to have this issue again randomly (emails only sometimes bounce...helpful I know) despite having IPv6 is disabled on both Cloudron and on the Network interface for that server.

      avatar1024A Offline
      avatar1024A Offline
      avatar1024
      wrote on last edited by
      #42

      @avatar1024 Right so here I had made a mistake, I hadn't disabled IPv6 on the network interface on my server persistently and I reckon it got reactivate after a reboot. I've updated my post here for clarity: https://forum.cloudron.io/post/100505

      1 Reply Last reply
      1
      • dsp76D Offline
        dsp76D Offline
        dsp76
        wrote on last edited by
        #43

        For Hetzner... it looks like the PTR setting for an IPv6 is not checking if its correctly set. You will need to add the last piece - in my case "::1" - to the PTR record - even if Hetzner also accepts "::" only. I guessed this will cover the whole range - but I was wrong.

        image.png

        (Ask me about B2B marketing automation & low code business solutions, if thats interesting for you.)

        humptydumptyH 1 Reply Last reply
        3
        • dsp76D dsp76

          For Hetzner... it looks like the PTR setting for an IPv6 is not checking if its correctly set. You will need to add the last piece - in my case "::1" - to the PTR record - even if Hetzner also accepts "::" only. I guessed this will cover the whole range - but I was wrong.

          image.png

          humptydumptyH Offline
          humptydumptyH Offline
          humptydumpty
          wrote on last edited by humptydumpty
          #44

          @dsp76 I have it as ::/64 which is my full IPv6 address as shown at dash > IP's > IPv6 and it's been working fine for me. In case it matters, I'm on the CCX plan (VDS).

          Edit: asked chatgpt about this and it looks like I got it wrong too (possibly a security issue too). But, it mentioned that ::1 might be reserved by Hetzner so we'll need to manually assign it to something else.

          That means your IPv6 address is `xxxx:xxx:xx:xxxx::1`, and it’s using the `/64` subnet.  
          
          If others have had issues with `::1`, you might want to pick another address, like `::100` or `::abcd`. You can assign it manually with:  
          
          
          ip -6 addr add xxxx:xxx:xx:xxxx::100/64 dev eth0
           
          
          Then, set the PTR record for `xxxx:xxx:xx:xxxx::100` in Hetzner’s panel. If everything works, make it persistent by adding it to your network config (`/etc/network/interfaces` or equivalent, depending on your OS). 
          

          Edit 2: so dug some more and setting the ptr to cover the entire /64 block is a bit riskier. With that said, it's OK in my case since I'm using Hetzner's vDedicated (CCX) plan and according to Mr.GPT, I'm the sole user on for that IP. Also, security wise, I'm in the clear if I have set SPF, DMARC, and DKIM records.

          I did a Reverse lookup on Mxtoolbox for my IPv6 address and it's reporting back my mailserver domain 👍 .

          Give it a shot and see if that works for you.

          1 Reply Last reply
          2
          • jdaviescoatesJ jdaviescoates

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

            The check and thus the warning is fixed with https://git.cloudron.io/platform/box/-/commit/6fcfa6cac06cf2f0880669b22f154d2ae89be6de

            As for other providers we also have a link to setup PTR on hetzner at https://docs.cloudron.io/email/#ptr-record

            @nebulon I don't have a Hetzner Cloud server (I have dedicated) so I hadn't looked at

            https://docs.hetzner.com/cloud/servers/cloud-server-rdns/ as linked to there, I had only seen:

            https://docs.hetzner.com/robot/dedicated-server/ip/ip-addresses#reverse-dns

            Which wasn't very informative.

            I had tried this:

            Screenshot from 2025-01-14 12-45-06.png

            Which hadn't worked, but looking at https://docs.hetzner.com/cloud/servers/cloud-server-rdns/ gave me the clue that I should remove the /64 bit and now it seems to have worked! Phew! I just once that has propagated I'll hopefully be able to send emails again...

            jdaviescoatesJ Offline
            jdaviescoatesJ Offline
            jdaviescoates
            wrote on last edited by jdaviescoates
            #45

            @humptydumpty I've got a dedicated server with Hetzner and having /64 at the end didn't work for me:

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

            I had tried this:

            Screenshot from 2025-01-14 12-45-06.png

            Which hadn't worked, but looking at https://docs.hetzner.com/cloud/servers/cloud-server-rdns/ gave me the clue that I should remove the /64 bit and now it seems to have worked!

            I use Cloudron with Gandi & Hetzner

            humptydumptyH 1 Reply Last reply
            0
            • jdaviescoatesJ jdaviescoates

              @humptydumpty I've got a dedicated server with Hetzner and having /64 at the end didn't work for me:

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

              I had tried this:

              Screenshot from 2025-01-14 12-45-06.png

              Which hadn't worked, but looking at https://docs.hetzner.com/cloud/servers/cloud-server-rdns/ gave me the clue that I should remove the /64 bit and now it seems to have worked!

              humptydumptyH Offline
              humptydumptyH Offline
              humptydumpty
              wrote on last edited by
              #46

              @jdaviescoates Does it fail the reverse lookup or Hetzner doesn't save the entry?

              jdaviescoatesJ 1 Reply Last reply
              0
              • humptydumptyH humptydumpty

                @jdaviescoates Does it fail the reverse lookup or Hetzner doesn't save the entry?

                jdaviescoatesJ Offline
                jdaviescoatesJ Offline
                jdaviescoates
                wrote on last edited by
                #47

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

                Hetzner doesn't save the entry?

                This. Hetzner just says it's invalid.

                I use Cloudron with Gandi & Hetzner

                1 Reply Last reply
                0
                • girishG girish

                  To summarize the situation:

                  • starting 8.2, it seems the mail server has started to prefer using IPv6 for gmail. This wasn't a change in Cloudron consciously at least. I have looked into the Haraka changes and cannot find anything specific there either. I do see that gmail has IPv6 mail servers now, not sure if they were there before or not.

                  • To fix the situation, you simply have to set IPv6 PTR record . Cloudron has not implemented a IPv6 PTR check in 8.2 but a check is implemented for next release. The PTR record is set in the VPS provider. Usually, IPv6 is allocated a block of addresses and not a single address like IPv4.

                  • If you run curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip, this will give you the specific IPv6 address that Cloudron is using to connect to gmail. You have to set the PTR for this specific IPv6 address.

                  • If your VPS provider does not allow you to set IPv6 PTR , then just disable IPv6 in the interfaces. sysctl -w net.ipv6.conf.ens18.disable_ipv6=1 for example . You have to put net.ipv6.conf.ens18.disable_ipv6=1 in your /etc/sysctl.conf for this to persist reboots. After you do this, also disable IPv6 in Cloudron, Network -> IPv6 -> Disable.

                  avatar1024A Offline
                  avatar1024A Offline
                  avatar1024
                  wrote on last edited by
                  #48

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

                  If your VPS provider does not allow you to set IPv6 PTR , then just disable IPv6 in the interfaces. sysctl -w net.ipv6.conf.ens18.disable_ipv6=1 for example . You have to put net.ipv6.conf.ens18.disable_ipv6=1 in your /etc/sysctl.conf for this to persist reboots. After you do this, also disable IPv6 in Cloudron, Network -> IPv6 -> Disable.

                  Hi @girish,

                  IPv6 keeps coming back on on my servers network interface (it's not activated on Cloudron). Every so often curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip keeps returning the IPv6 address and I get the Gmail errors again. I have done both: sysctl -w net.ipv6.conf.ens18.disable_ipv6=1 and put net.ipv6.conf.ens18.disable_ipv6=1 in /etc/sysctl.conf (replacing ens18 by eth0 which does disable IPv6 for that interface...but then after a while it comes back on).

                  Any idea?

                  1 Reply Last reply
                  0
                  • J Online
                    J Online
                    joseph
                    Staff
                    wrote on last edited by
                    #49

                    @avatar1024 I would check if ens18 is actually your interface ? ip addr

                    1 Reply Last reply
                    0
                    • avatar1024A Offline
                      avatar1024A Offline
                      avatar1024
                      wrote on last edited by avatar1024
                      #50

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

                      @avatar1024 I would check if ens18 is actually your interface ? ip addr

                      sysctl -w net.ipv6.conf.ens18.disable_ipv6=1 returns
                      sysctl: cannot stat /proc/sys/net/ipv6/conf/ens18/disable_ipv6: No such file or directory

                      whereas

                      sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 returns
                      net.ipv6.conf.eth0.disable_ipv6 = 1

                      and subsequently

                      curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip returns as expected
                      curl: (7) Failed to connect to ipv6.api.cloudron.io port 443 after 1 ms: Couldn't connect to server, instead of the IPv6 address which shows IPv6 is deactivated.

                      So I'm pretty sure eth0 is the correct one (also, when active, the IPv6 address is displayed for that interface via ifconfig).

                      And it all works fine temporarily, it just doesn't stays that way, even after adding net.ipv6.conf.eth0.disable_ipv6=1 at the bottom of the /etc/sysctl.conf file.

                      1 Reply Last reply
                      1
                      • avatar1024A Offline
                        avatar1024A Offline
                        avatar1024
                        wrote on last edited by avatar1024
                        #51

                        Right so, after adding to /etc/sysctl.conf:

                        net.ipv6.conf.all.disable_ipv6 = 1
                        net.ipv6.conf.default.disable_ipv6 = 1
                        net.ipv6.conf.lo.disable_ipv6 = 1
                        net.ipv6.conf.eth0.disable_ipv6 = 1
                        

                        on reboot, cat /proc/sys/net/ipv6/conf/all/disable_ipv6 return 1 so one would think it's all good, but it isn't. curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip still retunrs the IPv6 address and I can still see it in ifconfig for the network interface. Yet manually running either sysctl -p or sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 post boot works just fine to disable IPv6. So there is something at boot time that prevents disabling IPv6.

                        I therefore went the bulletproof way and disabled ipv6 as a boot argument in grub (GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"). But then I got of errors at boot time when services start, especially for nginx so that;s not working either.

                        Any idea?

                        J 1 Reply Last reply
                        1
                        • avatar1024A avatar1024

                          Right so, after adding to /etc/sysctl.conf:

                          net.ipv6.conf.all.disable_ipv6 = 1
                          net.ipv6.conf.default.disable_ipv6 = 1
                          net.ipv6.conf.lo.disable_ipv6 = 1
                          net.ipv6.conf.eth0.disable_ipv6 = 1
                          

                          on reboot, cat /proc/sys/net/ipv6/conf/all/disable_ipv6 return 1 so one would think it's all good, but it isn't. curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip still retunrs the IPv6 address and I can still see it in ifconfig for the network interface. Yet manually running either sysctl -p or sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 post boot works just fine to disable IPv6. So there is something at boot time that prevents disabling IPv6.

                          I therefore went the bulletproof way and disabled ipv6 as a boot argument in grub (GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"). But then I got of errors at boot time when services start, especially for nginx so that;s not working either.

                          Any idea?

                          J Online
                          J Online
                          joseph
                          Staff
                          wrote on last edited by
                          #52

                          @avatar1024 usually, if that happens it's because something else is enabling ipv6 on the interface. Do you use netplan? If so, I could chek /etc/netplan/50-cloud-init.yaml . Does it have some statically assigned ipv6 block?

                          avatar1024A 1 Reply Last reply
                          3
                          • J joseph

                            @avatar1024 usually, if that happens it's because something else is enabling ipv6 on the interface. Do you use netplan? If so, I could chek /etc/netplan/50-cloud-init.yaml . Does it have some statically assigned ipv6 block?

                            avatar1024A Offline
                            avatar1024A Offline
                            avatar1024
                            wrote on last edited by avatar1024
                            #53

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

                            Do you use netplan? If so, I could chek /etc/netplan/50-cloud-init.yaml . Does it have some statically assigned ipv6 block?

                            I was not aware I did use netplan (I don;t even really know what it is), but yes there is this config file and it seems to contain static IPs, see:

                            network:
                              version: 2
                              ethernets:
                                eth0:
                                  match:
                                    macaddress: "xx:xx:xx:xx:xx:xx"
                                  addresses:
                                  - "152.xx.xx.43/22"
                                  - "2a03:4000:xx:xx:xxxx:xxxx:xxxx:6007/64"
                                  nameservers:
                                    addresses:
                                    - 46.38.225.230
                                    - 46.38.252.230
                                    - 2a03:4000:0:1::e1e6
                                  routes:
                                  - to: "default"
                                    via: "152.xx.xx.1"
                                  - on-link: true
                                    to: "default"
                                    via: "fe80::1"
                            

                            If you tell me how i should modify the file then I'll try it out.

                            Thanks a lot for your help.

                            J 1 Reply Last reply
                            2
                            • avatar1024A avatar1024

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

                              Do you use netplan? If so, I could chek /etc/netplan/50-cloud-init.yaml . Does it have some statically assigned ipv6 block?

                              I was not aware I did use netplan (I don;t even really know what it is), but yes there is this config file and it seems to contain static IPs, see:

                              network:
                                version: 2
                                ethernets:
                                  eth0:
                                    match:
                                      macaddress: "xx:xx:xx:xx:xx:xx"
                                    addresses:
                                    - "152.xx.xx.43/22"
                                    - "2a03:4000:xx:xx:xxxx:xxxx:xxxx:6007/64"
                                    nameservers:
                                      addresses:
                                      - 46.38.225.230
                                      - 46.38.252.230
                                      - 2a03:4000:0:1::e1e6
                                    routes:
                                    - to: "default"
                                      via: "152.xx.xx.1"
                                    - on-link: true
                                      to: "default"
                                      via: "fe80::1"
                              

                              If you tell me how i should modify the file then I'll try it out.

                              Thanks a lot for your help.

                              J Online
                              J Online
                              joseph
                              Staff
                              wrote on last edited by
                              #54

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

                                - "2a03:4000:xx:xx:xxxx:xxxx:xxxx:6007/64"
                              

                              yup, this is the culprit. The IPv6 address is statically assigned here. You have to put a # in front of the line to comment it out and reboot the machine.

                              avatar1024A 1 Reply Last reply
                              2
                              • J joseph

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

                                  - "2a03:4000:xx:xx:xxxx:xxxx:xxxx:6007/64"
                                

                                yup, this is the culprit. The IPv6 address is statically assigned here. You have to put a # in front of the line to comment it out and reboot the machine.

                                avatar1024A Offline
                                avatar1024A Offline
                                avatar1024
                                wrote on last edited by
                                #55

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

                                yup, this is the culprit. The IPv6 address is statically assigned here. You have to put a # in front of the line to comment it out and reboot the machine.

                                THANK YOU! That worked.

                                Seems like netplan is here by default since Ubuntu 18: https://pscl4rke.wordpress.com/2019/10/01/disabling-ipv6-on-ubuntu-18-04-the-netplan-version/

                                1 Reply Last reply
                                1
                                • J Online
                                  J Online
                                  joseph
                                  Staff
                                  wrote on last edited by
                                  #56

                                  @avatar1024 I found this https://github.com/canonical/netplan/blob/main/doc/netplan-tutorial.md#editing-netplan-yaml-files-to-disable-ipv6 . Can't figure where this page is "published" . The yaml ref is at https://netplan.readthedocs.io/en/latest/netplan-yaml/

                                  1 Reply Last reply
                                  2
                                  • potemkin_aiP Offline
                                    potemkin_aiP Offline
                                    potemkin_ai
                                    wrote on last edited by
                                    #57

                                    Just for the reference: netplan try is usually a better way, as it might save from end up getting locked out from the server. I also usually run a background cron task, that removes those temporary files from /etc/netplan, when messing with the network.

                                    1 Reply Last reply
                                    2
                                    • P Offline
                                      P Offline
                                      privsec
                                      wrote on last edited by
                                      #58

                                      Ok, its not working again (or maybe it never did.

                                      These are my screens

                                      image.png

                                      image.png

                                      image.png

                                      image.png
                                      From my understadning, it is set up correctly.

                                      jdaviescoatesJ 1 Reply Last reply
                                      0
                                      • P privsec

                                        Ok, its not working again (or maybe it never did.

                                        These are my screens

                                        image.png

                                        image.png

                                        image.png

                                        image.png
                                        From my understadning, it is set up correctly.

                                        jdaviescoatesJ Offline
                                        jdaviescoatesJ Offline
                                        jdaviescoates
                                        wrote on last edited by
                                        #59

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

                                        its not working again

                                        What exactly isn't working?

                                        Have you set up the ipv6 reverse dns/ PTR /rDNS record too?

                                        I use Cloudron with Gandi & Hetzner

                                        avatar1024A 1 Reply Last reply
                                        1
                                        • jdaviescoatesJ jdaviescoates

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

                                          its not working again

                                          What exactly isn't working?

                                          Have you set up the ipv6 reverse dns/ PTR /rDNS record too?

                                          avatar1024A Offline
                                          avatar1024A Offline
                                          avatar1024
                                          wrote on last edited by
                                          #60

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

                                          What exactly isn't working?

                                          I imagine they are getting bounce to Gmail.

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

                                          Have you set up the ipv6 reverse dns/ PTR /rDNS record too?

                                          Looks like they have looking at screenshot 2....but possibly badly. I think it should say my.businessdoctorut.com

                                          Though for me, after setting it all up properly I kept getting issues and random bounces with the same error message. Only completely disabling IPv6 from the network interface works (and even that turned out to be a struggle 😰)

                                          P 1 Reply Last reply
                                          1
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

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