VM Kein Internet nach Installation

Lucas1232

New Member
Jun 16, 2024
10
1
3
Hallo zusammen,
ich arbeite seit ein paar Jahren mit basic linux und habe nun entschieden meine Kenntnisse zu erweitern.

Mein Setup:
Ich habe einen Strato VPS Linux VC8-32 mit einer public IP darauf Debian 12

Mein Plan:
Ich würde gerne proxmox installieren, damit ich hierauf verschiedene Dienste unabhängig von einander laufen lassen kann (Plesk, Evtl einen Gameserver Manager wie z.b. Pelican o. Pterodactyl). Ich vermute, dass ich mit NAT - IpTables arbeiten muss, da ich nur eine public IP Adresse habe.

Mein Fortschritt:
Ich habe Proxmox ans laufen gekriegt. Anschließend die Network Config von Proxmox mit NAT kopiert von https://pve.proxmox.com/wiki/Network_Configuration

/etc/network/interfaces:

auto lo
iface lo inet loopback

iface ens6 inet manual

auto eno1
#real IP address
iface eno1 inet static
address 85.***.***.**/24
gateway 85.***.***.1

auto vmbr0
#private sub network
iface vmbr0 inet static
address 10.10.10.1/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 '10.10.10.0/24' -o eno1 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE

post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1



Ich habe nun eine VM mit Ubuntu 24.04 erstellt

hierauf habe ich cloud-init disabled und in die /etc/netplan/50-cloud-init-yaml angehängten screenshot konfiguriert

Somit ist die IP der VM nun 10.10.10.2. Über ping kann ich 10.10.10.1 erreichen, sowie vom Proxmox host auch 10.10.10.2 erreichen

Mein Problem:
Die VM hat keinen Internet zugriff. Ich sitze nun seit 4 Tagen an dem Problem, habe Proxmox ca 5 mal neu installiert und das gesamte Internet, sowie dieses Forum durchsucht. Auch ChatGPT war keine Große hilfe. Es tut mir leid, ich vermute, dass ich trotz der ganzen Posts den richtigen Ansatz nicht erkenne.

Internet zugriff habe ich über ping 1.1.1.1 sowie sudo apt update geprüft.

LG Lucas
 

Attachments

  • brave_3hImOHhcLU.png
    brave_3hImOHhcLU.png
    3.8 KB · Views: 16
Hallo Lucas, auf dem ersten Blick sieht alles korrekt aus, die Vermutung liegt aber nahe, dass das Masquerading nicht richtig greift.

Zur Sicherheit ueberpruef mal ob die Regel in der Firewall gesetzt wurde
Code:
iptables -t nat -L

Falls nicht, am besten mal ein ifdown vmbr0 und ifup vmbr0 durchfuehren (ein reboot tuts auch)

danach wuerde ich von deiner VM einen ping auf 1.1.1.1 laufen lassen und am Proxmox Host einen tcpdump auf dein WAN Interface zur 1.1.1.1 laufen lassen:
Code:
tcpdump -i eno1 host 1.1.1.1

Wenn die Masquerading Regel greift, sollte hier nun NICHT die IP-Adresse von deiner VM aufscheinen, also waere folgendes falsch:
Code:
IP 10.10.10.2 > one.one.one.one: ICMP echo request
 
Hallo Kevin, danke für deine Antwort. Ich kann leider nicht genau beurteilen ob der Output passt, denke aber schon?:

Code:
root@proxmox:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         


Chain INPUT (policy ACCEPT)
target     prot opt source               destination         


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         


Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
ts-postrouting  all  --  anywhere             anywhere           
MASQUERADE  all  --  10.10.10.0/24        anywhere           


Chain ts-postrouting (1 references)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere             mark match 0x40000/0xff0000


Beim Ping taucht die IP im TCP Dump auf.

Code:
10:36:34.732758 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 3880, seq 1, length 64
10:36:35.776209 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 3880, seq 2, length 64
10:36:36.800210 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 3880, seq 3, length 64
 
Also der TCP Dump zeigt eben die falsche IP-Adresse an, am externen Interface muesste ja die externe IP-Adresse angezeigt werden. Aktuell werden deine Pakete von der VMware mit einer internen Source IP an 1.1.1.1 geschickt, also gehen die Antwortpakete ins Nirvana.

Interessant waere, woher deine ts-postrouting Regel her kommt, fuer mich sieht das aktuell so aus als wuerde die zuerst matchen und daher greift die masquerading Regel gar nicht.
 
Ich habe einiges an selbständigem Debugging versucht und kann deshalb nicht genau sagen, woher welche Config kommt, wenn es hilft kann ich alles nochmal neu installieren. Es sollte bei der Instanz aber nicht viel vom default verändert sein. Macht es sinn die IP tables zurückzusetzen?
 
Ja wenn du die IPtables zuruecksetzt und dann das networking neu startest, sollte da nur noch die Masquerading Rule da sein. Danach wuerde ich nochmal einen tcpdump machen um nachzusehen ob sich was geaendert hat.
 
Habe die IP tables wie hier zurückgesetzt https://www.cyberciti.biz/tips/linux-iptables-how-to-flush-all-rules.html

Code:
root@proxmox:~# ./fw.stop
Stopping IPv4 firewall and allowing everyone...
root@proxmox:~# iptables -L -n -v
Chain INPUT (policy ACCEPT 189 packets, 29081 bytes)
 pkts bytes target     prot opt in     out     source               destination         


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


