Why Your LAN Game Vanishes Before You Add a VPN

A group of people install a game, connect to the same network, and see an empty server list. The reflex is to blame the network and look for a tunnel, but the game may never have sent a packet that a tunnel could carry. Before any VPN enters the picture, work out which of three things the edition actually does when someone clicks multiplayer.

The three are not interchangeable. One uses direct local traffic, one asks a service who else is playing, and one refuses to start without an account. A tunnel can help with the first, is irrelevant to the second, and cannot fix the third. That order matters, because all three can produce the same empty list with three different fixes.

What the game checks before it lists a host

Most multiplayer menus do several things in sequence: confirm the signed-in account, check entitlements for the edition, query a backend for lobbies or friends, and only then look at the local network. Any step can fail silently, and the interface usually shows the same empty list either way. That is why "LAN is broken" is a diagnosis you cannot make from the screen alone. A backend error, an expired entitlement and an isolated subnet are indistinguishable from the lobby screen, and only one of them is a network problem at all.

Read the edition's own documentation before changing network settings. Remasters routinely drop direct IP join, replace LAN discovery with a hosted lobby, or require a platform account that the original release never needed. The support page for the current Age of Empires II: Definitive Edition, for instance, walks through a lobby hosted on the game's servers where you choose visibility, a password and a region; that is an application workflow to verify for that edition, not evidence about any earlier release.

Note the build number as well as the edition name. A patch can move a game from one model to another, and instructions written for the launch build may describe a menu that no longer exists.

Discovery packets die at the first router

Direct LAN play usually depends on broadcast or multicast: the host announces itself to a subnet-wide address, and clients listen for that announcement. Those packets are not routable by design, so a router between the two machines drops them even when unicast traffic would pass. Two devices on the same switch see each other; the same two devices on different VLANs, or on a guest network with client isolation, do not. Consoles and phones usually follow the same pattern with their own discovery protocol, which is why the platform matters as much as the game.

This is where most "same Wi-Fi, no servers" reports come from. A guest SSID with isolation enabled, a mesh system that puts the console on a separate segment, or a firewall profile that treats the local subnet as public will each break discovery while leaving ordinary internet access working. Check the client isolation setting and the subnet mask before assuming the game is at fault.

A lobby service is not a network path

When the game uses a hosted lobby, the list of matches comes from the operator's servers, not from your subnet. A VPN changes the path your packets take to those servers, but it does not change which lobbies the service shows you, which region the match is hosted in, or whether your account is entitled to join. Those are answers the backend gives, and no amount of routing changes them.

In that model a tunnel is at best a latency variable and at worst a geo-detection problem, because the service sees the exit address rather than your street address. The same logic applies to friend invitations and party systems. They are account-level features mediated by the platform, which is why two players on the same LAN can fail to see each other in a lobby while both can join a stranger's match.

What a tunnel can rebuild, and what it cannot

A tunnel is useful when the players are in different places and the game supports direct joining by address. A routed tunnel carries unicast traffic between the two sites; a bridged tunnel, or an overlay that presents a virtual Ethernet segment, can also carry the broadcast discovery that direct LAN play depends on. That is the distinction to understand: routing moves packets between subnets, bridging makes two sites look like one subnet.

What a tunnel cannot do is add a multiplayer mode the application does not implement. If the edition removed direct join, a virtual LAN segment will not restore it. If the lobby requires an account, a tunnel will not satisfy the check. And if the two machines sit behind the same NAT with isolation between them, an overlay may work around the isolation, but it is also a policy bypass, which is a conversation to have with whoever runs the network.

Test the path the game actually uses

Start with one host and one client on the same subnet, isolation disabled, and no tunnel. If that works, the game and the edition support what you are trying to do, and any later failure is a path problem. If it fails there, the tunnel was never the answer.

Then record what the manual says about the join method, the port or discovery mechanism, and any account requirement. Move one variable at a time: subnet first, then segment, then tunnel. Capture the host's address and the exact menu path so the next session can reproduce the test instead of repeating the argument.

Settle the version, who hosts, how people join, and which account or subscription the session needs, and write that down before the date. It ends more arguments than a tunnel ever will, and it leaves a record of what was tested.