[GELÖST] Namensauflösung schlägt nach Installation fehl

[Njuguna]

Hallo,

bei einer VM-Basisinstallation auf Promox [192.110.55.250] habe ich wieder das Problem der Namensauflösung. Mit dieser resov.conf

Code: Alles auswählen

/etc/resolv.conf 
search example.tld
nameserver 9.9.9.9

und dieser Netzkonfiguration

Code: Alles auswählen

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug ens19
iface ens19 inet static
        address 192.110.55.86
        netmask 255.255.255.255
        pointopoint 192.110.55.250
        gateway 192.110.55.250
        dns-nameservers 9.9.9.9 
        dns-search example.tld

allow-hotplug ens18
iface ens18 inet static
        address 192.168.1.86/24
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 9.9.9.9 
        dns-search example.tld

kann ich keinen externen Hostnamen wie www.google.com anpingen. Die Ip-Adressen funktioniert erwartungs gemäss.

Code: Alles auswählen

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:32:84:47:a0:aa brd ff:ff:ff:ff:ff:ff
    altname enp0s19
    inet 192.168.1.85/24 brd 192.168.1.255 scope global ens19
       valid_lft forever preferred_lft forever
    inet6 fe80::2032:84ff:fe47:a0aa/64 scope link 
       valid_lft forever preferred_lft forever       
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether e6:9d:5c:92:ba:cf brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 192.110.55.86 peer 192.110.55.250/32 brd 192.110.55.86 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::e49d:5cff:fe92:bacf/64 scope link 
       valid_lft forever preferred_lft forever

Code: Alles auswählen

ip r
default via 192.110.55.250 dev ens19 onlink 
192.110.55.250 dev ens19 proto kernel scope link src 192.110.55.86
192.168.1.0/24 dev ens18 proto kernel scope link src 192.168.1.85

Ich finde den Fehler leider nicht. Weder in der Netzwerkkonfiguration noch in der resolv.conf. Installiert ist Debian 12.2.0.

Viele Grüße
Njuguna

[heisenberg]

1. Steht Dein Proxmox bei Hetzner? Wenn ja: Hast Du die MAC-Adresse der VM freigeschaltet? (Hetzner-Doku: Proxmox VE)
2. Geht ein ping auf die 9.9.9.9 aus der VM heraus?
3. Geht ein nslookup -query=A www.google.de 9.9.9.9 aus der VM heraus?

[Njuguna]

1. Steht Dein Proxmox bei Hetzner? Wenn ja: Hast Du die MAC-Adresse der VM freigeschaltet? (Hetzner-Doku: Proxmox VE)
2. Geht ein ping auf die 9.9.9.9 aus der VM heraus?
3. Geht ein nslookup -query=A www.google.de 9.9.9.9 aus der VM heraus?

Hallo Heisenbetrg,
zu 1) nein
Pings gehen problemlos auf externe IP-Adressen hinaus. Für mich sieht das nach reiner Namensauflösung aus.
Einen Nslookup kann ich leider nicht machen, weil nur die Basispakete installiert sind.
Der Promox-Server hängt an einem Switch, der ähnlich wie bei Hetzner konfiguriert ist, so dass ich die VMs via Pointopoint anschliessen muss. Das geht im Debian-Installer nicht und du musst irgendwann ohne Repository weitermachen, halt mit den Systempaketen. Dann kann ich erst über die Proxmox-Gui das Netzwerk der VM anschließen. Da wären wir wieder bei dem Problem. Bisher hatte diese Vorgehensweise geklappt.

[mat6937]

Einen Nslookup kann ich leider nicht machen, weil nur die Basispakete installiert sind.

Dann versuch mit:

Code: Alles auswählen

host -t a google.de 9.9.9.9
host -t a -T google.de 9.9.9.9
nc -zv 9.9.9.9 53

[Njuguna]

Einen Nslookup kann ich leider nicht machen, weil nur die Basispakete installiert sind.