Chain OUTPUT (policy ACCEPT 205 packets, 31335 bytes)
 pkts bytes target     prot opt in     out     source               destination         
root@proxmox:~# systemctl reboot
root@proxmox:~# System is going down. Unprivileged users are not permitted to log in anymore. For technical details, see pam_nologin(8).

Anschließend die VM gestartet und einen ping gemacht
Code:
root@proxmox:~# tcpdump -i ens6 host 1.1.1.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:18:15.143981 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 971, seq 1, length 64
11:18:16.175344 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 971, seq 2, length 64
11:18:17.199363 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 971, seq 3, length 64

und die IP Tables wurden wie vorher eingestellt

Code:
root@proxmox:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         


Chain INPUT (policy ACCEPT)
target     prot opt source               destination         


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         


Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
ts-postrouting  all  --  anywhere             anywhere           
MASQUERADE  all  --  10.10.10.0/24        anywhere           


Chain ts-postrouting (1 references)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere             mark match 0x40000/0xff0000
 
Ok hab kurz recherchiert, da ist anscheinend tailscale installiert. Leider kenne ich mich damit zu wenig aus um jetzt genauer weiterhelfen zu koennen. Es kann sein, dass ich tailscale hier in den traffic einmischt (die NAT Regel sieht eigentlich fuer mich in Ordnung aus, in deiner urspruenglichen Beschreibung haette sie hier nur nichts verloren und ist damit durchaus ein Indiz, dass sich hier etwas anderes einmischt.)

Wenn du trotz Tailscale deinstallation weiterhin auf den Server kommst, wuerde ich dir empfehlen Tailscale vorerst wegzulassen und dann in einen eigenen Container/VM zu installieren. Rein Technisch zwar absolut nicht notwendig, aber wenn das derzeit die Ursache fuer das Problem ist, ersparst du dir sicher ein paar Kopfschmerzen in der Zukunft und die Netzkonfiguration ist etwas uebersichtlicher.
 
Hey, vielen Dank für deine Arbeit. Ich habe Tailscale entfernt, es ist auch aus den IPTables raus. Nur leider ohne Erfolg.

Code:
root@proxmox:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination        


Chain INPUT (policy ACCEPT)
target     prot opt source               destination        


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        


Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination        
MASQUERADE  all  --  10.10.10.0/24        anywhere          
root@proxmox:~# tcpdump -i ens6 host 1.1.1.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:08:38.015708 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 975, seq 7, length 64
13:08:39.039604 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 975, seq 8, length 64
13:08:40.063666 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 975, seq 9, length 64
13:08:41.087676 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 975, seq 10, length 64
13:08:42.111638 IP 10.10.10.2 > one.one.one.one: ICMP echo request, id 975, seq 11, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

Falls das hilft:

Code:
root@proxmox:~# 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: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02******** brd ff:ff:ff:ff:ff:ff
    altname enp0s6
    inet 85.***.***.**/32 metric 100 scope global dynamic ens6
       valid_lft 388sec preferred_lft 388sec
    inet6 2a***::1/128 scope global dynamic noprefixroute
       valid_lft 3791sec preferred_lft 2791sec
    inet6 fe***/64 scope link
       valid_lft forever preferred_lft forever
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 96******:ab brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.1/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe***/64 scope link
       valid_lft forever preferred_lft forever
4: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 96****** brd ff:ff:ff:ff:ff:ff
 
Last edited:
Kein Problem, wollte mir NAT ohnehin einrichten und dein Thread hat mich gleich dazu bewegt es mal einzurichten :)

Auf jeden Fall sehr seltsam, den einzigen Unterschied den ich zu meinem Setup erkenne, ist das mein WAN Interface auf einer Bridge liegt (aber auch nur weil es bei der Erstinstallation so war), das sollte aber keinen Unterschied machen, das Beispiel im Wiki ist ja auch mit dem "normalen" Interface.

Der Blog erklaert ganz gut wie man das Problem weiter tracen kann:
https://web.archive.org/web/20220610151210/https://blog.lobraun.de/2019/05/19/prox/

Anbei mal wie das bei mir aussieht, vielleicht hilft dir das ja weiter:
(vmbr0 ist mein WAN Interface, vmbr2 mein LAN)

Code:
2:0 6 - 17/Jun/2024:16:22:58 +0200 TRACE: raw:PREROUTING:policy:4 IN=vmbr2 MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=172.16.16.2 DST=1.1.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=57275 DF PROTO=ICMP TYPE=8 CODE=0 ID=14055 SEQ=1
3:0 6 - 17/Jun/2024:16:22:58 +0200 TRACE: nat:PREROUTING:policy:1 IN=vmbr2 MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=172.16.16.2 DST=1.1.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=57275 DF PROTO=ICMP TYPE=8 CODE=0 ID=14055 SEQ=1
4:0 6 - 17/Jun/2024:16:22:58 +0200 TRACE: filter:FORWARD:policy:1 IN=vmbr2 OUT=vmbr0 MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=172.16.16.2 DST=1.1.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=57275 DF PROTO=ICMP TYPE=8 CODE=0 ID=14055 SEQ=1
5:0 6 - 17/Jun/2024:16:22:58 +0200 TRACE: nat:POSTROUTING:rule:1 IN=vmbr2 OUT=vmbr0 MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=172.16.16.2 DST=1.1.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=57275 DF PROTO=ICMP TYPE=8 CODE=0 ID=14055 SEQ=1
 
  • Like
Reactions: Lucas1232

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!