Minecraft over a VPN: which address goes in the server list?

Typing the VPN endpoint into Minecraft server list feels logical and fails every time, because that address terminates the tunnel rather than hosting the game. A player joined to the same VPN already has a path to the game host, so the entry has to name the host and the port the game listens on. Get those two right and the rest of the problem is ordinary service reachability, which is a much shorter checklist than it first appears.

Two addresses, two jobs

One address is public infrastructure: the transport endpoint that carries encrypted packets between peers. The other is a private address belonging to the machine running the dedicated server. They are not interchangeable, and substituting one for the other produces a connection refused or a timeout that looks like a firewall problem.

With the default port, the player types 10.60.0.20:25565 and nothing else. Mojang's Java server download page names 25565 as the default, and a server operator who changed the port has to be believed rather than second-guessed from an old tutorial.

Make that address a real service

A reachable address is necessary and not sufficient. The dedicated server has to be running, has to be compatible with the version the player's client runs, and has to be listening on an address the tunnel can deliver to. A process bound only to loopback does not become reachable because somebody added another address to the machine.

Confirm the listener before touching a firewall:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

The first line shows what the process actually bound to, and the second shows whether a peer can complete a TCP handshake. When the bind is 127.0.0.1, no amount of VPN configuration changes the outcome, and that single detail explains a surprising number of "the VPN is broken" reports.

Peer policy, firewall and the reply path

Two permission questions sit on top of the listener. The VPN peer configuration has to allow traffic between the two peers, and the game host firewall has to accept the game port from that peer. Keep both scoped to the game service and the authorized peers instead of disabling the host firewall, which trades a two-line rule for a much larger problem. Narrow rules are also the only version of this that survives a security review without a paragraph of justification.

Then remember what a successful ping proves. Reaching the VPN gateway, or getting a reply from the game host, only demonstrates that ICMP crossed the path. A game connection needs the specific port to be open in both directions, and the reply path matters as much as the outbound one.

When the server sits behind the gateway

The example above has the game server as a peer, which keeps the address plan trivial. If the server instead lives on a LAN behind a VPN gateway, the player needs the server's routable private address, the gateway needs forwarding configured for that LAN, and the LAN host needs a route back toward the tunnelled client. Miss the return path and the handshake dies halfway, which is the most confusing failure of the three.

Do not copy the example peer address onto another machine to imitate this topology. Addresses in an example describe roles, and reusing one across two roles creates an overlap that routing cannot resolve.

Discovery, accounts and what not to change

Automatic LAN discovery is a convenience built on announcements. A routed VPN need not carry those broadcasts, so a missing entry in the LAN list says nothing about whether the explicit private address works. Type the address, then judge. If it connects, the discovery gap is a usability nuisance rather than a fault, and it can be documented as such instead of investigated.

Keep the game's normal account authentication and admission policy intact as well. A working private route grants a path, not membership, and no amount of adapter priority shuffling substitutes for identifying the destination the client should be using.