Firewallregels Proxmox voor een VM of een CT

Julien Macé Published on 18 september 2026 at 8 h 13 min Updated on 19 september 2026 at 11 h 48 min 8 min read

Règles pare feu Proxmox pour une VM et un CT

Je VM web reageert nog, maar je arriveert op het moment dat een te brede regel een onnodige dienst kan openen of SSH kan afsluiten.

De Proxmox-firewall is al actief en de vraag wordt specifiek: moet je schrijven op het niveau van de VM, de node of het gast-OS?

Voor een VM of een container, begin bij de gast en zijn werkelijke stromen.

Lees de opties van net0, bouw de regels IN, beslis over het lot van OUT, en factoriseer alleen de regels die een groep verdienen. De Proxmox-controles en de applicatietest blijven gescheiden van de host-firewall.

De VM/CT-regels van Proxmox moeten afkomstig zijn van de werkelijke stromen van de gast en mogen alleen worden gefactoriseerd wanneer ze herbruikbaar zijn.

Stel het doel vast voordat je de eerste regel schrijft

Identificeer de VMID, de virtuele interface, het adres van de gast en de werkelijk blootgestelde diensten. Een Debian VM die HTTP en HTTPS levert, heeft niet dezelfde invoeren als een beheerscontainer die toegankelijk is vanaf een bastion.

noteer de werkelijke VMID en de net0 interface;
lijst de inkomende poorten en toegestane bronnen;
houd een console of administratieve toegang tot de host;
controleer of de Datacenter/Node-firewall al is behandeld.

De zones zijn niet onderling vervangbaar. Datacenter is met name bedoeld voor herbruikbare bouwstenen, Node betreft de host, en VM/CT filtert de stromen naar of van de gast.

De Debian-firewall blijft een aparte laag. De officiële Proxmox VE-documentatie beschrijft deze scheiding evenals de richtingen IN, OUT en FORWARD.

Als de firewall van de node nog niet is ingeschakeld of als je bang bent om Web UI of SSH te verliezen, stop dan voordat je VM-regels toevoegt en raadpleeg de voorzichtige activatie van de Proxmox-firewall zonder toegang te verliezen.

Het vergrendelen van de host blijft hier buiten de reikwijdte.

Lees de opties van de VM en zijn interface

Voordat je schrijft, herlees de configuratie vanaf de Proxmox-node. Vervang <VMID> door het numerieke identificatienummer van je VM:

qm config <VMID> --current

Controleer vervolgens in de configuratie van de VM de enable, policy_in, policy_out, log_level_in, log_level_out en ipfilter.

Elke interface heeft ook zijn eigen firewall-indicator. De algemene optie van de VM is niet voldoende als de vlag van net0 is gedeactiveerd.

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
log_level_in: nolog
log_level_out: nolog
ipfilter: 1

Dit blok illustreert een restrictieve invoer en een nog permissieve uitvoer. Het is geen bestand dat zomaar kan worden gekopieerd: pas de waarden aan naar jouw VM en controleer vervolgens de gegenereerde configuratie.

ipfilter dient vooral om IP-adresvervalsing op de interface te beperken, niet om een HTTP- of SSH-allowlist te maken.

Toestaan van werkelijk noodzakelijke inkomende stromen

Begin met de invoer. Voor een web-VM komt SSH meestal van een bastion of een beheersnetwerk.

De poorten 80 en 443 komen van de reverse proxy of een openbare bron die door de architectuur is voorzien. Een toegangsregel moet dus het protocol, de poort, de bron en de interface omschrijven wanneer deze elementen bekend zijn.

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0
IN ACCEPT -p tcp -dport 80 -source +reverse_proxy -i net0
IN ACCEPT -p tcp -dport 443 -source +reverse_proxy -i net0

In dit voorbeeld zijn +admins en +reverse_proxy afzonderlijk gedefinieerde IPSet.

Het documentadres 192.0.2.0/24 kan een netwerk in een voorbeeld of documentatie illustreren, maar het vertegenwoordigt niet jouw echte netwerk. Vervang het door jouw gecontroleerde bronnen, zonder een adres uit een tutorial te kopiëren.

Plaats specifieke toestemmingen vóór een DROP of REJECT beleid. Een globale weigering te vroeg toegevoegd kan de nuttige regel maskeren.

Het verandert een eenvoudige vergissing in een SSH-onderbreking. Lees de configuratie door voordat je deze verhardt en houd een hostconsole bereikbaar.

