Proxmox NAT: when a private VM loses Internet with the firewall active

You activate the Proxmox firewall on a node that remains accessible via Web UI and SSH. The private VM, on the other hand, can no longer access the Internet. An absent route, disabled forwarding, or a missing MASQUERADE produces the same symptom.

Before modifying a rule, check the route, NAT, and the MASQUERADE rule, then the DNS. Next, check the policy_out of the VM and the special case of conntrack zones on fwbr+. The official fix does not apply to all NAT mounts, so keep the rollback handy.

Identify the right scenario before touching the rules

The diagnosis focuses on a VM or CT placed on a private subnet. Its bridge has no direct public physical port and the guest exits through the public address of the Proxmox node with a masquerading rule.

Here are the steps to follow before any modification:

• confirm that the guest has a private address and a default route;
• confirm that the NAT exists on the node and IPv4 forwarding is active;
• confirm that the firewall is active while the node’s Web UI and SSH remain accessible.

If the VM has never had functional output, first go back to the bridge, the virtual card, and the guest interface. The article Restore a Proxmox VM network, from bridge to guest covers this branch of the diagnosis.

Read the route and the NAT before blaming the firewall

You must first understand if the packet is actually leaving the VM. In the guest, look for a default line with:

ip route
ping -c 3 1.1.1.1

An absent default route explains an impossible output. A failed ping to the test IP address does not yet prove that the firewall is blocking the VM.

On the node, check the forwarding and the POSTROUTING chain:

sysctl net.ipv4.ip_forward
iptables -t nat -S POSTROUTING

The Proxmox documentation describes masquerading for private guests with a POSTROUTING type rule. Its example uses 10.10.10.0/24, the output interface eno1, and the action MASQUERADE. Adapt these values to the existing configuration, without randomly replacing a rule.

A ip_forward=0, an absent NAT rule, or a wrong output interface move the problem outside the firewall. Configure the Proxmox firewall without losing access applies if access to the node itself is at stake.

Separate IP output, DNS, and APT update

Test the layers in this order. A failed DNS resolution does not allow concluding that the firewall is blocking.

ping -c 3 1.1.1.1
getent hosts deb.debian.org
curl -I https://deb.debian.org/

• the IP ping fails: check route, forwarding, and MASQUERADE;
• the IP ping responds but getent fails: check the guest resolver and a possible policy_out that blocks DNS;
• the resolution responds but the HTTP request fails: check the HTTPS output, the VM policy, and connectivity to the repository;
• the network output works but APT update fails: do not modify the NAT before checking the repository and the image used.

The APT test concerns Debian and Ubuntu images. For another distribution, use the appropriate package manager and repository. The expected outcome remains the same: distinguish an IP outage, resolution issue, or repository access problem.

Check the OUT policy and Proxmox logs without changing the bridge

When the route and NAT are consistent, move on to the guest’s firewall zone. Proxmox separates the Host, VM/CT, and VNet zones. A VM rule does not read the same way as a rule that protects the node.

On the node, display the status and compilation of the rules:

pve-firewall status
pve-firewall compile

Then reread the VM or CT configuration in /etc/pve/firewall/<VMID>.fw. Look for policy_out, log_level_out, and the output rules concerning DNS, NTP, or HTTP/HTTPS. Also check the Firewall Log in the Proxmox interface if logging is enabled.

pve-firewall simulate can simulate a source, a destination, a port, and a protocol. It does not simulate the kernel’s routing table. A favorable result does not therefore validate the complete NAT path.

For VM/CT rules, outgoing policies, and logs, refer also to Proxmox firewall rules for a VM or CT. Do not change the bridge to correct an outbound policy.

Check the official case of conntrack zones on fwbr+

The Proxmox documentation reports a particular case: with certain masquerade mounts and the firewall active, outgoing connections may prefer the POSTROUTING of the VM bridge over the MASQUERADE. A conntrack zone may then be necessary to avoid blocking the output.

Do not generalize this fix to all Proxmox NAT. First check for the presence of a firewall bridge in the raw table:

iptables -t raw -S PREROUTING | grep 'fwbr'

If the traffic matches this scenario, the official documentation proposes these two lines in the concerned network configuration:

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

The first line adds the zone at the network start-up. The second removes exactly the same rule at shutdown. Add them to the existing stanza in /etc/network/interfaces that bears the concerned network after confirming that the NAT works well on this path.

If the raw command shows no fwbr and the IP output already works, do not force zone 1. Instead, check for route, NAT, DNS, or the OUT policy that remains in failure.

Test the fix without breaking access to the node

Before the network reload, keep both lines in sight and plan a maintenance window if remote access may be interrupted. I recommend retaining console access or another recovery path before modifying /etc/network/interfaces.

After applying the configuration, check the raw rule first, then redo the three tests from the VM:

iptables -t raw -S PREROUTING | grep 'fwbr'
ping -c 3 1.1.1.1
getent hosts deb.debian.org
curl -I https://deb.debian.org/

The IP output must respond before judging DNS. The resolution must respond before concluding on HTTP access or APT repository. If the symptom returns, remove the two added post-up and post-down directives, then check that the CT --zone 1 line no longer appears in iptables -t raw -S PREROUTING.

Warning: pve-firewall stop actively removes Proxmox iptables rules and can leave the host unprotected. This command does not replace the diagnosis and should not serve as a normal solution for a private VM that loses its NAT output.

The verdict will be very concrete: route, forwarding, MASQUERADE, DNS, and OUT policy must be consistent before blaming the firewall. If NAT goes through fwbr+, the conntrack zone becomes a targeted fix, with a symmetrical rollback. Otherwise, revert to the bridge diagnosis or the VM/CT rules.

References: Proxmox documentation on NAT and masquerading, Proxmox VE Firewall documentation, and official pve-firewall manual.