Basic setup of Proxmox in an OVH environment (Kimsufi example) with NAT and IPv6 enabled containers

Maounique · June 2023

@ebony said:

@qeba said:

@ebony said: working now thanks

currently facing the same issues, how does you solve this? im able to ping to gateway IP but not working ping to google with IPv6.

i had to always tracert ipv6.google.com to get it to fire on the VM a few hours later it would die unless u keep a ping6 open i had very bad ping6 on the server support fixed the ::1 address but would not fix anything else on the ipv6 orded a new server lower price less ram but that server just worked fine no problems at all run my minecraft server on a ipv6 and works great!

That looks like the wrong bridging, i.e. you bridged to vmbr0 or the wrong gateway. It is likely you paid more attention in the new server.

@lala_th said: How to create multiple VMs running webserver on ports 80/443 while using this NAT setup?

If you mean over IPv4, you can't, just create on other ports and use something to redirect, such as Cloudflare. On IPv6, no problems.

miguelzabala · July 2023

I have the same problem, I can ping to the IPv6 gateway on the host (xxxx:xxxx::1) from the VM. I can ping from the host to the VM (xxxx:xxxx:100). I can ping from host to google.con using ipv6. But the container can't ping to google.com using ipv6. I double checked ndppd config and running, the bridge on container, the ipv6 addresses and gateways. I have not clue what to do.

Maounique · July 2023

post configs here, I will take a look. Check if you enabled ipv6 forwarding first.

Bertie · August 2023

Thanks for this guide. I was able to finally get IPv6 finally properly up and running thanks to you.

I know this is mentioned in the troubleshooting. When IPv4 port 80/443 is forwarded to a VM, all containers are no longer able to browse. Connections to github, docker, etc. time out. Ping and nslookup both still work.

Unlike the troubleshooting, I wasn't able to get it consistently working after restarting the VM. I can curl google.com afterwards (sometimes), but curl to github.com and registry-1.docker.io both time out always, no matter how many times I restart the host or VM. At least my port 80/443 web servers are accessible.

I am using the proxmox 7 template from OVH and have already tried reinstalling proxmox 7 to get it working.

config (with anonymized IP):

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 198.27.64.100/24
        gateway 198.27.64.254
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        hwaddress 2A:B1:8F:04:7C:D9

iface vmbr0 inet6 static
    address 2607:5300:dead:beef::ffff/128
    post-up sleep 5; /sbin/ip -6 route add  2607:5300:dead:beff:ff:ff:ff:ff dev vmbr0
    post-up sleep 5; /sbin/ip -6 route add default via 2607:5300:dead:beff:ff:ff:ff:ff
    pre-down /sbin/ip -6 route del default via 2607:5300:dead:beff:ff:ff:ff:ff
    pre-down /sbin/ip -6 route del 2607:5300:dead:beff:ff:ff:ff:ff dev vmbr0

auto vmbr6
iface vmbr6 inet static
    address 10.0.0.254/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
    post-up iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.3
    post-up iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.0.0.3
    post-down iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
    post-down iptables -t nat -D PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.3
    post-down iptables -t nat -D PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.0.0.3

iface vmbr6 inet6 static
    address 2607:5300:dead:beef::1/64

This is a bit of a shot in the dark - I don't think anyone really knows what's causing this.

I'm happy just only using IPv6 at this point; since I finally managed to get that working thanks to you and I can just use IPv6 reverse proxy from Cloudflare. Alternatively, I can just defy best practice and setup the reverse proxy on the hypervisor itself.

Maounique · August 2023

I know what is causing it. The interface is not specified and the system gets confused.

Change this:

@Bertie said: post-up iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.3
post-up iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.0.0.3

Into this:

post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.3
post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to-destination 10.0.0.3

And the subsequent post-down stanzas.

Sorry for being lazy, I will have to update the guide as many people have complex setups with multiple bridges etc. So far That issue only appeared for those but it looks like 2 bridges can also be enough to confuse the system.

Bertie · August 2023

@Maounique said: Sorry for being lazy, I will have to update the guide as many people have complex setups with multiple bridges etc. So far That issue only appeared for those but it looks like 2 bridges can also be enough to confuse the system.

Thanks, that worked, and definitely don't think you're lazy, you got me way further than I would've on my own and I'm very appreciative. I don't think anyone else came up with a viable tutorial on dealing with the quirks of Kimsufi's IPv6 routing.

optisoft · December 2024

