[GELÖST] IPv6-IPs auf KVM-Host zu den VMs routen

[Kaheto]

Ich konnte jetzt zumindest einmal Teilerfolge mit einer VM erzielen. Dazu habe ich auf dem KVM-Host (87.56.85, 2a03:587:140:6268::::2) zuerst die libvirt-Config erstellt.
/etc/libvirt/qemu/networks/routed1.xml

Code: Alles auswählen

<network>
  <name>routed1</name>
  <uuid>b0277bde-555b-49d3-a3b0-b53f6ad1956a</uuid>
  <forward dev='enp0s31f6' mode='route'>
    <interface dev='enp0s31f6'/>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:fb:78:46'/>
  <domain name='example.com'/>
  <ip address='167.9.107.1' netmask='255.255.255.0'>
  </ip>
  <ip family='ipv6' address='2a03:587:140:6268::::1' prefix='64'>
    <dhcp>
      <range start='2a03:587:140:6268::::100' end='2a03:587:140:6268::::1ff'/>
    </dhcp>
  </ip>
</network>

Wobei ich jetzt statt wie üblich die IP-Adresse von virbr0 nicht auf 192.168.1.1 sondern auf 167.9.107.1 gesetzt habe, in der Hoffnung, dass Hetzner diese nicht nutzt.
KVM-interfaces:

Code: Alles auswählen

# The loopback network interface
auto lo
iface lo inet loopback
iface lo inet6 loopback

# The primary network interface enp0s31f6
auto enp0s31f6
iface enp0s31f6 inet static
        address 87.56.85.85
        netmask 255.255.255.255
        pointopoint 87.56.85
        gateway 87.56.85.65

iface enp0s31f6 inet6 static
        address 2a03:587:140:6268::::2
        netmask 64
        gateway fe80::1

Routing KVM:

Code: Alles auswählen

default via 87.56.85 dev enp0s31f6 onlink 
87.56.85 dev enp0s31f6 proto kernel scope link src 87.56.85.85 
167.9.107.0/24 dev virbr0 proto kernel scope link src 167.9.107.1

Code: Alles auswählen

::1 dev lo proto kernel metric 256 pref medium
2a03:587:140:6268::::/64 dev enp0s31f6 proto kernel metric 256 pref medium
2a03:587:140:6268::::/64 dev virbr0 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
fe80::/64 dev virbr0 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s31f6 metric 1024 onlink pref medium

Pings nach aussen funktionieren

Code: Alles auswählen

# ping6  2003:e5:9710:7a00:213:3bff:fe10:773c
PING 2003:e5:9710:7a00:213:3bff:fe10:773c(2003:e5:9710:7a00:213:3bff:fe10:773c) 56 data bytes
64 bytes from 2003:e5:9710:7a00:213:3bff:fe10:773c: icmp_seq=1 ttl=58 time=20.4 ms
64 bytes from 2003:e5:9710:7a00:213:3bff:fe10:773c: icmp_seq=2 ttl=58 time=20.6 ms
64 bytes from 2003:e5:9710:7a00:213:3bff:fe10:773c: icmp_seq=3 ttl=58 time=20.5 ms

Code: Alles auswählen

ping www.google.com
PING www.google.com(fra16s42-in-x04.1e100.net (2a00:1450:4001:809::2004)) 56 data bytes
64 bytes from fra16s42-in-x04.1e100.net (2a00:1450:4001:809::2004): icmp_seq=1 ttl=118 time=5.07 ms
64 bytes from fra16s42-in-x04.1e100.net (2a00:1450:4001:809::2004): icmp_seq=2 ttl=118 time=5.11 ms
64 bytes from fra16s42-in-x04.1e100.net (2a00:1450:4001:809::2004): icmp_seq=3 ttl=118 time=5.11 ms

Die VM (Mailserver) hat 167.9.107.244 und 2a03:587:140:6268::::24/64 mit

Code: Alles auswählen

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet static
        address 167.9.107.244
        netmask 255.255.255.255
        pointopoint 87.56.85.85
        gateway 87.56.85.85
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.1.1 213.133.100.100 9.9.9.9
        dns-search example.com

