Can't Get ipv6 Working (reliably) On Contabo VPS Freebsd 13.1

Yes, of course. I've got blackbox exporter running and it measures pings every few seconds. Everything worked with the 14.2 kernel fine. Since upgrade to 14.3 ip6 pings and the entire ip6 traffic to my server and jails stopped to work entirely. Packets don't even arrive at em0.

I didn't make any changes in pf.conf. There is still the rule that allows icmp and one that allows icmp6.

I also tried to reboot to make sure it's not a temporary problem.

It looks like an NDP problem, because I can at least see NDP in my subnet, but no other traffic.
I see the same thing on a FreeBSD 14.0 VPS..ndp only shows my address and the gateway address(static_ndp_pairs) and nothing else.
 
I am currently running my FreeBSD mail server and web server on a Contabo VPS located in Dusseldorf. Services are running in jails with IPv4 and IPv6 without any problems. Since my previous post above I removed:
Code:
rtsold_enable="YES"
rtsold_flags="-Fa"
from /etc/rc.conf.
But it's another VPS instance since my previous post. This new VPS is running since December 2024.
It's currently FreeBSD 14.2-RELEASE but I will switch to 14.3-RELEASE soon.
Upgrade to 14.3-RELEASE done.
All is working flawlessly, host and jails with IPv4 and IPv6.
 
Contabo VPS follow-up:
They migrate my VPS from Dusseldorf to Hub-Europe. I discovered that because my FreeBSD server had a reboot.
IPv6 /64 doesn't work anymore. Only one IPv6 is working so it seems I haven't /64 anymore. It's like a /128.
I contacted the support but got any relevant reply about this. So I will change my VPS provider.
 
I simply deleted all my AAAA entries. IPv6 with this kind of routing has never been supported.
Okay but I am running a mail server and this is difficult without an IPv4 /24 range. You can be blacklisted if another in this range is a spammer.
Do you know if another OS (Linux/Debian for example) can handle IPv6 /64 on this VPS ? I need more than one IPv6.
 
I use Spamhaus for blacklisting and it blocks single IPs. Every hosting service might have the same problem.

I haven't tested it, but the support always points me to their emergency boot that is Linux based. I guess it's the IPv6 implementation in FreeBSD. Maybe I need to use Debian there.
 
I guess the missing parts are somewhere in NDP. Because packets are not arriving at all. It's like the router behind fe80::1 decides it won't forward packets.

Just a guess. But it definitely got worse after 14.3.
 
After analyze with tcpdump(1) and net/wireshark of three OS's behavior with ICMPv6 Neighbor Discovery Protocol, I found why it doesn't work with FreeBSD whereas it works with Debian/Linux and OmniOS.
OmniOS and Debian are responding to Neighbor Solicitation with the target address found in the message. It can be Link-Local Unicast address or Global Unicast address.
FreeBSD does not. It always respond with the Link-Local Unicast address which the sender of the Neighbor Solicitation message discard because it resend this one forever.

2025-08-28-165756_1461x450_scrot.png
 
After analyze with tcpdump(1) and net/wireshark of three OS's behavior with ICMPv6 Neighbor Discovery Protocol, I found why it doesn't work with FreeBSD whereas it works with Debian/Linux and OmniOS.
OmniOS and Debian are responding to Neighbor Solicitation with the target address found in the message. It can be Link-Local Unicast address or Global Unicast address.
FreeBSD does not. It always respond with the Link-Local Unicast address which the sender of the Neighbor Solicitation message discard because it resend this one forever.

View attachment 23474
Could you try setting net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 and re-test ?
 
Back
Top