Home Assistant Works on Wi-Fi but Fails on Ethernet or VPN

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

When Home Assistant works on Wi-Fi but fails on Ethernet or VPN, the application is probably healthy; the fault is usually in link state, addressing, routes, policy, DNS, return traffic, or multicast discovery.

Keep the known-good Wi-Fi path available while testing Ethernet and VPN separately. First use the target interface's direct IP, then verify gateway and return route, then test the service port, hostname, and discovery. Changing several network layers together can lock you out and makes a successful result impossible to attribute.

Prove the Ethernet Interface Has a Usable Address

Check physical link, negotiated speed, interface state, assigned address, subnet, gateway, and DHCP lease from the Home Assistant host or hypervisor. Compare them with a working client on the same Ethernet network. Link lights alone do not prove correct Layer 3 configuration.

A community case recommends inspecting all interfaces with nmcli when the expected eth0 device was absent. The useful first test is the actual interface name and address, not assuming every platform calls its wired port eth0.

From a client on the same subnet, ping or otherwise test the Ethernet IP and open port 8123 directly. If the IP is unreachable, remain at link, VLAN, DHCP, and subnet checks. If the IP works but the hostname fails, the Ethernet service is healthy and DNS becomes the next branch.

Check Route Choice, Firewall Policy, and Return Traffic

Inspect the routing table while both Wi-Fi and Ethernet are active. Identify the default route, interface metrics, and the route back to the testing client or VPN subnet. Replies leaving through the wrong interface can make inbound connections appear blocked even when the request arrived.

Temporarily test from the same VLAN before crossing router policies. If same-subnet access works but routed access fails, inspect inter-VLAN firewall rules, container network mode, hypervisor bridge, VPN allowed networks, and the reverse route on the Home Assistant side.

The ZimaSpace comparison of host and bridge networking helps distinguish a container port or discovery boundary from a physical Ethernet failure. Preserve the working Wi-Fi route until the wired path passes independently.

Separate Direct Reachability From DNS and Discovery

Test in order: Ethernet or VPN IP, service port, configured hostname, then automatic discovery. A direct IP success with a hostname failure points to DNS or a stale cached address. A direct UI success with missing devices points to discovery or device-subnet policy instead.

Cross-subnet Home Assistant discussions show that mDNS resolution may fail even when ordinary unicast traffic is allowed, because multicast discovery needs deliberate forwarding or a reflector. This multicast-versus-unicast distinction is especially important over VLANs and routed VPNs.

Do not widen every firewall rule to make discovery appear. Prefer explicit integration addresses when supported, or configure a narrowly scoped multicast relay between trusted segments. If the UI itself is unreachable by direct IP, discovery is not yet the relevant repair.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Apply One Network Fix and Retest Every Path

Correct the confirmed layer only: cable or switch port, DHCP reservation, subnet or gateway, interface metric, firewall rule, return route, DNS record, VPN allowed network, or multicast relay. Save the previous configuration and schedule a local access method before restarting network services.

Retest the Ethernet IP, hostname, local devices, VPN client, remote UI, WebSocket stability, and discovery in the same order. Restart the host once and renew client network state so stale routes and DNS do not create a temporary pass.

A passing result preserves reliable Ethernet access, retains the intended VPN route, avoids duplicate default paths, and discovers only across approved boundaries. Roll back if the working Wi-Fi path disappears or traffic leaks between segments; escalate with interface, route, firewall, and packet-flow evidence when requests arrive but replies still leave incorrectly.