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

[avatar1024]

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

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

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

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

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

[avatar1024]

@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/

[joseph]

@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/

[potemkin_ai]

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.

[privsec]

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

These are my screens

From my understadning, it is set up correctly.

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

[avatar1024]

@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 )

[privsec]

@avatar1024 My mail server location is

I do keep getting bounced emails from Gmail.

[potemkin_ai]

Just in case - I've just found that IPv6 might be enabled at the NetPlan level, despite all of the sysctl and other configs.

To disable - add to the appropriate yaml file in /etc/netplan - link-local: [ ipv4 ] - on the same level as dhcp instruction. Run netplan try and netplan apply if you are lucky.

That seems to disable IPv6 on Linux.

<rant> Linux start looking more and more like Windows </rant>

[avatar1024]

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

I've just found that IPv6 might be enabled at the NetPlan level

Yep this has been discussed above in this thread...from post #52 onward. The solution provided by @joseph worked on my end. I had originally tried something along the line you mentioned (adding link-local: [ ipv4 ] to the yaml file but that didn't work...although I might have done it wrong).

[avatar1024]

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

I do keep getting bounced emails from Gmail.

In that case I would just disable IPv6 altogether from your server network interface. That's the only only thing that worked for me.

[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 another 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!

[joseph]

Cloudron uses unbound to do DNS lookups .Can you try host -t PTR <ip6> 127.0.0.150 ? 127.0.0.150 is the address where unbound listens

[Gengar]

@joseph When I have the issue ? Or when I don't ? As I already rebooted my server a few hours ago, atm I don't have the issue. But I guess it will come tomorrow or the day after.