Category Archives: VM

VMware ESXi on’s dedicated server, additional IPv4 subnet, and native IPv6 connectivity

I have finally migrated my server from LeaseWeb to OVH.  LeaseWeb wouldn’t provide me with a reasonable offer after being a loyal customer for 3 years so I terminated my server there. I came across OVH’s 1-year anniversary for Asia Pacific servers (50% off for annual payment) and their offer was massively appealing so I immediately signed up. I am extremely impressed with their customer control panel. I would say it’s much better than SoftLayer and LeaseWeb if you like to configure things by yourself.  OVH may not have a perfect reputation but it seems to have improved significantly over the years. I’m quite pleased on their automatic provisioning that took minutes and the KVM-over-IP is very easy to use.

It took me a while to get up to speed but once I got a hold of it, things were quite straightforward.  I intend to run a VM-based router (MikroTik’s Cloud Hosted Router) and route the subnet through it and other VMs will be a part of this VM network.  I could “bridge” my VMware ESXi CHR VM to the physical network to take advantage of their very-reasonably-priced one-time-fee additional IPv4 blocks using a FailOver (FO) IP address.  You need 1 individual FO IP to route/”bridge” the additional IPv6 subnet(s).  Apply the OVH-generated VMware-accepted MAC address to your VM host’s virtual ethernet (in my case VMware ESXi) to get the “bridge” to work.  You will need to “bridge” every single IP to the OVH-generated MAC address in the subnet manually.

Once I got everything working as expected, I continued to configure native IPv6 as provided by OVH.  I read the available guides on and on Google (they have various guides on IPv6 make sure you read the right one for dedicated server), but I could never get it to work.  I got assigned the IPv6 range of 2402:1f00:8000:3cb::/64 but the guide states that I need to use 2402:1f00:8000:3ff:ff:ff:ff:ff as the gateway IPv6 address, which does not make sense (if you know how IPv4 and IPv6 subnets work) because such address is outside the /64 range.  2402:1f00:8000:3cb::/64 means 2402:1f00:8000:3cb:0:0:0:0 – 2402:1f00:8000:3cb:ffff:ffff:ffff:ffff.  Compare this range to the suggested gateway IPv6 address of 2402:1f00:8000:3ff:ff:ff:ff:ff (or 2402:1f00:8000:03ff:00ff:00ff:00ff:00ff), you can clearly see that the suggested IPv6 gateway address is outside the range.  This is the reason why no Operating System would take such gateway IPv6 setting.

I did not really take notice of this initially and wondered for hours why it wouldn’t work.  I opened a support ticket and the response was not helpful, the response only repeated the guide. I eventually used an IPv6 calculator to confirm my suspicion and it proved to be the culprit (because the gateway error was “unreachable” and “no route to host” when ping was used). I immediately tried changing the subnet mask to /56 instead of /64 because the assigned gateway IPv6 address is expected to be overridden with “ff” and changing it to /56 now makes the gateway IPv6 address within the network.  Remember, previously it was outside with the /64 range. Now the OS would accept the gateway IPv6 address and is reachable.  Ping also worked this time and immediately I had native IPv6 connectivity.

So, if you are an OVH customer and you cannot get IPv6 to work after following their guides, don’t worry it’s not you that is the problem, it’s OVH’s problem.  I told OVH on my support ticket to update their guides and knowledgebase to help others with similar issue but they don’t seem to get it.  I guess these tech support guys don’t really know fundamentally how IPv6 works.  Anyway, just make sure that your IPv6 configuration on the router is /56 and not /64 and native IPv6 will work as expected on your dedicated server or “bridged” VM router.  Good luck!