iface enp1s0 inet6 static
        address 2a03:587:140:6268::::24
        netmask 64
        gateway 2a03:587:140:6268::::1
        dns-nameservers 2a01:4f8:0:1::add:1010 2620:fe::fe:9

Routing auf VM:

Code: Alles auswählen

default via 87.56.85.85 dev enp1s0 onlink 
87.56.85.85 dev enp1s0 proto kernel scope link src 167.9.107.244

Code: Alles auswählen

::1 dev lo proto kernel metric 256 pref medium
2a03:587:140:6268::::/64 dev enp1s0 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
default via 2a03:587:140:6268::::1 dev enp1s0 metric 1024 onlink pref medium

Von aussen ist die VM via ssh, smtp, http erreichbar, soweit gut. Aber ich kann nicht rauspingen

Code: Alles auswählen

ping6  2003:e5:9710:7a00:213:3bff:fe10:773c
PING 2003:e5:9710:7a00:213:3bff:fe10:773c(2003:e5:9710:7a00:213:3bff:fe10:773c) 56 data bytes

und von aussen

Code: Alles auswählen

ping6 2a03:587:140:6268::::24
PING 2a03:587:140:6268::::24(2a03:587:140:6268::::24) 56 data bytes
From 2a03:587:140:6268::::2: icmp_seq=1 Destination unreachable: Address unreachable

Also ich weiß nicht, ob das jetzt die richtige Herangehensweise ist. Das Routing sollte noch angepasst werden. Und ich weiß nicht, wie man das mit der IP 167.9.107.1 für die Bridge lösen kann, denn die ist bei Hetzner sicher anders vergeben.

Ich bin dankbar, wenn man mir meine Fehler zeigen kann bzw. was ich besser machen kann.

[Kaheto]

radvd habe ich noch nicht verstanden, was das soll. Denn die IPs 4 wie 6 sollen doch geroutet werden und somit an den VMs wie von aussen zur Verfügung stehen.

[reox]

radvd tut nur das prefix announcen und den clients sagen, dass da ein router ist.
ich bin mir nicht ganz sicher aber glaube das libvirt das auch irgendwie intern kann, habs aber nur mit dem radvd zum laufen gebracht.

[Kaheto]

radvd tut nur das prefix announcen und den clients sagen, dass da ein router ist.
ich bin mir nicht ganz sicher aber glaube das libvirt das auch irgendwie intern kann, habs aber nur mit dem radvd zum laufen gebracht.

Würde das eventuell das oben beschriebene Routingproplem bei den VMs lösen?

[reox]

ah, da hatte ich gar nicht ganz angeschaut

also ich würde als gateway die link-local adresse von der bridge nehmen, also fe80:...usw
Versuch das mal von der VM zu pingen, das muss auch gehen ohne das du eine public v6 IP vergibst.

edit wegen den adressen: in der libvirt doku steht

For IPv6, the default route is established via Router Advertisement.

https://libvirt.org/formatnetwork.html

Aber irgendwie klappt das bei mir nicht. Offenbar gehts nur wenn man auch DHCPv6 verwendet, aber eigentlich mag ich das eher mit der autoconfig haben... ohne das hier kapern zu wollen: Weiß jemand ob man mit libvirt auch SLAAC machen kann ohne extra den radvd anzuwerfen?

[Kaheto]

Also ich habe es jetzt einmal mit

Code: Alles auswählen

gateway fe80::5054:ff:fefb:7846

in der Guest-interfaces ausprobiert. Das Ergebnis bleibt gleich, obwohl ich es wie Hetzner mache

Code: Alles auswählen

# /etc/network/interfaces
### Beispiel für Einzel-IP aus fremden Subnetz
# Loopback device:
auto lo
iface lo inet loopback

# device: ens18
auto ens18
iface ens18 inet static
  [b]address <Zusatz-IP>[/b]
  netmask 255.255.255.255
  [b]pointopoint <Haupt-IP>[/b]
  [b]gateway <Haupt-IP>[/b]

iface ens18 inet6 static
  address <Adresse aus dem IPv6-Subnetz> # z.B. 2001:db8::f001
  netmask 64
  [b]gateway <IPv6-Adresse vmbr0>[/b] # z.B. 2001:db8::3

Respektive, wie müssen das Routing, die Firewall-Rules auf dem KVM-Host aussehen und wie auf der VM?