Dann versuch mit:

Code: Alles auswählen

host -t a google.de 9.9.9.9
host -t a -T google.de 9.9.9.9
nc -zv 9.9.9.9 53

Hätte ich auch bereits gerne gemacht, aber auch diese Kommandos sind leider nicht installiert.

[MSfree]

Hätte ich auch bereits gerne gemacht, aber auch diese Kommandos sind leider nicht installiert.

ping muß auch eine Namensauflösung durchführen, wenn du es mit Hostnamen statt IP-Adresse aufrufst.

Code: Alles auswählen

ping www.google.com

Führt also zuerst mal intern ein nslookup www.google.com mittles libc-Funktionen auf und pingt anschließend die zurückgelieferte IP-Adresse an.

[heisenberg]

Code: Alles auswählen

ping www.google.com

Führt also zuerst mal intern ein nslookup www.google.com mittles libc-Funktionen auf und pingt anschließend die zurückgelieferte IP-Adresse an.

Und diese beiden Schritte sieht man auch getrennt auf der Konsole beim ping. Als erstes findet die Namensauflösung statt, dann wird die IP-Adresse auch als Text ausgegeben und dann wird der ping durchgeführt und entweder mit Fehler oder Erfolg quittiert.

Die Frage ist dann noch: Was von den Tests (ping auf ip, namensauflösung) funktioniert auf dem PVE-Host und was funktioniert in der VM?

[Njuguna]

Das ist alles nachvollziehbar, bringt aber nichts, wenn die Tools alle nicht drauf sind, wenn nur ca. 50 Pakete installiert wurden sind.

Und diese beiden Schritte sieht man auch getrennt auf der Konsole beim ping. Als erstes findet die Namensauflösung statt, dann wird die IP-Adresse auch als Text ausgegeben und dann wird der ping durchgeführt und entweder mit Fehler oder Erfolg quittiert.

Das wäre sehr hilfreich, aber die Realitität ist das das hier

Code: Alles auswählen

ping www.google.com
ping: www.google.com: Temporärer Fehler bei der Namensauflösung

Die Frage ist dann noch: Was von den Tests (ping auf ip, namensauflösung) funktioniert auf dem PVE-Host und was funktioniert in der VM?

Auf dem PVE-Host funktionieren alle Tests von oben:

Code: Alles auswählen

ping -c2 www.google.com
PING www.google.com (172.217.23.100) 56(84) bytes of data.
64 bytes from mil04s23-in-f4.1e100.net (172.217.23.100): icmp_seq=1 ttl=118 time=7.38 ms
64 bytes from mil04s23-in-f100.1e100.net (172.217.23.100): icmp_seq=2 ttl=118 time=7.49 ms

--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 7.382/7.437/7.493/0.055 ms

Code: Alles auswählen

host -t a google.com 9.9.9.9
Using domain server:
Name: 9.9.9.9
Address: 9.9.9.9#53
Aliases: 

Code: Alles auswählen

nc -zv 9.9.9.9 53
dns9.quad9.net [9.9.9.9] 53 (domain) open

[mat6937]

Code: Alles auswählen

ping www.google.com
ping: www.google.com: Temporärer Fehler bei der Namensauflösung

Wie sind die Ausgaben von:

Code: Alles auswählen

nft list ruleset
iptables -nvx -L

?

[heisenberg]

Und diese beiden Schritte sieht man auch getrennt auf der Konsole beim ping. Als erstes findet die Namensauflösung statt, dann wird die IP-Adresse auch als Text ausgegeben und dann wird der ping durchgeführt und entweder mit Fehler oder Erfolg quittiert.

Das wäre sehr hilfreich, aber die Realitität ist das das hier

Code: Alles auswählen

ping www.google.com
ping: www.google.com: Temporärer Fehler bei der Namensauflösung

Das ist doch schon mal super. Man sieht, dass die Namensauflösung - d. h. der erste Schritt der beiden oben erwähnten - schlägt fehl.

