All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
How to configuring Proxmox for IPv6?
My server provider provided me with the following configuration.
Subnet: 2a04:bdc7:100:XXXX::/64 (I can use the whole /64, I have tested it.)
Gateway: 2a04:bdc7:100::1
File:/etc/network/interface (The IPv4 part is not included.)
auto lo
iface lo inet6 loopback
iface eth0 inet6 manual
auto vmbr0
iface vmbr0 inet6 static
address 2a04:bdc7:100:XXXX::e030
netmask 64
gateway 2a04:bdc7:100::1
bridge_ports eth0
bridge_stp off
bridge_fd 0
File:/etc/sysctl.conf (The IPv4 part is not included.)
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.proxy_ndp = 1
net.ipv6.conf.all.proxy_ndp = 1
Proxmox CT Configure:
IPv6/CIDR: 2a04:bdc7:100:XXXX::e031/64
IPv6 Gateway: 2a04:bdc7:100:XXXX::e030
From Host:
~# traceroute -s 2a04:bdc7:100:XXXX::e030 ipv6.google.com
traceroute to ipv6.google.com (2607:f8b0:4023:c0d::8b), 30 hops max, 80 byte packets
1 2a04:bdc7:100::1 (2a04:bdc7:100::1) 0.347 ms 0.284 ms 0.286 ms
2 2604:6600:0:17::1 (2604:6600:0:17::1) 1.089 ms 1.065 ms 1.039 ms
3 2604:6600:0:8::42 (2604:6600:0:8::42) 0.349 ms 0.325 ms 0.303 ms
4 2001:4860:0:1110::14 (2001:4860:0:1110::14) 0.477 ms 2001:4860:0:110e::13 (2001:4860:0:110e::13) 0.355 ms 2001:4860:0:1110::13 (2001:4860:0:1110::13) 1.048 ms
5 2001:4860::c:4000:de40 (2001:4860::c:4000:de40) 0.941 ms * *
6 2001:4860::c:4001:bffd (2001:4860::c:4001:bffd) 7.385 ms 7.212 ms 7.149 ms
7 2001:4860::cc:4001:bfd1 (2001:4860::cc:4001:bfd1) 7.496 ms 2001:4860::cc:4001:bfd2 (2001:4860::cc:4001:bfd2) 6.989 ms 6.991 ms
8 2001:4860:0:1::4f93 (2001:4860:0:1::4f93) 7.123 ms * 2001:4860:0:1::4ea7 (2001:4860:0:1::4ea7) 6.454 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * 2607:f8b0:4023:c0d::8b (2607:f8b0:4023:c0d::8b) 6.744 ms 6.625 ms
From CT:
~# traceroute ipv6.google.com
traceroute to ipv6.google.com (2607:f8b0:4023:c0d::8b), 30 hops max, 80 byte packets
1 2a04:bdc7:100:XXXX::e030 (2a04:bdc7:100:a1::e030) 0.072 ms 0.018 ms 0.015 ms
2 * * 2a04:bdc7:100:XXXX::e030 (2a04:bdc7:100:a1::e030) 3057.505 ms !H
I don't know how else to proceed now?
Comments
Shouldn't you use 2a04:bdc7:100::1 as the gateway if you are bridging the VM with the external interface?
It looks your /64 is not routed either way. You should use bridging and configure your upstream gateway within the CT/VM, or use something like ndppd and route it onwards from there.
I also tried, but I couldn't reach it, instead I could reach 2a04:bdc7:100:XXXX::e030.
I have also configured ndppd:
Obviously, it stops when it reaches the gateway.
ndppd status:
But sometimes it is not completely unavailable, it is occasionally available, but usually not for long (less than a minute).
Could this be because I am implementing it on a VPS and this feature will not work?
Thank you for answering my questions.
What does your ndppd configuration look like? Is ip6_forward enabled in sysctl? If you traceroute some IP in your range, do you see the IP of the Proxmox host / hypervisor prior to the traceroute ending in a rain of wildcards *?
I've turned on ip6_forward:
ndppd:
what provider are you using? If contabo then
enable_ipv6
checked the address you provided and its from Hosthach @hosthatch help this dude
I can recommend this guide.. I struggled with IPv6 to, but when I started using the described routed setup, everything was fine.
https://community.hetzner.com/tutorials/install-and-configure-proxmox_ve/
Oh.. nevermind.
Hosthatch.. I think you need to configure it /48 not /64
I've also tried configuring it to /48, but it still doesn't work for NDP.
I suspect it may be a link prefix rather than a routed prefix.
My best guess is because we allow only the MAC address of the VM's network interface to use the IP addresses, both for IPv4 and IPv6.
I had a lot of trouble with ndppd.
What I've found is: when an address is assigned to the host machine, the kernel transmits Neighbor Advertisement packets from a global address, and it works everywhere; when an address is assigned to a container, ndppd transmits Neighbor Advertisement packets from a link-local address, and it works in some providers but doesn't work elsewhere.
I ended up writing my own NDP responder for solving this problem:
https://yoursunny.com/t/2021/ndpresponder/
https://www.lowendtalk.com/discussion/171123/ipv6-neighbor-discovery-responder-for-kvm-vps/p1
You don't have to guess, you're a service provider, but I see that WebHorizon deploys OVZ VPS on your KVM server, so that could be...
If ... and when BGP is supported, this restriction should be released when using my own prefix.
I have tried yoursunny docker and also a container described as magic docker, both of which did not work.
I found the problem, HostHatch provides a link prefix and not a routed prefix, only the routed prefix supports NDP, I am considering using ip6tables to make PVE work with a separate IP.
Hello, I am setting up wireguard on a Hosthatch vps and have a similar problem with you, ndppd doesn't work either. But interestingly when adding a same ip of the wireguard client to eth0 then delete it at once, my client would be able to access ipv6 internet for a while.
What’s your solution in the end, is NAT6?
@scad I actually have a NAT6 setup for Proxmox too, each LXC container gets an address on fcd9::1
Same issue with me. If your provider use SolusVM then it is likely happened.
The problem has been solved and requires Routed Prefix, the host may only provide Link Prefix.
Did you ask HostHatch to route your IPv6 prefix?
add HE tunnels, or BGP announcement IP prefix.