Bepaal de OUT-beleid voordat je het streng maakt

Een toegestane uitvoer laat DNS, NTP, updates, APT-repositories, monitoring of externe API’s werken zolang de andere lagen ze filteren.

Een restrictieve uitvoer vereist een nauwkeurige inventaris: het eerste geblokkeerde DNS-pakket is voldoende om te denken dat de VM of zijn bridge is mislukt.

Stroom van de VM	Richting	Voorbeeld	Risico onder DROP
Beheer SSH	IN	`+admins` naar 22/tcp	Toegang geweigerd als de bron niet is vermeld.
HTTP/HTTPS	IN	`+reverse_proxy` naar 80/443	De webdienst wordt onbereikbaar.
DNS-resolutie	OUT	UDP/TCP 53 naar de resolver	APT en naamoproepen mislukken.
Systeemtijd	OUT	UDP 123 naar de NTP-bron	De klok verschuift als geen andere mechanisme het overneemt.
Repositories en API’s	OUT	TCP 80/443 naar de voorziene bestemmingen	Updates en monitoring kunnen stoppen.

Ik geef de voorkeur aan policy_out: ACCEPT tijdens de inventaris, en schakel vervolgens over naar DROP met de gedocumenteerde uitvoeren één voor één.

Deze keuze beschermt de beschikbaarheid van de dienst tijdens de bouw. Het vervangt geen uitvoerend beleid als jouw omgeving daadwerkelijk een white-list vereist.

[OPTIONS]
policy_out: DROP

[RULES]
OUT ACCEPT -p udp -dport 53 -dest dns_interne
OUT ACCEPT -p tcp -dport 53 -dest dns_interne
OUT ACCEPT -p udp -dport 123 -dest ntp_interne
OUT ACCEPT -p tcp -dport 80 -dest depots
OUT ACCEPT -p tcp -dport 443 -dest depots

De namen dns_interne, ntp_interne en depots moeten naar jouw werkelijke adressen of groepen verwijzen. De syntaxis van meerdere poorten en aliassen moet worden herlezen met de geïnstalleerde versie van Proxmox voordat deze wordt toegepast.

Factoriseren van herhaalbare regels met een Security Group

Een Security Group wordt nuttig wanneer meerdere VM’s of containers dezelfde functie delen.

Proxmox definieert deze op cluster-niveau, en de configuratie van elke gast roept deze aan in zijn [RULES] sectie. De groep is niet van toepassing op een VM totdat je deze in zijn regels hebt ingevoegd.

# /etc/pve/firewall/cluster.fw
[group webserver]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443

# /etc/pve/firewall/<VMID>.fw
[RULES]
GROUP webserver

Houd in de groep de regels die werkelijk gemeenschappelijk zijn. Een uitzondering die specifiek voor een VM is, blijft in /etc/pve/firewall/<VMID>.fw. Deze scheiding voorkomt dat je alle gasten moet aanpassen om een enkele beheerspoort te corrigeren.

Geef de bronnen namen met IPSet en alias

De IPSet groepeert adressen of netwerken; de aliassen geven een leesbare naam aan een adres of netwerk.

De regels kunnen ze gebruiken als bron of bestemming. Zo herlees je +admins of dns_interne zonder een reeks IP’s elke keer te moeten interpreteren.

# /etc/pve/firewall/cluster.fw
[ALIASES]
dns_interne 192.0.2.53

[IPSET admins]
192.0.2.10

[IPSET reverse_proxy]
192.0.2.20
192.0.2.21

De adressen 192.0.2.10, 192.0.2.20 en 192.0.2.21 zijn placeholders voor documentatie. Een IPSet wordt aangesproken met het voorvoegsel +, bijvoorbeeld -source +admins.

Zonder dit voorvoegsel leest Proxmox de naam als een adres of alias en komt de regel niet overeen met de intentie.

Verwar ipfilter-net0 niet met een applicatieve allowlist.

Deze IPSet gekoppeld aan de interface helpt het vervalsen van het bronadres te voorkomen. Het beslist niet wie de poort 443 van jouw applicatie mag openen.

Lees de volgorde van regels voordat je het beleid verhardt

Een groepsregel of lokale regel heeft alleen effect als deze op de verwachte plaats wordt gelezen. Plaats de specifieke overeenkomsten vóór de algemene weigering en herlees de configuratie na elke wijziging.

