ESXi Guest VPN: Routing or Bridging, Decide Before Port Group
A routed TUN needs return routes; a bridged TAP needs layer-2 reach and a wider port-group policy. Settle the role before you widen promiscuous mode.
Route the packets or extend the Ethernet domain: the port group change is downstream of that choice. From an application holding a private address the results can look identical, while the hypervisor requirements are nothing alike. That is why the port group gets widened first and the design question gets answered second, usually after a broadcast storm. Work through these checks in order and stop while the requirement is still vague, because no port-group setting fixes a design that was never chosen.
The decision belongs to the service's owner; the hypervisor configuration should implement it, not accidentally determine it.
Check what the far end actually needs
List the services the remote clients must reach and the protocols they use. If the list is a handful of TCP services on known prefixes, routing covers it. If something genuinely needs layer-2 adjacency — broadcast-dependent discovery, non-IP protocols, a device that will not accept a gateway — routing cannot fake it and you should say so early. Be honest about the non-IP entries on that list, because they are where a routing design quietly fails a week later.
Then check the client pool. A routed design needs an address range and an explicit return route on the far side; a bridged design needs the extended Ethernet domain to own address allocation and isolation. Whichever you pick, somebody outside this VM has to agree to it.
What each design asks of the virtual network
The two designs differ in what the virtual network must tolerate, and the table is the shortest way to see it:
| Design | Guest-side role | What the virtual network must accommodate | Failure mode if you pick wrong |
|---|---|---|---|
| Routed TUN | Router between separate prefixes | A routed client pool plus return paths on the far side | Clients reach the gateway and never reach the service behind it |
| Bridged TAP | Layer-2 bridge for the clients that join | Extra Ethernet identities, broadcast traffic and VLAN rules | The vSwitch drops frames, or the design needs promiscuous mode nobody approved |
Routing keeps the broadcast domain where it is and gives you a natural place to limit which services cross the gateway. Bridging moves the boundary: the clients become participants in the extended Ethernet domain, and address allocation, isolation and any layer-2 policy now apply to them. Write the chosen row into the change record. A sentence like "routed TUN, client pool 10.90.0.0/24, return route on the core" prevents the next engineer from re-litigating the design from the port-group settings.
Who should be allowed to see whose frames
Ask the platform owner one question before touching the port group: does the design require this VM to receive frames addressed to other participants? If the answer is no, nothing in this section applies, because a routed TUN never needs that visibility. If the answer is yes, the Broadcom promiscuous-mode guidance is the reading that matters: it sets out how much more of the vSwitch the VM can see and recommends confining that policy to one port group.
Treat that as a requirement check, not a permission slip. Turn the setting on for one dedicated attachment when the bridging need is written down, and leave it off everywhere else. A broad VLAN trunk copied from another bridge example is the part nobody remembers to remove, and a single-VLAN design should stay single-VLAN.
Record which port group changed and why, in the same place you recorded the design row. That pairing is what makes the next audit possible.
Keep the guest's objects explicit
Inside Linux, bridge membership and address ownership are separate objects, and conflating them causes the confusing half-working state. Assign addresses to the bridge interface or to the routed tunnel, not to both sides of the same path, and keep the member ports free of IP configuration.
Avoid putting one subnet independently on a routed TUN and on an unrelated Ethernet interface. That configuration produces two paths to the same prefix, asymmetric replies, and a support thread about flapping that never mentions either path. If the guest also hosts containers or a local hypervisor, check that they are not already bridging into the same uplink. Two bridges on one NIC is a design, not an accident you want to discover during a change window.
Confirm with a packet path, not a ping
Verify the actual path rather than reachability alone. From a client, confirm which source address arrives at the far service, then confirm the reply returns the same way. On the guest, check the forwarding counters for the specific flow, and on the port group confirm that no additional visibility was enabled beyond what the chosen design needs.
Finally, test the failure direction. Stop the tunnel or detach the client and check that traffic does not silently fall back to a routed path you thought was unused, because that fallback is how a bridged design quietly becomes an unintended router.