HAOS Supervisor Docker IP making WAN calls on Proxmox setup

Installation Home Assistant OS
1

Hi all,

I’ve recently migrated my Home Assistant setup from a Raspberry Pi to Home Assistant OS (HAOS) running as a VM on Proxmox. My network configuration involves a specific VLAN for this VM, with a firewall on the VLAN strictly controlling outbound access.

Disclaimer: this text was improved by an LLM, sorry if it sounds like AI.

The Problem: Internal Docker IP appearing on External Firewall

I’m consistently observing blocked outbound connections in my firewall logs originating from 172.30.232.2 (the Home Assistant Supervisor’s internal Docker IP) destined for various WAN IPs (e.g., Cloudflare IPs). This is unexpected, as Docker’s default bridge networking should perform NAT, meaning my external firewall should only see the HAOS VM’s primary 10.*.*.X IP for any outbound traffic.

Sample firewall log: From: 172.30.232.2:36572 To: 172.67.68.90:443 Blocked

My goal is to restrict WAN access, only allowing necessary connections. However, granting access to 172.30.232.2 on my firewall feels like a workaround for an underlying NAT issue and carries risks (potential IP collisions with future internal Docker setups, broader exposure if other internal 172.x.x.x IPs start leaking).

My Debugging & Observations:

  • The Supervisor’s internal network is confirmed to be in the 172.30.232.0/23 range.
  • Upon inspecting the iptables -t nat -L POSTROUTING -n -v on the HAOS VM, I found the following relevant MASQUERADE rule:
pkts: 7
bytes: 528
target: MASQUERADE
prot: all
opt: --
in: *
out: !docker0
source: 172.30.232.0/23
destination: 0.0.0.0/0
  • I also noted the Supervisor primarily uses a Docker bridge network named hassio (or similar) internally, not the default docker0. This hassio bridge is where the 172.30.232.0/23 subnet is actually configured.

My Hypothesis:

The out: !docker0 condition in the MASQUERADE rule might be the culprit. Since the Supervisor’s traffic is originating from the hassio bridge (which is distinct from docker0), this specific NAT rule might not be applying correctly to traffic leaving the hassio bridge for the VM’s external interface. This would explain why the 172.30.232.2 source IP is “leaking” directly to my firewall.

Core Questions:

  1. What is the Supervisor primarily trying to call out to on the WAN? (e.g., update checks). Knowing this would help narrow down necessary firewall exceptions.
  2. Why is the 172.30.232.2 internal Docker IP appearing on my external firewall, rather than being NAT’d to the HAOS VM’s 10.*.*.X IP? Is my iptables hypothesis correct regarding the !docker0 vs. !hassio bridge name, or are there other common misconfigurations in HAOS or Proxmox that could cause this NAT bypass?

My Desired Outcome:

I want all outbound traffic from the HAOS VM, including from the Supervisor and other internal Docker containers, to be correctly NAT’d through the VM’s main 10.*.*.X IP address. This would allow me to manage firewall rules centrally based on the single, expected 10.*.*.X source IP, without needing to allowlist internal 172.x.x.x subnets.

Any insights or guidance on resolving this NAT issue within HAOS would be greatly appreciated!