Die Frage ist dann noch: Was von den Tests (ping auf ip, namensauflösung) funktioniert auf dem PVE-Host und was funktioniert in der VM?

Auf dem PVE-Host funktionieren alle Tests von oben:

Code: Alles auswählen

ping -c2 www.google.com
PING www.google.com (172.217.23.100) 56(84) bytes of data.
64 bytes from mil04s23-in-f4.1e100.net (172.217.23.100): icmp_seq=1 ttl=118 time=7.38 ms
64 bytes from mil04s23-in-f100.1e100.net (172.217.23.100): icmp_seq=2 ttl=118 time=7.49 ms

--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 7.382/7.437/7.493/0.055 ms

Code: Alles auswählen

host -t a google.com 9.9.9.9
Using domain server:
Name: 9.9.9.9
Address: 9.9.9.9#53
Aliases: 

Code: Alles auswählen

nc -zv 9.9.9.9 53
dns9.quad9.net [9.9.9.9] 53 (domain) open

Danke auch dafür. Jetzt weiss ich etwas mehr über den aktuellen Stand. (Du hast das vielleicht vorher schon gewusst aber wir/ich nicht.)

Du kannst in der VM Pakete installieren, wenn Du der VM als ISO-Image eine Debian-DVD virtuell einlegst (und die DVD in apt entsprechend vorher konfigurierst mit apt-cdrom). Da könntest Du dann erstmal folgendes installieren für die weitere Fehlersuche (auf dem Host und in der VM):

bind9-host (-> host)
tcpdump

[Njuguna]

Danke für den Hinweis mit der DVD. Ich hatte inzwischen die VM neuinstalliert im Expertenmodus und mit Remote-Installer, so ist wenigstens ssh-Login möglich. Jetzt hatte ich mir die Pakete zu netcat, nslookup, host auf diesem Umweg besorgt, schitert aber an den vielen Abhängigkeiten.
Ich versuche es jetzt mal mit Deiner Idee.

[Njuguna]

Jetzt habe ich die Tools beisammen.

Code: Alles auswählen

# iptables -nvx -L
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Code: Alles auswählen

nft list ruleset

liefert auch nichts.
Und

Code: Alles auswählen

host -t a google.com 9.9.9.9
;; communications error to 9.9.9.9#53: timed out
;; communications error to 9.9.9.9#53: timed out
;; no servers could be reached

dasselbe gilt bei

Code: Alles auswählen

nslookup -query=A www.google.de 9.9.9.9
;; communications error to 9.9.9.9#53: timed out
;; communications error to 9.9.9.9#53: timed out
;; communications error to 9.9.9.9#53: timed out
;; no servers could be reached

Aber

Code: Alles auswählen

ping -c4 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=58 time=6.45 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=58 time=6.46 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=58 time=6.46 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=58 time=6.46 ms

--- 9.9.9.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 6.454/6.460/6.463/0.003 ms

funktioniert.
Wäre jetzt zu klären, warum Port 53 auf 9.9.9.9 nicht klappt.

[MSfree]

Wäre jetzt zu klären, warum Port 53 auf 9.9.9.9 nicht klappt.

Vielleicht blockiert da ein Paketfilter auf dem Hostrechner?

Code: Alles auswählen

iptables -nvx -Ltination
nft list ruleset

auf dem Host ausführen.

[Njuguna]

Wäre jetzt zu klären, warum Port 53 auf 9.9.9.9 nicht klappt.

Vielleicht blockiert da ein Paketfilter auf dem Hostrechner?

Code: Alles auswählen

iptables -nvx -Ltination
nft list ruleset

auf dem Host ausführen.

Code: Alles auswählen

# iptables -nvx -Ltination
iptables v1.8.9 (nf_tables): chain `tination' in table `filter' is incompatible, use 'nft' tool.

und

Code: Alles auswählen