Geweest leesvolgorde	Voorbeeld	Risico als te laag geplaatst
1. Specifieke bron en poort	SSH van `+admins` naar 22/tcp	Het bastion wordt geblokkeerd door het beleid.
2. Herbruikbare groep	`GROUP webserver`	De webpoorten blijven gesloten op deze VM.
3. Gedocumenteerde uitvoer	DNS, NTP, repositories	De dienst start en verliest vervolgens zijn afhankelijkheden.
4. Standaardbeleid	`DROP` of `REJECT`	Elke vergeten stroom valt hier onder.

De officiële documentatie beschrijft de syntaxis IN/OUT, de opties --source, --dest, --dport en --iface, evenals het invoegen van een Security Group.

Gebruik de vorm die overeenkomt met jouw versie en controleer de gecompileerde configuratie in plaats van aan te nemen dat de groep actief is.

Activeer een gerichte log tijdens de test

De Proxmox-logging is standaard uitgeschakeld voor gefilterd verkeer. De opties log_level_in en log_level_out activeren de standaardlogs van de VM/CT, zichtbaar in Firewall → Log.

Het niveau dat aan het log wordt toegevoegd, helpt om het pakket te identificeren: het verhoogt niet automatisch het aantal gelogde pakketten.

[OPTIONS]
log_level_in: info
log_level_out: nolog

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0 -log info

Activeer het niveau alleen tijdens de test van de stroom die je interesseert en zet nolog weer terug als het volume te luid wordt.

Een permanente globale logging bemoeilijkt het lezen van echte weigeringen en verhoogt het operationele lawaai.

Let op: een leeg log bewijst niet dat een dienst werkt. Je moet nog steeds de regel, het antwoord van de applicatie en het netwerkpad vanuit de werkelijke bron controleren.

Compileren, testen en een terugval plannen

Begin met het lezen van de status van de firewall op de node:

pve-firewall status
pve-firewall compile

pve-firewall status leest en compileert de regels: een syntaxiswaarschuwing blijft een probleem dat gecorrigeerd moet worden voordat het netwerk wordt getest.

pve-firewall compile stelt je in staat om de gegenereerde configuratie te bekijken.

De officiële documentatie van pve-firewall beschrijft ook pve-firewall simulate, wat kan helpen om een bron, bestemming, poort en protocol te simuleren, maar bewijst noch de routering van de kernel noch het functioneren van de applicatie.

De laatste controle moet beginnen vanuit de toegestane bron en vervolgens vanuit een bron die moet worden geweigerd als je deze zonder risico kunt gebruiken:

SSH vanaf het verwachte beheers-IP met ssh -v;
HTTP of HTTPS vanaf de reverse proxy met curl -I https://<IP_VM>;
DNS, NTP en APT vanaf de VM als policy_out restrictief is;
lees het Proxmox-log tijdens het testvenster en keer dan terug naar nolog.

Present deze opdrachten niet als een test die al is uitgevoerd: ze vormen jouw validatieprotocol.

Een verwachte uitkomst is een toegestane verbinding die reageert, een verboden stroom die faalt, en een trace die consistent is met de beoordeelde regel.

Als een regel de VM afsluit, verwijder die regel of deactiveer tijdelijk de firewall van deze VM/CT.

Zet policy_out: ACCEPT weer terug als DNS, NTP of de updates niet functioneren.

Gebruik pve-firewall stop niet als een normale terugval: dit commando verwijdert de Proxmox-regels van de host en kan de server zonder bescherming achterlaten.

Houd de grenzen zichtbaar

Een VM zonder IP-adres, een ontbrekende bridge of een slecht doorgegeven VLAN wordt niet gerepareerd met een firewallregel.

Als de regel juist lijkt, maar de gast geen IP heeft, ga dan verder met het netwerkdiagnose van een Proxmox VM, van de bridge naar de gast: herstel het netwerk van de VM.

Voor een probleem aan de hostzijde behandelt de gids maak een Proxmox bridge zonder toegang tot de server te verliezen de juiste laag.

De nftables backend proxmox-firewall blijft gemarkeerd als tech preview in de PVE 9.2.11 documentatie.

De bovenstaande voorbeelden blijven gefocust op de standaard backend pve-firewall. Als jouw omgeving IPv6 gebruikt, controleer dan ook NDP en de IPv6-adressen in plaats van alleen te concluderen op basis van een IPv4-test.

Julien Macé