[reox]

Hast du net.ipv6.conf.all.forwarding=1 in sysctl gesetzt?

Kannst du aus der VM fe80::5054:ff:fefb:7846 pingen?

was macht ein ping6 ff02::2 bzw ping6 ff02::1 (pinge alle router bzw alle hosts)?

[Kaheto]

Hast du net.ipv6.conf.all.forwarding=1 in sysctl gesetzt?

Kannst du aus der VM fe80::5054:ff:fefb:7846 pingen?

was macht ein ping6 ff02::2 bzw ping6 ff02::1 (pinge alle router bzw alle hosts)?

Punkt 1 ist von Anfang an gesetzt.
Punkt 2 funktioniert auch

Code: Alles auswählen

# ping6 fe80::5054:ff:fefb:7846
PING fe80::5054:ff:fefb:7846(fe80::5054:ff:fefb:7846) 56 data bytes
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=1 ttl=64 time=0.192 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=2 ttl=64 time=0.251 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=3 ttl=64 time=0.260 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=4 ttl=64 time=0.249 ms

Punkt 3 ebenfalls

Code: Alles auswählen

root@mx ~ # ping6 ff02::2
PING ff02::2(ff02::2) 56 data bytes
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=2 ttl=64 time=0.273 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=3 ttl=64 time=0.267 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=4 ttl=64 time=0.272 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=5 ttl=64 time=0.252 ms
^C
--- ff02::2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 77ms
rtt min/avg/max/mdev = 0.099/0.232/0.273/0.069 ms
root@mx ~ # ping6 ff02::1
PING ff02::1(ff02::1) 56 data bytes
64 bytes from fe80::5054:ff:fe38:a916%enp1s0: icmp_seq=1 ttl=64 time=0.061 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=1 ttl=64 time=0.320 ms (DUP!)
64 bytes from fe80::5054:ff:fe38:a916%enp1s0: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=2 ttl=64 time=0.374 ms (DUP!)
64 bytes from fe80::5054:ff:fe38:a916%enp1s0: icmp_seq=3 ttl=64 time=0.071 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=3 ttl=64 time=0.374 ms (DUP!)
64 bytes from fe80::5054:ff:fe38:a916%enp1s0: icmp_seq=4 ttl=64 time=0.069 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=4 ttl=64 time=0.285 ms (DUP!)
^C
--- ff02::1 ping statistics ---
4 packets transmitted, 4 received, +4 duplicates, 0% packet loss, time 78ms
rtt min/avg/max/mdev = 0.061/0.203/0.374/0.137 ms

Dieser Ping bleibt so hängen

Code: Alles auswählen

root@mx ~ # ping6 www.google.com
PING www.google.com(fra02s19-in-x04.1e100.net (2a00:1450:4001:808::2004)) 56 data bytes

Das geht allerdings auch, der hat aber auch keinen AAAA-Record sondern nur A:

Code: Alles auswählen

root@mx ~ # ping www.lihas.de
PING www.lihas.de (45.150.154.30) 56(84) bytes of data.
64 bytes from rproxy.lihas.de (45.150.154.30): icmp_seq=1 ttl=53 time=5.96 ms
64 bytes from rproxy.lihas.de (45.150.154.30): icmp_seq=2 ttl=53 time=6.21 ms
64 bytes from rproxy.lihas.de (45.150.154.30): icmp_seq=3 ttl=53 time=6.25 ms
64 bytes from rproxy.lihas.de (45.150.154.30): icmp_seq=4 ttl=53 time=6.19 ms
^C
--- www.lihas.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 5.959/6.151/6.246/0.112 ms

Was bei der Interfaces auf dem Host bei virbr0 (weil über libvirt konfiguiert) fehlt, sind diese 3 Optionen

Code: Alles auswählen

        bridge_stp off       # disable Spanning Tree Protocol
        bridge_waitport 0    # no delay before a port becomes available
        bridge_fd 0          # no forwarding delay

die im Bridge-Modus die vmbr0 erhält.

[reox]

hmm soweit so gut. dH du siehst das korrekt als gateway und connection ist auch da. Dann kann es wohl nur so sein, dass irgendwo der Ping hängen bleibt.
rennt da irgendwo eine firewall? Wenn du vom host pingen kannst, kanns *eigentlich* nur daran liegen.