nft list ruleset

hatte ich gerade gepostet, das ist leer.

[Njuguna]

Ich habe jetzt einen tcpdump auf die Schnittstelle gemacht, auf der die externe IP-Adresse hängt. Und das Routing sieht so aus

Code: Alles auswählen

ip r
default via 192.110.55.250 dev ens18 onlink 
192.110.55.250 dev ens18 proto kernel scope link src 192.110.55.86 
192.168.1.0/24 dev ens19 proto kernel scope link src 192.168.1.86

Code: Alles auswählen

tcpdump -i ens18 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens18, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:29:44.248444 IP 192.110.55.86.43086 > 8.8.4.4.53: 44438+ A? 2.debian.pool.ntp.org.example.tld. (51)
13:29:44.248483 IP 192.110.55.86.43086 > 8.8.4.4.53: 12178+ AAAA? 2.debian.pool.ntp.org.example.tld. (51)
13:29:50.254967 IP 192.110.55.86.33431 > 9.9.9.9.53: 3928+ A? 3.debian.pool.ntp.org. (39)
13:29:50.254997 IP 192.110.55.86.33431 > 9.9.9.9.53: 17252+ AAAA? 3.debian.pool.ntp.org. (39)
13:29:55.260187 IP 192.110.55.86.48992 > 8.8.8.8.53: 3928+ A? 3.debian.pool.ntp.org. (39)
13:29:55.260205 IP 192.110.55.86.48992 > 8.8.8.8.53: 17252+ AAAA? 3.debian.pool.ntp.org. (39)
13:29:58.263374 IP 192.110.55.86.45459 > 8.8.4.4.53: 3928+ A? 3.debian.pool.ntp.org. (39)
13:29:58.263402 IP 192.110.55.86.45459 > 8.8.4.4.53: 17252+ AAAA? 3.debian.pool.ntp.org. (39)
13:30:04.269501 IP 192.110.55.86.33431 > 9.9.9.9.53: 3928+ A? 3.debian.pool.ntp.org. (39)
13:30:04.269529 IP 192.110.55.86.33431 > 9.9.9.9.53: 17252+ AAAA? 3.debian.pool.ntp.org. (39)
13:30:04.527904 IP 35.76.113.141 > 192.110.55.86: ICMP echo request, id 6, seq 2221, length 16
13:30:04.527931 IP 192.110.55.86 > 35.76.113.141: ICMP echo reply, id 6, seq 2221, length 16
13:30:05.892350 IP 43.198.222.150 > 192.110.55.86: ICMP echo request, id 16, seq 9824, length 16
13:30:05.892381 IP 192.110.55.86 > 43.198.222.150: ICMP echo reply, id 16, seq 9824, length 16
13:30:05.935852 IP 16.163.103.67 > 192.110.55.86: ICMP echo request, id 16, seq 9824, length 16
13:30:05.935867 IP 192.110.55.86 > 16.163.103.67: ICMP echo reply, id 16, seq 9824, length 16
13:30:06.018756 IP 16.163.129.41 > 192.110.55.86: ICMP echo request, id 16, seq 9824, length 16
13:30:06.018774 IP 192.110.55.86 > 16.163.129.41: ICMP echo reply, id 16, seq 9824, length 16
13:30:06.540401 IP 54.238.176.72 > 192.110.55.86: ICMP echo request, id 6, seq 15068, length 16
13:30:06.540428 IP 192.110.55.86 > 54.238.176.72: ICMP echo reply, id 6, seq 15068, length 16
13:30:06.803316 IP 13.230.30.46 > 192.110.55.86: ICMP echo request, id 5, seq 19381, length 16
13:30:06.803343 IP 192.110.55.86 > 13.230.30.46: ICMP echo reply, id 5, seq 19381, length 16
13:30:09.274682 IP 192.110.55.86.48992 > 8.8.8.8.53: 3928+ A? 3.debian.pool.ntp.org. (39)
13:30:09.274709 IP 192.110.55.86.48992 > 8.8.8.8.53: 17252+ AAAA? 3.debian.pool.ntp.org. (39)
13:30:09.340509 ARP, Request who-has 192.110.55.250 tell 192.110.55.86, length 28
13:30:09.340591 ARP, Reply 192.110.55.250 is-at 2a:98:c6:6a:13:9a, length 28
13:30:09.675147 ARP, Request who-has 192.110.55.86 tell 192.110.55.65, length 28
13:30:09.675159 ARP, Reply 192.110.55.86 is-at bc:24:11:95:b5:34, length 28
13:30:12.277832 IP 192.110.55.86.45459 > 8.8.4.4.53: 3928+ A? 3.debian.pool.ntp.org. (39)
13:30:12.277859 IP 192.110.55.86.45459 > 8.8.4.4.53: 17252+ AAAA? 3.debian.pool.ntp.org. (39)
13:30:14.586353 ARP, Request who-has 192.110.55.75 tell 192.110.55.65, length 28
13:30:15.627123 ARP, Request who-has 192.110.55.75 tell 192.110.55.65, length 28
13:30:16.651120 ARP, Request who-has 192.110.55.75 tell 192.110.55.65, length 28
13:30:18.284089 IP 192.110.55.86.53698 > 9.9.9.9.53: 5959+ A? 3.debian.pool.ntp.org.example.tld. (51)
13:30:18.284116 IP 192.110.55.86.53698 > 9.9.9.9.53: 8286+ AAAA? 3.debian.pool.ntp.org.example.tld. (51)
^C
35 packets captured
35 packets received by filter
0 packets dropped by kernel

