Kimsufi: unable to get IPv6 connectivity in guests (either ndppd or static neighbour)
Hi all,
My Kimsufi is running Proxmox with encryption and all, thanks for the help!
The past few nights I've spent trying to get IPv6 to the containers. As OVH shows my server as having a /128, I've searched for yoursunny's hall of shame, but was not able to find the list (I'm sure to have seen it a couple of times during BF/CM).
I did find @loay 's IPv6 subnet-checker. It warned me of OVH's on-link practise and suggested ndppd.
Enabling forwarding and proxying (all/vmbr0/eno1) and configuring ndppd on either the bridge (vmbr0) or the actual interface (eno1) does not have the desired effect: neighbour advertisements / neighbour sollicitations are not proxied.
I tried setting a static neighbour for two containers on eno1, seperately also on vmbr0, again with no result.
I threw the story in a chatbot, which regurgitated the same commands and told me that it should work that way.
Is there something obvious I must have missed in the context of Kimsufi OVH BHS?
Comments
Capture traffic with tcpdump and analyze with Wireshark.
You can see the NDP packets and find out what's missing.
best of "yoursunny lore" by Google AI 🤣 affbrr
Thanks!
tcpdumpshowed that NDP does not seem to get proxied. Traffic over eno1 shows packages with the IP of the guests, instead of that of of the host. So I know what is missing: proxying of NDP, but with ndppd already running, I don't know what else to add.I was notified that that a thread by Maounique (OGF) might hold some pointers.
It seems so!
Maounique described a setup with two bridges:
1. vmbr0 enslaving eno1, on a chosen IP/128 from the /64 bloc
2. vmbr64 on the ::1/128 in the OVH panel, but with /128 replaced by /64
3. ndppd proxies on vmbr0, for the subnet on vmbr64
Guests use the IP of vmbr64 as gateway; traffic forwarded with net.ipv6.conf.all.forwarding=1 in systcl (but seemingly without the need to set proxy_ndp=1)
I'll be reconfiguring following that suggestion and testing whether it gives me connectivity.
Make sure thr kernel has ndp enabled. Without doesn't matter if nppd is installed and running.
The Yeti has left the building.
That is,
isn't it? Thanks for mentioning it, as I did not notice it in the other thread. (It was in my attempts so far, so I'll keep it)
Strong boys use ndpresponder instead of ndppd.
https://lowendspirit.com/discussion/2815/ipv6-neighbor-discovery-responder-for-kvm-vps
best of "yoursunny lore" by Google AI 🤣 affbrr
Is the /128 and default route assigned to the bridge?
Can you ping out from the bridge?
Assign a static address to the bridge inside the /128 use that as the default gateway see if it works inside the container.
Also make sure ipv6 forwarding is on.
The Yeti has left the building.
Real strong boys don't use any extra sh*t but add the additional IPv6 static to the bridge
ip -6 neigh add proxyndppd works fine if properly configured.
Free NAT KVM | Free NAT LXC
Hi all, thanks a lot for your input, suggestions and patience :-)
I got it to work!
While detailing my situation for follow-up questions I dropped all configs and the results of troubleshooting in an editor with similar-selection-highlighting.
In the end it turned out I mixed up the IP of vmbr0 (outer bridge to eno1) and vmbr64 (inner bridge connected to the containers).
As a result, my containers were configured with the wrong gateway and the traffic went nowhere.
For anyone with the same problem on Kimsufi: as of december 2025 it still works with double bridges and ndppd, and Maounique's howto I abbreviated above.
Lesson learned: explaining the problem to someone to ask them a question in 90% hands the solution by itself.
Happy networking :-)
Better reply than "nvm figured it out"
Hey teamacc. You're a dick. (c) Jon Biloh, 2020.
Aiming to make the world a better place
Looks like it's time to raise the dead!
Replying on topic as I had been facing these issues and turns out most of the issues can be because the OVH/Kimsufi router is f*cked...
Lemme go back and explain. So I have 2 dedicated servers with OVH (through OneProvider as they didn't charge setup fee). On one of the servers, assigning any random IP from the IPv6 /64 range works. On the other one, it doesn't UNTIL i ping or try to access the IP from outside the network. So it's not always wrong config. It might just be that the OVH/Kimsufi router is ignoring requests and only recognizing your server's main IP.
The script I ran on my dedicated server to test things before i setup anything:
https://gist.github.com/loayai/8eb1fa456246202a4deece7780725da6
.
On the server that works with the full /64 range:
And the one that fails:
So... welcome to OVH IPv6 lotto?
I thought it was just me with this issue, no NDP responder worked on my Kimsufi (not even @yoursunny one). in the end i wrote a script that sends spoofed IPv6 packets as VM IPs which restores connectivity on the VMs for some period of time (likely until cache in NDP OVH router is purged).
You may also try running traceroute from inside the VM and see if that brings back the connectivity, i think there's a specific ICMP packet you need to send from inside to restore it.
onidel - 🇦🇺🇳🇱🇸🇬🇻🇳🇺🇸 - High Availability - Hourly Billing - API support - BGP/BYOIP - SEV-SNP
Yes, I noticed that for the dedi I was having issues as well. It only triggers WHEN the router receives a inbound packet and saves it to memory for 5 mins. Outbound packets does work as keep-alive but if no traffic, it forgets it. Like you said, the cache is probably set to purge in 300s or so.
Nope. The traffic leaves the host (goes to router) but nothing ever comes back. There is no ARP being sent out by the router to ask which MAC address has the VM's IP until the IP is accessed by an external device from outside the OVH network.
We are not the only ones. I saw a few more people have this same issue. Seems to be a issue with how the OVH configured their routers. Some works fine, some doesn't.
Since I have 2 dedicated servers, I was able to do the same on both to see the difference. I installed proxmox 9 on both at the same time. thæn I setup both at the same time with 2 different side by side terminal windows until both had EXACT same OS and setup. One worked fine. Other didn't. Only difference between the two is the "route" or "gateway" being used by the two servers. That's how I was able to identify the issue being on OVH's side. But since they already said /128 IPv6, cant even complain. People who did got no resolution either. So need to live with it.
you did setup ntppd right?
Free NAT KVM | Free NAT LXC
yep. As I said, I setup 2 servers, both with ndppd and . One of them works, one doesn't.
So i used the script to test. The script basically adds additional IPs to your dedicated server and tries to use those new IPs to communicate. It skips over all of the other issues and tries to confirm the router settings and your IPv6 range.
@oloke @Neoon I cant believe I am saying this, but complaining about it works...
I got both of the OVH Kimsufi servers through oneprovider. One of them had working /64 IPv6, while the other did not. I complained, but no action. However, last night, my server had no internet from 1 AM till 5 AM. 4 hours downtime. When the server came back online, I noticed that the server was still running but it lost the internet connectivity for the 4 hours. So i decided to run the script to check if IPv6 /64 is still not working.
To my surprise, full /64 IPv6 is now assignable and I can spin up VM/LXC containers and assign them any IPv6 IP and it works fine (through ndppd). Since it did not work as of yesterday, I think they either upgraded their router firmware or change it out during that time. Either way, I am happy now
Some good news, which location was that?
onidel - 🇦🇺🇳🇱🇸🇬🇻🇳🇺🇸 - High Availability - Hourly Billing - API support - BGP/BYOIP - SEV-SNP
Both my servers are in Singapore location. Which is why I found it specially weird that one had /128 IP while one had /64. Now both has full /64 range unblocked (still need to route through pdppd which i already had installed previously).
Baguette
Free NAT KVM | Free NAT LXC
No, this is Patrick!