diese bridge optionen brauchst du IMHO nicht bei der virbr.

[Kaheto]

rennt da irgendwo eine firewall? Wenn du vom host pingen kannst, kanns *eigentlich* nur daran liegen.

Nein, ich schalte die Shorewall auf dem Host ab, da die für die Bridge-Methode und Nat konfiguriert ist. Ich würde ansonsten gar nicht auf den Host kommen. Dennoch sehe ich

Code: Alles auswählen

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:67

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             194.8.125.0/24      
ACCEPT     all  --  194.8.125.0/24       anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

und

Code: Alles auswählen

# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp      anywhere             anywhere             udp dpt:dhcpv6-server
ACCEPT     udp      anywhere             anywhere             udp dpt:domain
ACCEPT     tcp      anywhere             anywhere             tcp dpt:domain

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all      anywhere             2a03:587:140:6268::/64 
ACCEPT     all      2a03:587:140:6268::/64  anywhere            
ACCEPT     all      anywhere             anywhere            
REJECT     all      anywhere             anywhere             reject-with icmp6-port-unreachable
REJECT     all      anywhere             anywhere             reject-with icmp6-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

[Kaheto]

Ich habe jetzt mal recherchiert und gefunden, dass bei libvirt "nwfilter" für Firewallregeln auf dem Host bzw. Gast existiert.

Code: Alles auswählen

# virsh nwfilter-list 
 UUID                                   Name
-----------------------------------------------------------------
 0525f8ed-9b19-4fe8-9f71-3152041ce99c   allow-arp
 d97104ba-5dd2-488a-a361-42caca0176dd   allow-dhcp
 0eb7caaa-1be6-41b4-a336-07b0e4e32534   allow-dhcp-server
 8a076492-d9b5-403c-8a64-bcaf1f47dec6   allow-incoming-ipv4
 bbae4326-2d89-4177-9d49-83ef67316102   allow-ipv4
 c1590c18-f2bd-4717-9375-da162fdd825d   clean-traffic
 6fbe195c-87ef-4fa2-97f3-527ede0c9334   clean-traffic-gateway
 9ab0ceb9-3037-4077-8ef7-470b658d4aff   no-arp-ip-spoofing
 132de347-338c-43e1-bbba-b329a1667f45   no-arp-mac-spoofing
 9bf301a5-0d43-4135-b51b-56ee6af27b71   no-arp-spoofing
 7ba954ec-2b91-44d4-b126-56e9e526a8cc   no-ip-multicast
 b3e9258e-8020-4922-b649-92129e88ba29   no-ip-spoofing
 10437c97-33f8-4112-b243-744ff3dbc1c4   no-mac-broadcast
 10cc4590-9397-4f50-9ca9-7e8e159f4efe   no-mac-spoofing
 8075e4e0-04a2-420e-8f20-446129b86337   no-other-l2-traffic
 0e27c307-e993-491e-9afe-020713c57168   no-other-rarp-traffic
 90f5d653-fab9-4329-b558-8f0641a746b8   qemu-announce-self
 65b2bed5-9aec-4f57-b654-016c48bf0d49   qemu-announce-self-rarp

Zeigt das auch.

Auf der VM wird allerdings nichts dergleichen angelegt:

Code: Alles auswählen

 # ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[Kaheto]

Jetzt habe ich diese Regeln

Code: Alles auswählen

REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

mit

Code: Alles auswählen

iptables -D FORWARD 5
iptables -D FORWARD 4
ip6tables -D FORWARD 5
ip6tables -D FORWARD 4

gelöscht und

Code: Alles auswählen

iptables -A FORWARD -p icmp -j ACCEPT
ip6tables -A FORWARD -p icmp -j ACCEPT

gesetzt. Die Regeln auf dem Host sehen jetzt so aus

Code: Alles auswählen

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:67

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             194.8.125.0/24      
ACCEPT     all  --  194.8.125.0/24       anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootp


# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp      anywhere             anywhere             udp dpt:dhcpv6-server
ACCEPT     udp      anywhere             anywhere             udp dpt:domain
ACCEPT     tcp      anywhere             anywhere             tcp dpt:domain

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all      anywhere             2a03:587:140:6268::/64 
ACCEPT     all      2a03:587:140:6268::/64  anywhere            
ACCEPT     all      anywhere             anywhere            
ACCEPT     icmp     anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

IPv4 von VM nach aussen geht:

Code: Alles auswählen

root@mx ~ # ping  93.220.240.28
PING 93.220.240.28 (93.220.240.28) 56(84) bytes of data.
64 bytes from 93.220.240.28: icmp_seq=1 ttl=57 time=16.5 ms
64 bytes from 93.220.240.28: icmp_seq=2 ttl=57 time=16.6 ms
64 bytes from 93.220.240.28: icmp_seq=3 ttl=57 time=16.5 ms
^C
--- 93.220.240.28 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 16.452/16.528/16.629/0.074 ms

aber nach wie vor nicht mit IPv6

Code: Alles auswählen

ping6  2003:e5:970a:500:213:3bff:fe10:773c
PING 2003:e5:970a:500:213:3bff:fe10:773c(2003:e5:970a:500:213:3bff:fe10:773c) 56 data bytes
^C
--- 2003:e5:970a:500:213:3bff:fe10:773c ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 197ms

An die externe IP-Adresse genauso

Code: Alles auswählen

root@mx ~ # ping6 2a03:587:140:6268::2
PING 2a03:587:140:6268::2(2a03:587:140:6268::2) 56 data bytes
From 2a03:587:140:6268::24: icmp_seq=1 Destination unreachable: Address unreachable

[reox]

da hab ich jetzt leider keine idee

aber was sagt `ip -6 r` auf dem host und in der VM? vllt doch noch irgendwie ein routing problem

[Kaheto]

Ich glaube ich komme der Sache etwa näher, denn auf dem Host hat 2a03:587:140:6268::/64 zwei Routen. Einmal über enp0s31f6 und einmal über virbr0:

Code: Alles auswählen

root@srv ~ # ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2a03:587:140:6268::/64 dev enp0s31f6 proto kernel metric 256 pref medium
2a03:587:140:6268::/64 dev virbr0 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
fe80::/64 dev virbr0 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s31f6 metric 1024 onlink pref medium

Auf der VM ist es wie folgt.

Code: Alles auswählen

root@mx ~ # ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2a03:587:140:6268::/64 dev enp1s0 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
default via 2a03:587:140:6268::1 dev enp1s0 metric 1024 onlink pref medium

Ich setze die Routen bislang nicht manuell, sondern das passiert offensichtlich durch libvirt.

[Kaheto]

Okay, jetzt habe ich eine Teillösung geschafft!

Code: Alles auswählen

ip -6 route del 2a03:587:140:6268::/64 dev enp0s31f6

auf dem Host sorgt dafür, dass die VM via IPv6 ihre Connections bekommt. Jetzt ist natürlich interessant, diese Route erst gar nicht entstehen zu lassen.

[reox]

könnte sein, dass es noch ein relikt von der konfiguration vorher ist wo auf dem enp0s31f6 noch die /64 und nicht die /128 war.

Interessant das du die route bekommst, weil bei mir macht das libvirt nicht selber. Aber du hast ja auch dhcpv6 konfiguriert oder?

[Kaheto]

Okay, das stimmt. Ich hatte für enp0s31f6 noch /64 in der Config stehen. Mit dem Austausch zu /128 sind zwar beide Interfaces als Route auf dem Host drin, allerdings kann die VM jetzt korrekt rauspingen. Damit wäre das Thema erfolgreich geschlossen. Vielen Dank für Deine Unterstützung

[reox]

np

zur vollständigkeit:
ich hab jetzt bei mir noch den dhcpv6 von libvirt getestet und damit wird auch korrekt eine route gesetzt.
Das einzige was damit ein wenig frickelig zu sein scheint, ist den VMs die richtige IP zuzuteilen. mit name='xxx' klappt es irgendwie nur mit der hälfte meiner VMs :/
mac='xxx' geht lt. doku mit v6 nicht und die id bekomme ich ja gar nicht beim aufsetzen der VM (ich hab da ein script zum erstellen wo ich das wissen müsste...)
Egal, aber das tut ja für diesen thread nichts zur sache.