Dann habe ich festgestellt, dass ein

Code: Alles auswählen

ssh 192.110.55.86

von einem Host im Internet nicht geht.
Das lässt mich erinnern, dass bei KVM früher bestimmte Flags für ein Forwarding gesetzt wurden. Ich weiß bloss nicht mehr Welche. Ausserdem habe ich nebenan einen PVE-Host mit 10 VMs stehen, woe dieses Namensauflösungsproblem nicht besteht.

[heisenberg]

Code: Alles auswählen

iptables -nvx -Ltination

Der Befehl ist falsch. Das tination am Ende muss weg.

Code: Alles auswählen

iptables -nvx -L

[Njuguna]

Code: Alles auswählen

iptables -nvx -L
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination 

Da ist noch nichts drin.

[heisenberg]

Also das sieht stark nach Firewall aus. Wenn nicht auf dem Host, dann zwischen Host und Internet.

• Bei welchem Provider steht die Kiste?
• Mach mal bitte - auf dem Host - einen

  Code: Alles auswählen

  tcpdump -i any host 9.9.9.9 -n

  und dann auf einem anderen Terminal in der VM einen

  Code: Alles auswählen

  host www.debianforum.de 9.9.9.9

• Anschließend zum Vergleich nochmal - auf dem Host - einen

  Code: Alles auswählen

  host www.debianforum.de 8.8.8.8

• Poste dann die Gesamtausgabe von tcpdump.

Vor kurzem gab es hier einen Fall, bei dem die DDOS-Protection des Anbieters nicht richtig funktioniert hat und Traffic weggefiltert hatte.

[heisenberg]

Was ich hier insgesamt recht mühselig finde ist, dass für mich die Konfiguration nicht zu 100% gesichert ist, auch wenn ich aktuell vermute, dass es wohl passt. D. h. ich hätte grundsätzlich gerne die Angabe für welches System ("Host" oder "VM") der jeweillige Befehl jetzt ausgeführt wurde. Ich bin mir nicht zu 100% sicher, dass das jetzt immer richtig war. Das ist eine potentielle Fehlerquelle bei dem Austausch hier.

Insofern die Bitte, dass nochmal sauber aufzulisten:

