How to setup ipv6 on Proxmox on Naranja.tech server? They only give a:b:c:d::1/64 in their panel.

stoned

Naranja.tech server, I am trying to setup ipv6, they give only a subnet like a:b:c:d::1/64 in their panel. How would I find out the gateway for it?

They don't seem to have any other documentation available.

dosai

Ticket and ask them?

nullnothere

The gateway will be a:b:c::1 (the /48).

You can do something like:

ip -6 route add a:b:c::1 dev eth0
ip -6 route add default via a:b:c::1

stoned

Oh it's the /48. I got it now. Thanks! I opened a ticket for nothing. I'll close it. Don't like to bother support people too much so I asked here first. Much appreciated. It's good now.

stoned

I've installed proxmox on the server. I've got ipv6 and gateway. I can ping6 google from within the host.

I setup lxc container
I give it another ipv6, like a:b:c:d::2/64, I set gateway as a:b:c::1

I get Destination unreachable: Address unreachable

So I installed ndppd on the host, thinking they may not be routing at their end, configured ndppd to route, created a ::2 on their panel in the subnet as another ip, gave the ::2 ip to the container with ::1 as the gateway, and I get address unreachable.

Host can ping container ipv6
The container cannot ping the host ipv6 at ::1.

Anyone have idea of how naranja.tech ipv6 routes?

Maounique

Check if forwarding is working for ipv6. Also, how did you bridge the VM? PM me your config to take a look.

stoned

auto lo
iface lo inet loopback

iface ens3 inet manual

auto vmbr0
iface vmbr0 inet static
        address 1.2.3.4/24
        gateway 1.2.3.1
        bridge-ports ens3
        bridge-stp off
        bridge-fd 0

iface vmbr0 inet6 static
        address a:b:c:d::ffff/128
        gateway a:b:c::1

        post-up sleep 5; ip -6 route add a:b:c::1 dev vmbr0
        post-up sleep 5; ip -6 route add default via a:b:c::1

        pre-down ip -6 route del default via a:b:c::1
        pre-down ip -6 route del a:b:c::1 dev vmbr0

        post-up echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
        post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
        post-up echo 1 > /proc/sys/net/ipv6/conf/default/forwarding

auto vmbr1
iface vmbr1 inet static
        address 192.168.1.0/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 192.168.1.0/24 -o vmbr0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s 192.168.1.0/24 -o vmbr0 -j MASQUERADE

iface vmbr1 inet6 static
        address a:b:c:d::1/64

vmbr0 at a:b:c:d::ffff
vmbr1 at a:b:c:d::1

Attatch containers/VMs to vmbr1, use any ipv6 in your /64, and use vmbr1's ipv6 a:b:c:d::1 as the gateway.

Then use ndppd: /etc/ndppd.conf

route-ttl 30000
proxy vmbr0 {
        router yes
        timeout 500
        ttl 30000
        rule a:b:c:d::/64    {
                static
        }
}

This in sysctl.conf

net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

And LXC container seem to have ipv4 and ipv6 now.

rsc

I know this is an old thread, which I found while looking for configuration instructions.

Unfortunately, their panel says only 2001:db8:1:132::/64 (redacted from real IPv6 prefix to IPv6 documentation space), however configuring 2001:db8:1:132::1/64 on the network interface and using 2001:db8:1::1 (first from /48 supernet) as default gateway does not work.

Other common things like fe80::1 (IPv6 link-local) or 2001:db8:1:132::1 (on-link instead of routed, yes, was using 2001:db8:1:132::2/64 then on the network interface) as IPv6 default gateway don't work either.

Does somebody still run a working IPv6 configuration with them in a virtual machine? If so, did their setup change or did they simply mess up their network configuration related to me?

@naranjatech's support unfortunately does not answer the repeated question what the IPv6 default gateway is (and they unfortunately rolled out the virtual machine initially without IPv6 and the support added it later as part of a support ticket, but IPv6 never showed up automatically in the operating system's network configuration (even not after their suggested turn off/on of the virtual machine), thus I do not have any working example to look at).

nullnothere

@rsc said: Does somebody still run a working IPv6 configuration with them in a virtual machine? If so, did their setup change or did they simply mess up their network configuration related to me?

My VMs have IPv6 working as before. Nothing seems to have changed for me specifically.

IPv6: 2a0b:8bc0:2:xxxx::1 (/64)
Gateway: 2a0b:8bc0:2::1 (the /48)

My config (/etc/network/interfaces)

iface eth0 inet6 static
    accept_ra 0
    address 2a0b:8bc0:2:xxxx::1
    netmask 64
    gateway 2a0b:8bc0:2::1

rsc

@nullnothere said:
My VMs have IPv6 working as before. Nothing seems to have changed for me specifically.

IPv6: 2a0b:8bc0:2:xxxx::1 (/64)
Gateway: 2a0b:8bc0:2::1 (the /48)

After 7 business days, @naranjatech's support finally solved my issue (also thanks to this thread which helped me to understand how a working IPv6 configuration at them should look like). While I provided them a lot of information of what I tried and what did not work (and how ip neigh looks like), they finally noticed with my mentioning of 2a0b:8bc0:1::1 and 2a0b:8bc0:2::1 as non-working IPv6 default gateways (but 2a0b:8bc0:2::2 actually worked!), that something is wrong on their end. Initially, they assigned 2a0b:8bc0:1:xxxx::/64 to me, where 2a0b:8bc0:1::1 did not work. This evening they switched my assignment to 2a0b:8bc0:2:xxxx::/64 and, yay, 2a0b:8bc0:2::1 works just flawlessly as IPv6 default gateway.

sullivanroger867

Comparing what's out there, Naranja's method of giving a single /64 and expecting NDP proxying for nested IPs is pretty common for providers in their ~10-15 euro price bracket for a KVM. You'd typically find a routed /56 or a separate routed /64 with providers like Hetzner or OVH, but those often start at higher price points for similar CPU/RAM specs, offering that extra layer of routing abstraction. It's usually a cost-benefit trade-off where you do more manual work for a cheaper machine. Glad you found a working setup with ndppd.