The strangest nested-lab fault: Proxmox itself is perfectly online, yet every VM inside it is network-dead. Nothing is broken — ESXi is doing exactly what its default security policies tell it to. Here is the diagnosis and the three-setting fix.
The symptoms mislead everyone the first time. Proxmox inside ESXi pings the gateway, downloads updates, loads its web UI — clearly the network works. But a VM created inside that Proxmox gets no DHCP address, or gets one and then cannot reach anything, and pinging it from outside returns silence. The fault is not in Proxmox, not in the guest, and not in your cables. It is a security policy on the ESXi port group doing its designed job: dropping frames that appear to come from a machine the switch does not know.
The split personality is the diagnosis. ESXi knows exactly one machine on that port: the Proxmox VM, with one MAC address. Traffic from Proxmox itself uses that MAC and flows normally. But every guest inside Proxmox transmits with its own MAC address, which arrives at the ESXi virtual switch looking forged — a different machine apparently hiding behind the Proxmox VM's port. Default policy says drop. Result: the outer layer is healthy, the inner layer is mute, and every troubleshooter who starts inside the guest wastes an hour.
The vSwitch security policies exist to stop one VM impersonating another. Forged transmits: Reject drops any frame whose source MAC differs from the VM's assigned MAC — which describes every nested guest frame ever sent. MAC address changes: Reject similarly refuses traffic for MACs the guest OS claims beyond its assigned one. And Promiscuous mode: Reject prevents the port from receiving frames addressed to those other MACs, so even replies cannot find their way back. Networking textbooks use nested virtualization as the textbook example for these policies — it is the workload they were guaranteed to break.
On a distributed switch the same three policies live on the distributed port group. No reboot of Proxmox or ESXi is needed — the change bites as soon as the guest retransmits.
These settings loosen real protections, so be deliberate about where they live. Promiscuous Accept lets the port hear traffic not addressed to it; Forged Transmits Accept lets a VM send as another address. On a port group shared with production VMs, that is a genuine weakening. The clean pattern is a dedicated port group (ideally its own VLAN) for the nested lab, with the three Accepts applied there and nowhere else. The Proxmox VM moves to that port group; everything else keeps default Reject policies and full protection.
Watch the nested Proxmox video for the full build — this fix is the step that turns a half-working lab into a whole one.
▶️ Watch Full VideoMost likely the policies were edited on a different port group than the one the Proxmox VM is attached to, or the VM's adapter got reconnected to another group during editing. Check the Proxmox VM's network adapter setting and confirm it names the port group you edited. The three Accept settings themselves never break the outer VM's traffic — they only permit more, never less.
On the wrong port group, it is a real weakening: promiscuous mode exposes traffic, and forged transmits allow address spoofing. That is why the recommendation is a dedicated lab port group, ideally on its own VLAN, with the Accepts set only there. Scoped to a lab segment containing only your nested hosts, the risk is contained and the trade is a fair one.
Yes. The same three security policies — Promiscuous mode, MAC address changes and Forged transmits — exist on distributed port groups, and nested guests need all three set to Accept there too. The menu location differs slightly from a standard switch port group, but the policy names and the reasoning are identical.