Was ist genau die IP-Adresskonfiguration für Host und VM? (ip addr show)
Was ist genau die Routing-Konfiguration für Hosts und VM? (ip route show)
Wenn ich das jetzt richtig sehe, gibt es weder auf dem Host noch auf der VM irgendwelche Firewallregeln weder nft noch iptables?

... und auch in Zukunft zu jedem Befehl dazu zu schreiben, ob der jetzt auf dem Host oder der VM ausgeführt wurde.

[Njuguna]

Der Host steht als Maschine in einem Datacenter bei München, soweit ich weiß. Provider weiß ich jetzt nicht. Hier zu

Code: Alles auswählen

host www.debianforum.de 9.9.9.9
;; communications error to 9.9.9.9#53: timed out
;; communications error to 9.9.9.9#53: timed out
;; no servers could be reached   

die passende tcpdump-Ausgabe

Code: Alles auswählen

14:18:22.175223 ens18 Out IP 192.110.55.86.56923 > 9.9.9.9.53: 55946+ A? www.debianforum.de. (36)
14:18:25.219387 ens18 Out IP 192.110.55.86.33361 > 9.9.9.9.53: 23855+ A? 3.debian.pool.ntp.org. (39)
14:18:25.219402 ens18 Out IP 192.110.55.86.33361 > 9.9.9.9.53: 55585+ AAAA? 3.debian.pool.ntp.org. (39)
14:18:27.180514 ens18 Out IP 192.110.55.86.47079 > 9.9.9.9.53: 55946+ A? www.debianforum.de. (36)

[mat6937]

Der Host steht als Maschine in einem Datacenter bei München, soweit ich weiß. Provider weiß ich jetzt nicht. Hier zu

Code: Alles auswählen

host www.debianforum.de 9.9.9.9
;; communications error to 9.9.9.9#53: timed out
;; communications error to 9.9.9.9#53: timed out
;; no servers could be reached   

Dann teste mal mit tcp statt udp, denn der tcp-Port 53 ist ja erreichbar:

Code: Alles auswählen

nc -zv 9.9.9.9 53
dns9.quad9.net [9.9.9.9] 53 (domain) open

Code: Alles auswählen

host -t a -T debianforum.de 9.9.9.9

?

[Njuguna]

Vielen Dank bis her für eure unterstützenden Beiträge. Ich habe das Problem zumindest von der Ursache her lösen können. Es ist doch ein Firewall-Thema. Nicht auf der VM selber, sondern auf dem PVE-Host, wo eine Firewall aktiv ist. Nach Deaktivieren geht auch die Namensauflösung auf der VM.

Wie jetzt die Firewall auf dem PVE-Host aus zusehen hat, das muss ich jetzt noch lösen. Das ist aber nicht Thema dieses Threads hier.

Vielen Dank an alle!

Njuguna

[heisenberg]

D. h. die Ausgaben von iptables ... bzw. nft ... waren doch falsch?

[Njuguna]

D. h. die Ausgaben von iptables ... bzw. nft ... waren doch falsch?

Nein. Denn auf einer ganz frisch installierten VM, die nur die Basispakete enthielt, kann kein Iptables konfiguriert wurden sein. Der Befehl kam ja auch erst später nach dem Tipp mit apt-cdrom auf die VM. Und wenn ich mit IPtables etwas konfiguriert hätte, ganz ehrlich, das wüsste ich dann auch.
Nein, der PVE-Host, der Host für die VMs, für sich besitzt eine Firewall. Hier macht die Namensauflösung zwar keine Probleme, aber offensichtlich für die VM schon.

[heisenberg]

Nein, der PVE-Host, der Host für die VMs, für sich besitzt eine Firewall. Hier macht die Namensauflösung zwar keine Probleme, aber offensichtlich für die VM schon.

Ja. Eben. Ich hatte vermutet, dass Du die Regeln auf dem Host auch geprüft hast. Das war dann aber wohl nicht der Fall.