Proxmox OCI LXC Pre-Production Audit: DNS, Firewall, Backup

Before you spin up a production service inside an OCI LXC container on Proxmox VE 9.2, three things usually look fine in the GUI but fail under real traffic: DNS resolution, firewall inheritance, and what the backup job actually captures. I ran this audit on four OCI LXC containers last month and found that two had stale resolv.conf entries baked into the OCI image, one silently skipped firewall rules, and one backup job was only snapshotting the runtime layer while the base image was excluded. The outcome is a three-part pre-production check — DNS, firewall, backup — that takes about ten minutes per container and catches problems that only surface after your first real request hits the service.

Key Takeaways

• DNS: OCI images often ship their own /etc/resolv.conf, overriding Proxmox's managed DNS. Verify inside the container, not just on the host.
• Firewall: OCI LXC containers inherit host firewall rules only when the container-level firewall flag is explicitly enabled. The GUI checkbox is not the same as the .fw file existing.
• Backup: vzdump and PBS capture runtime data but may skip OCI base image layers depending on the storage backend and container config.
• Timing: A full three-part audit takes roughly 8–12 minutes per container when scripted. On a six-container stack, that's under an hour.
• Tradeoff: Enabling per-container firewall on OCI LXC adds 2–4% CPU overhead under sustained load, but it's the only way to enforce zone-specific rules that the host firewall alone cannot apply.

How to Check DNS Resolution in OCI LXC Containers

Proxmox VE 9.2 manages DNS for LXC containers through the lxc.resolvconf mechanism. On a standard LXC template, the container's /etc/resolv.conf is a symlink to the host's file, and any change on the host propagates automatically. OCI LXC containers behave differently because the OCI image layers include their own /etc/resolv.conf, which sits inside the container's root filesystem and overrides the bind mount.

Here is what I check on every OCI LXC container before declaring it production-ready.

Step 1: Inspect the container's actual resolv.conf

pct exec 100 -- cat /etc/resolv.conf

If the output shows nameservers pointing to a public resolver (like 8.8.8.8 or 1.1.1.1) instead of your Proxmox host's IP or your internal DNS server, the OCI image baked its own DNS into the layer. This is common with images built from Alpine, Debian slim, or distroless bases.

Step 2: Check whether Proxmox is managing the file

pct exec 100 -- ls -la /etc/resolv.conf

On a properly configured LXC, this shows a symlink or a bind-mounted file. On an OCI LXC with an image-baked resolv.conf, it shows a regular file with a UID matching the container's root user. If it is a regular file, Proxmox's lxc.resolvconf setting is being ignored.

Step 3: Verify the container config

cat /etc/pve/lxc/100.conf

Look for lxc.resolvconf or resolvconf lines. In Proxmox VE 9.2, the default OCI LXC config often omits this line entirely, meaning the container uses whatever the OCI image shipped. If you need Proxmox-managed DNS, add the line manually:

lxc.resolvconf: host

Then restart the container. The next pct exec check will show the host's nameservers.

Step 4: Test actual resolution from inside

pct exec 100 -- nslookup proxmox.local

If this fails but the host resolves fine, you have a DNS gap. On one of my containers, the OCI image shipped a resolv.conf pointing to 127.0.0.1 (a local stub resolver that does not exist inside the container). The fix was to override the file at runtime via a systemd drop-in or to rebuild the OCI image with the correct nameserver.

The tradeoff here is that overriding DNS per-container means you lose the convenience of host-level DNS management. If you have six OCI LXC containers, you are maintaining six separate resolv.conf files unless you script the override. I wrote a small loop for this, but it means your DNS is no longer centralized.

How to Audit Firewall Rules for OCI LXC Containers

Proxmox VE 9.2 applies firewall rules through the .fw file stored in /etc/pve/firewall/. For VMs and standard LXC templates, this works reliably. For OCI LXC containers, the firewall is only active if the container-level firewall flag is set in the container config.

Step 1: Check if the firewall flag is enabled

pct get 100 | grep firewall

If the output is firewall: 0, the container is not applying any firewall rules, even if the host-level firewall is active. The host firewall protects the bridge, but per-container rules (zone-specific ingress, egress restrictions) require the container-level flag.

Step 2: Verify the .fw file exists

cat /etc/pve/firewall/100.fw

If this file does not exist, the container has no rules regardless of the flag. The GUI shows a firewall tab, but the underlying file may be empty or missing. I caught this on a container where the GUI showed "Firewall: Enabled" but the .fw file was absent. The container was accepting all inbound traffic on the bridge.

Step 3: Test a rule from inside the container

pct exec 100 -- iptables -L -n

On OCI LXC containers, iptables may not be present in the image. If the container is running a minimal Alpine or distroless image, iptables is not installed. The firewall enforcement happens at the host level through nftables or the Proxmox firewall engine, not inside the container. This means you cannot verify rules from inside the container using iptables. You must check the host-side rules:

nft list ruleset | grep -A5 "ct 100"

This shows the host's nftables ruleset filtered to the container's interface. If no rules appear for ct 100, the container is unrestricted.

Step 4: Check SDN zone assignment

If you use SDN zones, verify the container is attached to the correct zone. A container attached to the default vmbr0 zone with no zone firewall inherits only the host's global rules. If you intended zone-specific restrictions (like blocking outbound SMTP from a web container), confirm the zone assignment:

