A Proxmox host can reach the internet over Wi-Fi while its virtual machines remain offline. That pattern often points to the network design, rather than a broken guest driver. A normal Ethernet bridge expects to carry traffic for multiple MAC addresses. An ordinary Wi-Fi client connection usually cannot provide that transparent behavior.
Separate the host path from the guest path
Start at the host console. Identify the wireless adapter, its connection state, the host address, and the default route. These commands inspect the current state; they do not replace your configured network manager.
ip -br address
ip route
ip -br link
bridge link
cat /etc/network/interfacesIf the host has no route or cannot reach its gateway, fix association, authentication, and host addressing first. If the host works, inspect the guest’s address and gateway separately. A guest attached to vmbr0 is not guaranteed to reach the access point merely because the host does.
Understand the wireless bridge limitation
In ordinary station mode, Wi-Fi frames do not carry the same address information as a transparent Ethernet bridge. The access point and client driver may reject or fail to transport guest traffic with additional source MAC addresses. Four-address or WDS support can change this, but it requires compatible behavior at both ends.
A reliable first option is Ethernet. A second option is an external wireless client bridge connected to the host’s Ethernet port. Check whether that device really supports multiple downstream MAC addresses; some products provide only a single-client workaround.
Treat Wi-Fi as a lab constraint, especially when availability matters. Keep host management reachable through a tested console while changing network configuration. Wireless interruptions are also a poor foundation for cluster communication and storage traffic.
Use routing when transparent bridging is unavailable
A routed design gives guests a separate subnet behind an internal bridge. The wireless uplink carries the host’s traffic, and the host routes guest packets. For example, an isolated lab bridge might use 172.28.40.1/24, with a guest at 172.28.40.10 and that bridge address as its gateway. Confirm the subnet does not overlap an existing LAN or VPN.
Guest 172.28.40.10
→ Internal bridge 172.28.40.1
→ Proxmox host routing / optional NAT
→ Wireless uplink
→ Existing gatewayThe upstream network needs a return route to the guest subnet. If you cannot add one, source NAT on the host can provide outbound access instead. That choice changes inbound access: services in a guest then need an explicitly designed route, VPN, or port forward. An empty bridge alone provides neither DHCP nor DNS.
Verify each dependency before changing firewall rules
sysctl net.ipv4.ip_forward
ip route
bridge linkIn the guest, verify its address, default route, and DNS. Test the bridge gateway first, then an approved upstream IP, then a hostname. On the host, observe traffic on the internal bridge and uplink with a narrow packet capture. Replies disappearing at the uplink suggest a return-path problem; traffic never leaving the bridge suggests forwarding or policy.
Implement forwarding and NAT through the host’s chosen firewall configuration, with persistent rules and a rollback plan. Avoid pasting an unrelated iptables recipe into a host already managed by another firewall backend.
Define what success means
A guest that can browse the web has passed only an outbound test. Verify the required management connections, DHCP behavior if used, DNS, and reconnect behavior after an uplink interruption. Record the architecture so future troubleshooting starts with the correct assumption: these guests are routed behind the host, rather than directly bridged onto the wireless LAN.