Empty LAN Game List Over OpenVPN? Check the Discovery Path

Pinging another player's tunnel address and seeing their hosted game are two different achievements. The lobby list usually depends on a discovery exchange that was written for a single local network, while the game session is an ordinary connection to an address and port. Treating an empty list as a routing failure sends you toward a bridge you may not need, so separate the two questions before changing anything.

Separate joining a session from finding it

A failed join points at routes, firewall rules and a listening service. A successful join with an empty list points at discovery, or at the address the announcement carries. Those two outcomes lead to completely different work, and you can only tell them apart by trying the first one deliberately.

Write the result down before you touch the VPN configuration. It is the cheapest test in the whole investigation and it eliminates half the design space. Note the address you used as well, since that becomes the reference point for every later test. Without that line in your notes, the next comparison is guesswork.

Test a direct join before touching the tunnel

If the game offers a direct connect option, use the host's tunnel address and the documented game port, and leave the game's own authentication and host firewall rules intact. A successful join narrows the problem to discovery. A failed join still needs its own investigation, and no relay will fix it.

Do not assume the discovery port and the session port are the same number. Games commonly announce on one UDP port and accept players on another, and a relay built for the wrong one produces a list that still stays empty.

Check which adapter the hosting process selected as well. A process bound to the home LAN address will announce that address, and the remote player cannot route to it even when the announcement arrives. The list may populate and the join may still fail for that reason alone.

Understand where broadcast stops

A routed TUN tunnel carries IP packets between peers and does not reproduce local broadcast on every peer's network. The limited broadcast address 255.255.255.255 stays inside the interface that emits it, and a subnet-directed broadcast is a separate case rather than a general licence for routers to flood announcements.

That is a property of the design, not a defect to be patched with an option. OpenVPN's client-to-client setting governs peer traffic inside the tunnel and is not a discovery relay, despite being suggested for this purpose in many threads. A relay is a separate component with its own configuration and its own failure modes. Assuming an existing option already covers it is the most common way this investigation stalls.

Multicast discovery has the same problem with a different address class, and it needs multicast routing or a relay rather than a broadcast exception.

When a relay is justified, keep it narrow

If automatic discovery is a requirement, identify the actual exchange first: broadcast or multicast, destination address, UDP port, the interface that sends it, and the address inside the reply. A protocol-appropriate relay scoped to those five facts is far narrower than extending an entire Ethernet segment.

Forwarding the packet unchanged can still be insufficient. If the payload tells the receiver to connect to an address it cannot reach, the relay delivers a useless answer, which is why the game's own interface or advertised-address setting should be tried before any relay exists.

Scope the relay to the interfaces and peers that need it, and define how replies find the requester. Repeating unrelated broadcasts exposes other local services and creates loops that are painful to debug later.

Bridge only when the design needs Ethernet

Ethernet frames travel inside TAP, so a TAP tunnel can belong to a deliberately bridged broadcast domain. Simply switching dev tun to dev tap does not build that bridge, does not make the server configuration compatible and does not make the application choose the new interface. The OpenVPN bridging guide describes the broader arrangement rather than a cure for one empty lobby.

Bridging also flattens the address plan, which is why the decision deserves a reason beyond impatience. Two networks that were separate become one, and every service on either side starts seeing the other side broadcasts. That consequence belongs in the change record before anyone enables it. There is no rule that game clients must sit in a 192.168 range; choose a non-overlapping plan and check the individual game's restrictions instead of renumbering the tunnel because a forum post did.

Keep the two results separate at the end: whether the host can be joined, and whether the discovery reply advertises a destination the other player can actually use. Fixing the second without confirming the first is how people end up maintaining a bridge for a problem that was never about broadcast.