Hello
I move from a OVH server with proxmox ( SYS on VH ) to other on BHS ( Kimsufi ) .
I have a lot of problems with ipv6 (ndppd and trying to work with more than 1 ip.
How is working for u ?

optisoft · December 2024

@miguelzabala said:
I have the same problem, I can ping to the IPv6 gateway on the host (xxxx:xxxx::1) from the VM. I can ping from the host to the VM (xxxx:xxxx:100). I can ping from host to google.con using ipv6. But the container can't ping to google.com using ipv6. I double checked ndppd config and running, the bridge on container, the ipv6 addresses and gateways. I have not clue what to do.

Same here, some idea ?

x5servers · April 2025

Thank you for this tutorial, it has been a great help.

Maounique · July 2025

@optisoft said:
Hello
I move from a OVH server with proxmox ( SYS on VH ) to other on BHS ( Kimsufi ) .
I have a lot of problems with ipv6 (ndppd and trying to work with more than 1 ip.
How is working for u ?

I would need more than that to even begin to guess. At this time I am setting up another kimsufi using this exact tutorial to see if anything changed. My old ones still chugging along without issues on either IPv6 of 4.

JerryHou · October 2025

@miguelzabala said:
I have the same problem, I can ping to the IPv6 gateway on the host (xxxx:xxxx::1) from the VM. I can ping from the host to the VM (xxxx:xxxx:100). I can ping from host to google.con using ipv6. But the container can't ping to google.com using ipv6. I double checked ndppd config and running, the bridge on container, the ipv6 addresses and gateways. I have not clue what to do.

@optisoft said:

@miguelzabala said:
I have the same problem, I can ping to the IPv6 gateway on the host (xxxx:xxxx::1) from the VM. I can ping from the host to the VM (xxxx:xxxx:100). I can ping from host to google.con using ipv6. But the container can't ping to google.com using ipv6. I double checked ndppd config and running, the bridge on container, the ipv6 addresses and gateways. I have not clue what to do.

Same here, some idea ?

I just googled this post, exact same thing for me, any luck to fix it?

My current status:

Host: PVE 9, ipv4 working, ipv6 working

Vm: debian 13, Ipv4 working
Ipv6: inside VM, can ping gateway (:1), can ping host (:ffff), cannot ping google (either by domain or ipv6 address). On host, can see VM(:1001) with ip neigh, but 1001 no "reachable" comment.

Currently on mobile, I can post more config later.

tux · October 2025

I can't get IPv6 inside lxc container working, so I might have same problem.

JerryHou · October 2025

@tux said:
I can't get IPv6 inside lxc container working, so I might have same problem.

I tried ndppd and ndpresponder, still in vain...guess OVH now has changed the way how ipv6 works...

I will give up on this try for now...

tunatech · October 2025

This webpage is sufficient to solve the problem.

https://medium.com/@nanda.adiyatma2/setting-up-kimsufi-ks-le-with-proxmox-ve-6-7d9beb43b46a

darius25 · October 2025

Thanks for the guide. Would this also work on Hetzner dedis?

Maounique · October 2025

@JerryHou said: guess OVH now has changed the way how ipv6 works

I don't think they can do that. Their router sees only the one IPv6 that does the routing for us, i.e. all connections are coming from one IPv6.
Moreover, my setup still works, even on a KS-1, the old atom version without virtualization, just containers, so it is definitely not an OVH change.
The next step in the investigation is what changed in proxmox since the tutorial has been written (I believe it was proxmox 7) and the networking stack.
Well, many things did change, but this change is not so easy to guess, just check if forwarding is, indeed, enabled and you would have your answer.
Debian 13 (which is the basis for Proxmox) changed the location of the sysctl.conf files, you need to move your config, or create another, with the forwarding only in /etc/sysctl.d and reloading the config with the new stanza: systemctl restart systemd-sysctl

OR, even better:

Add to the /etc/network/interfaces a line like this (where you bring up the bridge with the IPv6 where you bridge the container/VMs):

post-up sysctl net.ipv6.conf.all.forwarding=1

to read like this:


auto vmbr6
iface vmbr6 inet static
    address 10.0.0.254/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up sysctl net.ipv6.conf.all.forwarding=1
    post-up iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE

I could have done this in the original tutorial but wanted to show people where are the variables which are governing the forwarding.

Conclusion:
A change in Debian 13 location of config files broke the setting we require, enable IPv6 forwarding, the IPv4 one was set when we were bringing up the bridge so it was working, but the IPv6 setting we did in the sysctl.conf file. Debian 13 rendered our file at the old location useless, so it is better to bring forwarding on for both ipv4 and ipv6 at the same time we are bringing up the bridge that will handle the actual routing inside the Proxmox server.

P.S. Apologies for being verbose, I went to this length to give an idea on how to investigate an issue logically, i.e. check that forwarding is enabled, then, when seeing it is not, think what was the context in which this worked, what changed in subsequent versions of Proxmox and how best to fix it in order to avoid similar problems when Debian would decide to change the location of some files.
That being said, nothing is "future-proof", everything can change for any kind of real or imaginary reasons, we need to think it through and investigate the issue.

Maounique · October 2025

@darius25 said:
Thanks for the guide. Would this also work on Hetzner dedis?

AFAIK Hetzner doesn't have limitations regarding how many IPv6 you can use on your server, so you can simply bridge to the main bridge, the one with your routable IPv4, usually vmbr0, and IPv6 would work for as long as it is from within your allocation. If you would like to have IPv4 through NAT as well (i.e. NOT extra routable IPv4 you have rented from Hetzner, just route through the one assigned to the server) then you can use this setup, but it is not required due to internal Hetzner networking like it is in the case of OVH.

JerryHou · October 2025

@Maounique said:

@JerryHou said: guess OVH now has changed the way how ipv6 works

I don't think they can do that. Their router sees only the one IPv6 that does the routing for us, i.e. all connections are coming from one IPv6.
Moreover, my setup still works, even on a KS-1, the old atom version without virtualization, just containers, so it is definitely not an OVH change.
The next step in the investigation is what changed in proxmox since the tutorial has been written (I believe it was proxmox 7) and the networking stack.
Well, many things did change, but this change is not so easy to guess, just check if forwarding is, indeed, enabled and you would have your answer.
Debian 13 (which is the basis for Proxmox) changed the location of the sysctl.conf files, you need to move your config, or create another, with the forwarding only in /etc/sysctl.d and reloading the config with the new stanza: systemctl restart systemd-sysctl

OR, even better:

Add to the /etc/network/interfaces a line like this (where you bring up the bridge with the IPv6 where you bridge the container/VMs):

post-up sysctl net.ipv6.conf.all.forwarding=1

to read like this:


> auto vmbr6
> iface vmbr6 inet static
>     address 10.0.0.254/24
>     bridge-ports none
>     bridge-stp off
>     bridge-fd 0
>     post-up echo 1 > /proc/sys/net/ipv4/ip_forward
>     post-up sysctl net.ipv6.conf.all.forwarding=1
>     post-up iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
>     post-down iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
>

I could have done this in the original tutorial but wanted to show people where are the variables which are governing the forwarding.

Conclusion:
A change in Debian 13 location of config files broke the setting we require, enable IPv6 forwarding, the IPv4 one was set when we were bringing up the bridge so it was working, but the IPv6 setting we did in the sysctl.conf file. Debian 13 rendered our file at the old location useless, so it is better to bring forwarding on for both ipv4 and ipv6 at the same time we are bringing up the bridge that will handle the actual routing inside the Proxmox server.

P.S. Apologies for being verbose, I went to this length to give an idea on how to investigate an issue logically, i.e. check that forwarding is enabled, then, when seeing it is not, think what was the context in which this worked, what changed in subsequent versions of Proxmox and how best to fix it in order to avoid similar problems when Debian would decide to change the location of some files.
That being said, nothing is "future-proof", everything can change for any kind of real or imaginary reasons, we need to think it through and investigate the issue.

Thanks for the detailed explanation. I will give it a try after re-installing and re-setup my PVE9. In last weekend, somehow I messed it up on both IPv4 and IPv6 while I was exploring something else, I could not connect to the server at all. Since nothing was important on that server, I just did a re-install to start fresh.

I will try your method again. Thanks very much. I will post an update here if I got issues.

fan · November 2025

I was struggling with PVE9 ipv6 ndp proxying with new KS boxes as well, with all sorts of forwarding (ipv4/ipv6/ndp) enabled, ipv6 still does not work inside containers.

After trial and error, I found one command that can grant containers ipv6 access:

ip -6 neigh add proxy [ipv6 address] dev vmbr0

Still finding a way to make this automatic though.

Maounique · November 2025

@fan said: ipv6 still does not work inside containers

I tested and the method described here still works. I have a cluster of various proxmox nodes in OVH EU and I upgraded it to 9. I will also try a fresh install, maybe other issues could appear.

JerryHou · November 2025

@fan said:
I was struggling with PVE9 ipv6 ndp proxying with new KS boxes as well, with all sorts of forwarding (ipv4/ipv6/ndp) enabled, ipv6 still does not work inside containers.

After trial and error, I found one command that can grant containers ipv6 access:
ip -6 neigh add proxy [ipv6 address] dev vmbr0
Still finding a way to make this automatic though.

I was poking around and tried this based on a GPT answer (yes, I am dumb on network stuffs and have to use GPT... :P), it was not working for me though...

Can you elaborate a little more when and where in the original guide I should input this....

Thanks a lot...

fan · November 2025

@Maounique said: other issues

Found one, your method actually works, without the need to manual command I posted above: I'm using the official debian 13 template to create the container, and once it started, direct ping any ipv6 address does not work, but if I install mtr and run mtr to any ipv6 address, it gained ipv6 access immediately.

fan · November 2025

@JerryHou said: Can you elaborate a little more when and where in the original guide I should input this....

You can try @Maounique method, and if it's not pinging ipv6 address, try mtr that address first, don't know why but this trick works for me.

JerryHou · November 2025

@fan said:

@Maounique said: other issues

Found one, your method actually works, without the need to manual command I posted above: I'm using the official debian 13 template to create the container, and once it started, direct ping any ipv6 address does not work, but if I install mtr and run mtr to any ipv6 address, it gained ipv6 access immediately.

wait...I searched online, from debian wiki, mtr is a traceroute and ping tool, it does not provide any connectivity function? And somehow it gives the container ipv6 after a traceroute? That's...interesting...

fan · November 2025

@JerryHou said: somehow it gives the container ipv6 after a traceroute

Here's ChatGPT's answer:

Why mtr “unblocks” IPv6
mtr/traceroute sends packets with incrementing hop-limit (TTL), eliciting ICMPv6 Time Exceeded replies from each hop, which creates inbound traffic toward the container address right away.

With an on-link /64 and NDP proxy, the upstream only performs Neighbor Discovery for a destination when it actually has a packet to deliver; before that, it has no L2 mapping for your container’s IPv6 and can’t return the ping replies, so the first outbound pings appear to fail.

Once mtr generates those inbound ICMPv6 replies, the upstream issues Neighbor Solicitations, ndppd answers with proxy Neighbor Advertisements, and a reachable neighbor entry is installed until it ages out per NDP timers, after which the cycle repeats if no traffic refreshed it.

JerryHou · November 2025

@fan said:

@JerryHou said: somehow it gives the container ipv6 after a traceroute

Here's ChatGPT's answer:

Why mtr “unblocks” IPv6
mtr/traceroute sends packets with incrementing hop-limit (TTL), eliciting ICMPv6 Time Exceeded replies from each hop, which creates inbound traffic toward the container address right away.

With an on-link /64 and NDP proxy, the upstream only performs Neighbor Discovery for a destination when it actually has a packet to deliver; before that, it has no L2 mapping for your container’s IPv6 and can’t return the ping replies, so the first outbound pings appear to fail.

Once mtr generates those inbound ICMPv6 replies, the upstream issues Neighbor Solicitations, ndppd answers with proxy Neighbor Advertisements, and a reachable neighbor entry is installed until it ages out per NDP timers, after which the cycle repeats if no traffic refreshed it.

this is some next-level stuff, so it's like mtr wakes up the node ipv6 and since then it's ok.... do I need to do this every time I reboot the host or not...

blorged · November 2025

The “correct” solution is to install ndppd.

blanehol · November 2025

Is there any idea how ipv6 ovh could work in vmware esxi?

Maounique · November 2025

@fan said: don't know why but this trick works for me.

It works because of how the OVH routers are configured.
I have explained it elsewhere, but it needs a more clear explanation.

You see, OVH "advertises" one IPv6 per server and offers that in the provisioning email, an /128.
Because of how IPv6 works and for some practical considerations, they are actually forced to allocate a full /64 and route it through a /56.
In order to keep you from using the whole /64 (not actually use it, nobody can use that many, but to make it usable, i.e. you could use more than one IPv6 at a time) they setup their routers to only allow one entry for your MAC.
You have an IP allocated per your mac, but if you use another, then the router deletes the old and uses the new one instead. If another IPv6 starts having traffic, then the router will delete the previous and use the new one. Doing mtr forces the router to allow the new IPv6, but then the old one will no longer work until it has some traffic, the other one is deleted and so on.

The solution is to route ALL traffic through ONE IPv6, just like you do with the IPv4 through NAT.
Since IPv6 NAT, while it exists, would negate some of the advantages of IPv6, among which the biggest is eliminating the firewalling and making it sit directly on the internet making port forwarding and the like redundant and making multiple ports of the same kind, i.e. 80, available for multiple servers, then we wouldn't be using IPv6 NAT, but direct routing since the IPv6s are directly routable. We just need to mask that traffic behind only one IPv6, unloading the routing from the OVH routers towards our own routing inside Proxmox. There are more ways to do this, I would take the time to consider whether I would be including alternatives in an already long tutorial or stick with ndppd.

I hope now it is more clear.

Maounique · November 2025

@blanehol said: Is there any idea how ipv6 ovh could work in vmware esxi?

I would be making a router VM for IPv6 in that case. Messing with proxmox is one thing, with esxi that would be a whole different ball game.

Howdy, Stranger!

Categories

In this Discussion

Basic setup of Proxmox in an OVH environment (Kimsufi example) with NAT and IPv6 enabled containers

Comments

OR, even better:

OR, even better:

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Basic setup of Proxmox in an OVH environment (Kimsufi example) with NAT and IPv6 enabled containers

Comments

OR, even better:

OR, even better: