New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Help with IPV6 Bridge settings Debian/Hetzner
Hi,
I'm going to pull my hair out. Can anybody help with a working IPV6 setup for host and guest on a bridged system on a dedicated server? IPV4 works like a charm, but I just don't know what to do with this ipv6 setup.
Thanks in advance.
My current setup on the host:
auto lo
iface lo inet loopback
auto vmbr0
iface vmbr0 inet static
address 1.2.3.4
netmask 255.255.255.255
pointopoint 1.2.3.1
gateway 1.2.3.1
bridge_ports enp4s0
bridge_stp off
bridge_fd 1
bridge_hello 2
bridge_maxage 12
iface vmbr0 inet6 static
address 2a01:4f8:1234:1234::1
netmask 64
gateway fe80::1
up ip route add IP.v4.local.route dev vmbr0
up ip -6 route add 2a01:4f8:1234:1234::/64 dev vmbr0
auto vmbr1
iface vmbr1 inet static
address 192.168.0.10
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
post-up iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o vmbr0 -j MASQUERADE
on the guest:
The loopback network interface
auto lo
iface lo inet loopback
The primary network interface
auto ens19
iface ens19 inet static
address 192.168.0.2/24
gateway 192.168.0.1
dns-nameservers 192.168.0.1 8.8.8.8
auto ens18
iface ens18 inet static
address 1.2.3.5
netmask 255.255.255.255
pointopoint 1.2.3.1
gateway 1.2.3.1
iface ens18 inet6 static
address 2a01:4f8:1234:1234::2
gateway fe80::1
netmask 64
Comments
PM me if you need me to fix this for you. I bill a few beers though... ;]
I sympathize with your pain on this issue. I've had my own strange issues with IPv6 on Hetzner.
Here's the setup I have that works for me. At one point I was having issues with IPv6 link-local addresses so that's why my configuration manually adds it. I believe it should be taken care of automatically though if you ignore it.
If you are still having issues, I recommend checking to see what's happening using tcpdump. e.g. tcpdump -i eth0 ip6
Note that I "reuse" the 2a01:4f8:1234:1234::1 IPv6 address on the host for both eth0 and br0. However I only add the /128 to eth0 and add the entire /64 subnet to br0.
In my configuration the bridging is handled by libvirt so that part isn't shown.
For each virtual machine I allocate a /112 (yes, I know this isn't technically correct but Hetzner charges extra if you want more than a /64 subnet).
e.g. virtual machine 1 is: 2a01:4f8:1234:1234::1:1/112
virtual machine 2 is: 2a01:4f8:1234:1234::2:1/112
...
settings on host:
Host /etc/network/interfaces:
Virtual machine /etc/network/interfaces:
Hey @goinsj2010:
Thank you for your kind reply.. I gotta admit that I'm only slowly getting into this IPv6 stuff and when I read your reply, I realize that I'm missing a lot of knowledge. Just to defend myself, this is just a hobby of me and so I do not claim to be an expert at all
The link local address is always the fe80 address which is given to a device automatically upon activating it? So I kinda route the traffic over this local address and then forward it to the actual given 64 (or whatever) net?
So I just tried to make it with those settings (of course changing values to my needs) but it either doesnt work or I messed up somehow. Maybe you can get into detail a little bit more :]
Hi @nobizzle
Don't worry if the IPv6 stuff is new to you. I can't claim to be an expert either so hopefully my advice on this topic is correct. I'm honestly not sure if IPv6 is more complicated than IPv4 or if we are just so familiar with the "old" way that it feels easier.
My understanding regarding the link-local addresses are that they provide a way to communicate with other hosts on the same physical link (or bridge). Normally a link-local address is automatically given to an interface based on its MAC address. As far as I know, the primary usage of these addresses is so that you can automatically communicate with routers on the same link and autoconfigure your global IP and other settings. Essentially, this allows IPv6 to implement the same behavior as DHCP.
In our case we don't really want the autoconfiguration part since Hetzner assigns you a static subnet of IPv6 addresses. To make configuration easier for you, Hetzner does a little "trick" and always assigns the link-local address of "fe80::1" to their routers. So no matter what physical server they give you, you can safely assume that the router is located at that IPv6 address.
So as far as debugging, I'd suggest first making sure that IPv6 works on your physical server and then progressing to make sure it works for your virtual servers.
First things first, on your host server if you run the command
do you get the same values that I showed in my previous post?
If not, you can change them for future reboots using something like the following:
Then restart your server and re-run the sysctl command to view the settings and make sure they are correct.
Now let's see if you can communicate with the local Hetzner IPv6 router. In a terminal window use the command
Now in another terminal window (while tcpdump is running) try executing the command
This is asking your server to ping the link-local address fe80::1 (e.g. the Hetzner router) using the eth0 interface. Note that the ping command had to specify which interface we were talking about since we asked about a link-local address.
Here are the results I get. In this example, the 3ada address is the link-local address assigned to my server's eth0 interface.
Awesome! We got a response from the router. Now if the default IPv6 route is set to fe80::1 on eth0, then we should be able to communicate with any global IPv6 addresses.
On the host server, an attempt to ping global IPv6 addresses should now work (assuming DNS works).
If everything works to this point then let me know and you can start debugging the virtual server connectivity.
To make it short for this answer: Everything is exactly like its described in your last post. This is really huge.. i learned a lot from it! I'm looking forward on what to do next ^^ thank you so far!
Okay, so IPv6 is working on the host.
Now for the virtual server setup. Insert caveat here... I use a bridged network configuration with KVM managed using libvirt/virsh. I'm not sure on the specifics of your usage but hopefully my example will provide enough guidance to lead you in the right direction.
For example, in my .xml configuration file that's used by virsh to define the KVM guest I have the following lines:
Your configuration may be different. On the host machine I can verify that my guest machines are connected to the bridge on interface vnet1, vnet2, and vnet3.
Since you said that IPv4 works properly, I'm assuming that your bridge configuration is already correct.
Now for the IPv6 configuration part. Let's start by copying the same strategy as Hetzner and adding a custom link-local IPv6 address of "fe80::1" to our bridge. This will be the address that we will use as the router for our virtual guests.
On the Host machine I have the following in /etc/network/interfaces (reiterated from my original post):
Notice that I assigned "2a01:4f8:1234:1234::1" to eth0 with a /128 subnet and also assigned the same IPv6 to br0, except with a /64 subnet. You don't have to do it this way (in fact it's probably more correct to assign a different IP address like "2a01:4f8:1234:1234::2" to the br0 interface). My inexperience with IPv6 is starting to show, so others will have to correct me if I've given you bad advice.
The important thing is that the /64 subnet is assigned to the br0 interface. This way the host server knows that any traffic for that IP range should be forwarded to the bridge.
If everything works correctly, the bridge should now have 1) a global static IPv6 address, 2) an automatic link-local address based on its MAC address, and 3) the "fe80::1" address that we manually assigned.
Here's my example:
The host machine should also be routing the traffic accordingly:
Now we can double check our virtual server network configuration. As noted previously, I personally split up the IPv6 allocation with a /112 subnet for each guest.
In the first guest machine, the /etc/network/interfaces file looks like this:
Notice that I am doing two things. First, I add the /112 subnet to the interface. Second, I am also instructing the KVM guest to use "fe80::1" as the default gateway. Since this is a link-local address it's actually going to connect to the br0 interface on the host machine. The host machine will then route the packet to the "fe80::1" address of the Hetzner router.
The routing table of the guest KVM machine:
It's finally time to test everything! After configuring everything as above, restart the host for good measure. I've previously had strange issues while configuring IPv6 with Hetzner and I'm becoming superstitious and starting to think that Hetzner sometimes "gives up" when sending traffic to your server (if the server isn't configured properly) and stops routing packets to the machine. I've never had issues after getting it set up correctly and waiting an hour or two.
Anyways, let's verify that packets are getting routed to you correctly. Use a different computer with IPv6 connectivity and try pinging the virtual server from the internet:
On the host machine:
Ping the IPv6 address (corrected with your IP info) and see what happens.
Hopefully the traffic will be routed through the internet to your server and you will see the ping request (and maybe even a ping response) in the tcpdump output. Now log into the guest virtual machine and try checking IPv6 connectivity. It should all work. If not, try debugging by running tcpdump on the br0 interface to make sure that packets are being forwarded correctly by the host machine.
Good luck!
Hey, first of all. Thanks for this superb tutorial. Really interesting and detailed. Lots of respect for taking the time to write this down. I love LET.
I did not have a lot of time yesterday, but i tried a little bit to make a few more steps.
On the host side everything seems to be as you described.
When trying to configure the VM guest, the machine does not come up with any IPv6 address. Is there a part missing in the given Guest config file?
I'll try again later and come back with more detailed information.
Again: Thank you!
Best regards
In the guest configuration posted above I manually assigned the IPv6 details using the "ip" command. You could also try using the standard /etc/network/interfaces syntax and see if that works for you.
The IPv6 info should still appear in the output of the "ip" command on the guest:
If everything is correct we should see the global IPv6 address that you manually assigned as well as the link-local address that was auto-assigned based on the MAC address.
First of all: sorry for the late response. The tutorial you wrote down here is just plain awesome! Thanks again!
Ok, I feel a little bit ashamed for not being able to realize the given solution in your last post on my own.. But yeah. IPv6 is now up and running. Partly.
I've been working on this for quite some time now. And i gotta admit that I'm pissed.
Whatever configuration I use, I end up with either having IPv4 on bot machines, or IPv6 on both machines. The best thing I could achieve was IPv4 and IPv6 on the host and IPv6 on the guest only.. I just don't know what to do anymore.
I'll try a little bit more tonight, but I almost gave up on it. If I can't make it, I'll post some of my settings I had the last few days..
Hmm, that's strange. As far as I know, IPv6 and IPv4 in Linux are completely independent so enabling one should have no affect on the other.
The only time I've encountered behavior like you describe is when I've installed firewall software (Shorewall) on the host. For example, if you install an IPv4 firewall, sometimes IPv6 gets disabled by default.
If you're comfortable giving me sudo or root access pm me and I can log in to help you. It sounds like you are really close to having everything working.
Ok.. it took me several days. I neglected my girlfriend and job, but i finally made it. And damn, it's actually VERY easy. Here is my solution:
HOST:
GUEST:
Don't forget the sysctl settings posted above. But now the funny part:
I don't want to change anything now, as is finally works and it took me A LOT of time to find this easy soltution, but in Proxmox I had to set the network interface to VMware vxnet on the guest. Not Intel (My server has a Intel card), not virtio. This one works.
Have fun with it. Peace I'm out.
Thank you, guys!