Your Game Server Is on the VPN and Nobody Can Join
A tunnel is not an inbound path. Pick the entry players use, then make the reply return the same way, before you touch the bind address.
The server is up, the VPN is connected, and nobody outside can join. Everyone inside the tunnel can, which makes it look like an access rule. What is missing is not a permission but a path: an address and port that players can reach, and a route for the replies to come back the same way. A VPN exit address is not an inbound hosting feature.
Four ways players can reach the server
The real choice is who your audience is and how their packets enter, and there are four shapes worth naming.
| Design | Who can join | What it costs |
|---|---|---|
| Private VPN players | Only members of the tunnel | Every player needs a profile and identity |
| Provider public mapping | Anyone with the assigned address and port | Depends on supported protocol and mapping lifetime |
| Your own public relay | Anyone who can reach the relay | You run and secure the relay |
| Deliberate direct entry | Anyone who can reach your line | Split routing has to stay coherent |
The private design is the simplest and the least convenient: authorised players join a restricted network and reach the game at its private address. Give them access to the game service, not a shared identity that can wander across every host you own.
The relay design is the one people underestimate. A reachable gateway accepts public traffic and forwards it over a private tunnel to the host, so players never join the backend VPN. The relay has to carry the game's transport, and an HTTP proxy is not a generic UDP relay.
Follow the reply as carefully as the arrival
For any translated entry, record four things: the external address, the protocol, the port and the internal target. Netgate's port-forward reference makes the distinction that trips people up, separating destination translation from the firewall rule that permits traffic onward. Configure one without the other and you get a mapping that looks correct and passes nothing.
Then check the return. A forwarded request can arrive perfectly and fail because the host replies through a different exit. A relay can source-translate the backend flow, or preserve the source and rely on routing; those are different designs and they change what the game host sees as the player's address.
Encryption does not rescue a broken return path. It protects a segment, not a topology.
What the tunnel does not make private
The game's authentication, updates and admission policy still do their own work. A private backend tunnel does not make an intentionally public entry private, and it does not encrypt the player-to-public-entry leg at all. Those are two different hops with two different exposures, and a design note saying the game runs over a VPN is describing exactly one of them.
Write down which leg is protected and which is not before you advertise the address to anyone.
Choose the audience before the address
Decide who should be able to join, then pick the design that matches. Friends only means the private tunnel, or a relay with an allowlist. A public community means a relay or a direct entry with real exposure, plus moderation. Once that is settled, use the game's documented ports and its advertised-address behaviour inside the chosen design.
Do not reorder VPN adapters until a test passes. That produces a working server with an undocumented path nobody can rebuild after the next update.
The test is two players, one inside the tunnel and one outside, both completing a join and a round of traffic. Anything less does not prove the entry works.