Proxmox VE - ausgehender Traffic

mcmaster

New Member
Aug 13, 2026
2
0
1
Hallo In die Runde,

in unserem Unternehmen möchten gerne den Einsatz von Proxmox als Virtualisierungslösung evaluieren.

Im Zuge der Evaluierung kam es zu einer Installation in unserer Testumgebung. Vorgreifend auf eine interne Softwareabnahme wurde der Traffic der Software mitgeschnitten und analysiert.

Hierbei sind uns verschiedene Verbindungsversuche zu Zielen im www aufgefallen. Im Wesentlichen die Protokolle NTP, DNS, http und https. Genaue Zieladressen kann ich bei Bedarf nachliefern.

Gibt es eine Möglichkeit, eine Anleitung, um sämtlichen Traffic ins www zu unterbinden? Sicher, die Perimeter-Firewall bzw. den Proxy "zu machen" ist der einfachste Weg. Unsere Softwareabnahme setzt allerdings vorraus, dass man im Produkt diese Konfiguration vornehmen kann.

Grüße aus Mainz
 
  1. NDP → default config von chrony holt sich die Zeit aus dem Internet, kann geändert werden falls es interne Zeitserver gibt.
  2. DNS → sollte selbsterklärend sein
  3. HTTP & HTTPS → sollten Zugriffe auf die verschiedenen package mirror sein wenn nach neuen Updates gesucht wird (Debian und Proxmox Server)
Update Repositories können umkonfiguriert werden. Für einen Produktivbetrieb, für den die Proxmox Enterprise Repositories verwendet werden, gibt es den Proxmox Offline Mirror (POM) um sich einen Snapshot zu ziehen den man dann den Airgapped Hosts zur Verfügung stellt. Weiters lassen sich darüber auch die Subscription Keys aktivieren, ohne dass die Hosts selbst eine Verbindung zum Keyserver aufbauen müssen.
 
Last edited:
  • Like
Reactions: mcmaster
Das ist Standard-Debian-Kram plus apt, Telemetrie hat PVE keine. NTP läuft über chrony (seit PVE 7 Standard), Config in /etc/chrony/chrony.conf, da einfach euren internen Zeitserver statt dem Debian-Pool rein. DNS stellst du am Node unter System > DNS auf euren Resolver um. HTTP/HTTPS ist apt gegen die Proxmox-Repos plus der Subscription-Check, der täglich über pve-daily-update.timer ausgelöst wird. Wenn ihr einen internen Mirror habt: Node > Updates > Repositories anpassen, sonst könnt ihr unter Datacenter > Optionen einen HTTP-Proxy eintragen, den nutzen apt und der Subscription-Check.

Für "hart dicht" nimmst du die PVE-eigene Firewall: unter Node > Firewall > Optionen die Output-Policy auf DROP (policy_out: DROP in /etc/pve/nodes/<node>/host.fw). Damit ist die Sperre im Produkt selbst konfiguriert, das erfüllt euer Abnahmekriterium. Vorher aber unbedingt Ausnahmen für Mgmt-Netz, internen DNS/NTP und bei Cluster für Corosync anlegen, sonst sperrst du dir die Node weg. Auf einer Testkiste mit IPMI/Konsole durchspielen, nicht blind aktivieren.

Poste ruhig mal die Zieladressen, dann kann man die einzeln zuordnen. Meist ist noch *.debian.org (Security-Updates) und ggf. der CDN vom no-subscription-Repo dabei.
 
  • Like
Reactions: mcmaster
Hallo Ihr zwei,

vielen Dank für eure schnellen Antworten, damit kann ich auf jeden Fall in eine zweite Testrunde starten.
Zu den IPs: NTP und DNS habe ich jetzt mal weg gelassen. Nur http und https:
45.144.208.36 Österreich, IPAX GmbH Hosting --> Ich nehme an die Subskriptonabfrage
188.114.96.3 Cloudflare R-Proxy oder CDN Knoten
188.114.97.3 Cloudflare R-Proxy oder CDN Knoten
146.75.118.132 Fastly - CDN Knoten --> Debian Repositories
151.101.130.132 Fastly - CDN Knoten --> Debian Repositories
151.101.194.132 Fastly - CDN Knoten --> Debian Repositories
151.101.66.132 Fastly - CDN Knoten --> Debian Repositories
151.101.2.132 Fastly - CDN Knoten --> Debian Repositories
146.75.118.132 Fastly - CDN Knoten ---> Debian Repositories
185.218.221.167 Australien/Sidney bzw. Hamburg (ISP Cyberzone SA) auch Subskriotion?