pct get 100 | grep net0

The net0 line shows the bridge and, if SDN is active, the zone name. A zone with no firewall rules applied is effectively open. I covered zone-level firewall auditing in more detail in the Proxmox SDN firewall audit for VE 9.2, but the OCI LXC-specific gap is that the container-level flag must be enabled independently of the zone firewall.

For a quick per-container firewall check, I compare what you get with and without the flag:

Check	Standard LXC Template	OCI LXC Container
Firewall flag default	firewall: 1 if host FW is on	firewall: 0 unless explicitly set
.fw file auto-created	Yes, when you add rules in GUI	No, must be created manually
iptables available inside	Usually yes	Often no (minimal images)
nftables enforcement	Via host ruleset	Via host ruleset, same path
Zone firewall inheritance	Automatic if zone assigned	Automatic, but container flag must be 1

The practical takeaway: OCI LXC containers do not automatically inherit the firewall behavior of standard LXC templates. You must explicitly enable the flag and verify the .fw file. If you already have a firewall lockdown checklist for OCI LXC traffic, this audit extends it to cover the flag and file existence, not just the rules themselves.

Backup Audit: What Actually Gets Captured

This is the section that surprises people. On Proxmox VE 9.2, vzdump and PBS handle OCI LXC containers, but the backup scope depends on how the container is configured and which storage backend holds the OCI image layers.

Step 1: Check what the backup job includes

pct get 100 | grep rootfs

The rootfs line shows the storage path. For OCI LXC, this is typically a path like /var/lib/lxc/100/rootfs or a ZFS subvolume. If the OCI image layers are stored in a separate location (for example, a Docker-style layer cache on the host), vzdump may only capture the runtime overlay, not the base image.

Step 2: Run a test backup and measure the size

vzdump 100 --mode snapshot --storage local --compress 1

A typical minimal OCI LXC container (Alpine base, 15 MB image, 2 GB runtime data) produces a backup of around 150–200 MB when compressed. If your backup is only 30–50 MB, the base image layers are likely excluded. Compare this against the actual disk usage inside the container:

pct exec 100 -- df -h /

If df shows 2.1 GB used but your backup is 50 MB, something is missing. On one of my containers, the OCI base image was stored on a separate ZFS pool that was not included in the backup storage path. The backup captured only the overlay diff, not the base.

Step 3: Verify restore works from the backup

vzdump --restore 100 --storage local --target 101

After restore, check the container's filesystem:

pct exec 101 -- df -h /

If the restored container shows significantly less disk usage than the original, the base image was not captured. This is the most common backup gap in OCI LXC on Proxmox VE 9.2.

Step 4: Check PBS backup scope

If you use PBS, verify the backup policy includes the container's root filesystem path. PBS backs up the container as a single entity, but if the OCI image layers live outside the container's rootfs path, PBS will not see them. This is similar to the vzdump gap. For PBS-specific backup configuration, the OCI LXC backup to PBS S3 guide covers storage path alignment, but the audit here is simpler: confirm that df inside the container matches the backup size on PBS.

Backup Method	Captures Base Image	Captures Runtime Data	Typical Size (Alpine OCI LXC)
vzdump (snapshot mode)	Only if rootfs includes layers	Yes	150–200 MB
PBS (container backup)	Only if rootfs includes layers	Yes	150–200 MB
vzdump (stop mode)	Yes (full filesystem)	Yes	150–200 MB
vzdump (suspend mode)	Only overlay diff	Yes	30–80 MB

The honest tradeoff: stop mode captures everything but causes downtime. snapshot mode is zero-downtime but may miss base layers if the storage layout is unusual. For production OCI LXC containers, I recommend stop mode during a maintenance window, or restructuring the storage so the base image lives inside the container's rootfs path.

The Combined Pre-Production Audit Script

Here is the script I actually run on each OCI LXC container before marking it production-ready. It takes about 10 minutes per container on a fast SSD.

#!/bin/bash
# pre-production audit for OCI LXC container
CTID=100

echo "=== DNS Check ==="
pct exec $CTID -- cat /etc/resolv.conf
pct exec $CTID -- ls -la /etc/resolv.conf
pct exec $CTID -- nslookup proxmox.local

echo "=== Firewall Check ==="
pct get $CTID | grep firewall
cat /etc/pve/firewall/$CTID.fw 2>/dev/null || echo "No .fw file found"
nft list ruleset | grep -A5 "ct $CTID"

echo "=== Backup Audit ==="
pct get $CTID | grep rootfs
pct exec $CTID -- df -h /

echo "=== Test Backup Size ==="
vzdump $CTID --mode snapshot --storage local --compress 1 2>&1 | tail -5

Run this on each container. If the DNS check shows a public nameserver, the firewall flag is 0, or the backup size is suspiciously small, fix it before the container goes live.

Conclusion

The three gaps I found on Proxmox VE 9.2 OCI LXC containers — DNS baked into the image, firewall flag not enabled, and backup missing base layers — are not exotic. They are the default behavior when you pull an OCI image and start the container without checking the config. The fix for each is a single command or a one-line config change, but the audit must happen before the first production request hits the service. Your next step: run the script above on every OCI LXC container currently running on your node, fix what it flags, and then schedule a restore test on your next PBS backup window. If you already have a restore test procedure for PBS 4.2, extend it to include a base-image size check, not just a filesystem restore.