This is my experience report after finally successfully setting up an IPv6 tunnel in sys-net in Qubes R4.0 and configuring things so that AppVMs could use it. It was quite a struggle - some things did not work as I expected.
Steps I followed to make it work: 1. Put the commands from Hurricane Electric, my IPv6 over IPv4 tunnel provider, into /rw/config/rc.local in sys-net. 2. As documented, in a dom0 terminal, enable the IPv6 feature: qvm-features sys-net ipv6 1 The rest of the steps I did not find documented anywhere: 3. At this point, dnf stopped working. This turned out to be an MTU issue - I had to add this line to my /rw/config/rc.local in sys-net: ip link set he-ipv6 mtu 1472 I had discovered this 1472 value using: tracepath6 mirrors.fedoraproject.org Although I don't think this was a Qubes issue, the same MTU value that I discovered also has to be used later as well. Side note: at this point, qubes-dom0-update was able to download packages but was not installing anything. However, I think that was because there was nothing that needed to be installed, because the downloaded packages were already up-to-date on dom0. So it wasn't a bug, or in any way related to this change, just a bit confusing. 4. I still had no IPv6 access in my web browsers in my AppVMs, so I investigated why. ipv6 NAT appeared to be set up in ip6tables as promised, but it wasn't working. I then discovered that net-vm didn't have an IPv6 address, other than a locally-scoped IPv6 address, for its virtual network interface. Is this a qubes bug? I added an IPv6 address: ip addr add fc00::10:8:8:71/7 dev vif9.0 and made it routable from sys-firewall: sudo ip -6 route add fc00::10:8:8:71 dev eth0 sudo ip -6 route add default via fc00::10:8:8:71 dev eth0 At this point I could successfully execute ping v6.ipv6-test.com 5. The web browsers still weren't able to use IPv6, and again it turned out to be an MTU issue. I had to execute: echo 1472 > /proc/sys/net/ipv6/conf/eth0/mtu as root, in both sys-firewall and the AppVM. Again, this was based on the MTU value I had discovered earlier. This means that path MTU discovery within the Qubes internal network doesn't work for IPv6 in Qubes. Though, based on something I have read about that, I think that may be a good thing from a security point of view. Can we simplify this process? It's quite complicated. Perhaps the firewall could by default allow through IPv6 ICMP messages to make MTU discovery work, only if they came from the internal network. Or perhaps that's incompatible with NAT of IPv6. I'm new to IPv6 and I'm still learning how it works. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CACVBcp51S2jHKkFbK9_jD5ThqMgg0Tp7A3bCMG35LY%2BVwwF1fQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
