StarRupture LAN Multiplayer and EOS Routing
A common frustration for players hosting StarRupture at home is that two machines on the same LAN cannot reliably connect to each other directly. The client returns "server not found" when pointed at a private LAN IP, and multiplayer only works by going out through the internet and back via a public IP or tunnel. This is a design consequence of Epic Online Services (EOS), which StarRupture uses as its session backbone. This guide explains why LAN-only play is not supported in the current Early Access build, which workarounds actually work, and which do not.
🏠 Fast Read
- Cause: Sessions are negotiated through EOS, not through direct LAN discovery.
- Symptom: Connecting to a private LAN IP returns "server not found" even on the same switch.
- Best workaround: Hairpin NAT via your own router plus public IP connect.
- Not a workaround: Using a "LAN only" hosts file entry or /etc/hosts redirect.
- Not yet supported: True offline LAN play with no internet connection.
Why Direct LAN Connects Fail
StarRupture relies on EOS for every multiplayer session. When a host starts a dedicated or player-hosted session, the server registers itself with the EOS service and the session becomes discoverable by session ID. When a client wants to join, it asks EOS for the address of the session's host. EOS returns the host's public IP, because that is the IP it saw when the host's traffic arrived at its servers.
If the client then sits on the same LAN as the host, it tries to connect to the public IP anyway. That is where two things can go wrong:
- The client's router refuses to route traffic to its own WAN IP from inside the LAN (hairpin NAT is disabled).
- The server's port forward only accepts external traffic and drops traffic arriving from the LAN.
Without either hairpin NAT or an external relay, the result is LogEOSSDK: Source Address Verification Failed in the server log and "server not found" in the client UI, even though both machines are sitting a metre apart.
Players on the Steam discussion thread have confirmed that pointing the client at the private LAN IP directly also fails. The client immediately returns "server not found" because the in-game join flow is driven by EOS session IDs, not by IP address. There is no menu option to skip the EOS lookup and speak straight to a LAN peer.
Symptom Fingerprint
- Two machines on the same LAN see each other at the network level (ping works) but the client cannot join.
- Server log contains
LogEOSConnect: VerifyIdTokenduring failed joins, confirming the call reaches EOS. - Connecting via the public IP works, confirming the server binary itself is fine.
- Disabling the router's internet connection causes every multiplayer join to fail, even for players on the same LAN.
- Steam's own "join session" flow between two accounts on the same LAN also goes through EOS and works or fails in lockstep.
Workaround 1: Hairpin NAT + Public IP
This is the most reliable workaround when both host and client sit behind the same router with internet access. Most consumer routers do not enable hairpin NAT (sometimes called "NAT loopback" or "reflection") by default. Turning it on lets a LAN client connect to the router's WAN IP and be correctly bounced back to the LAN host.
Steps:
- Log in to the router's admin UI. Look under NAT, Port Forwarding, or Virtual Servers for an option called "NAT Loopback", "Hairpinning", or "Reflection".
- Enable it. Save and reboot the router.
- Confirm that your port forwards for UDP 7777 (or your configured game port) and the query port target the host's LAN IP.
- On the client machine, connect to the public IP (or to the session via normal EOS discovery). The router will now loop LAN-originated traffic back into the LAN host correctly.
This is the standard fix and works for most consumer-grade routers from the last five years. If the setting is not present, check whether your ISP-provided router is in "bridge" mode with a second router behind it; hairpinning is usually handled by whichever router owns the WAN IP.
Workaround 2: Tunnel Service (CGNAT homes)
If your home connection is behind CGNAT (common with 5G home broadband, Starlink on certain plans, and some fibre ISPs), you cannot port forward at all. In that case, hairpinning does not help because there is no public endpoint on your own router. The practical solution is a tunnel service that gives you a public endpoint independent of your ISP.
Popular tunnels include Playit.gg and Ngrok. Both support UDP. The steps are:
- Install the tunnel agent on the host machine and create a UDP tunnel to local port 7777 (and a second tunnel to the query port).
- In the server config, set
PublicIPto the tunnel's public address and enableForceEOSIpBinding. See the EOS troubleshooting guide for the exact config block. - Share the tunnel's public address with LAN and remote players alike. Both types of player will connect via the tunnel, which is slightly slower than direct LAN but still much faster than the public internet on most CGNAT plans.
This is the same workaround that remote players would use to reach your server from outside the LAN. The only extra consideration on a CGNAT line is that your own LAN clients now also use the tunnel, because there is no working direct path. In practice the added latency is well under 10 ms.
Workaround 3: Dedicated Server on a Public VM
If you are hosting at home but want a LAN-like experience for a small group, the cleanest answer is to stop hosting at home. Rent a small VM or use a managed StarRupture hosting plan with a dedicated public IPv4. Everyone - LAN, remote, and guests - connects to the same public address, and you never need to care about hairpinning, CGNAT, or ISP routing quirks.
Supercraft's StarRupture hosting plans are designed around this pattern. Every server has a dedicated IPv4 address with predictable port forwarding, so EOS session discovery works identically for every player regardless of where they are physically located. See the hardware guide for sizing.
What Does NOT Work
Some LAN workaround ideas circulate on forums and Discord. These are the ones that look plausible but do not actually help:
- hosts file or /etc/hosts redirect. Redirecting an EOS hostname to a LAN IP will fail the TLS handshake. EOS pins certain endpoints and the client rejects the connection with a mismatch error.
- Offline mode on Steam. StarRupture requires EOS authentication, which requires internet connectivity. Steam offline mode does not include EOS.
- Private network VLAN or mesh VPN (Tailscale, ZeroTier) only between two machines. These give you a working private address but the client still asks EOS for the session and still gets the host's public IP back. Unless you tunnel all EOS traffic over the mesh (which most mesh VPNs do not do), you end up in the same place.
- In-game "Direct Connect" field. There is no such field in StarRupture's current UI. Every join goes through EOS session discovery.
Why Creepy Jar Designed It This Way
EOS gives StarRupture three things that would be expensive to build in-house: cross-play between Steam and Epic Games Store, friend invites, and session migration (the feature that powers SaveSync host migration). All three depend on EOS being the source of truth for who is hosting what. Carving out a "LAN only" code path that skips EOS would require duplicating session management for a relatively small audience, and the community is still requesting it rather than seeing it ship.
There is hope for the long term. Other EOS-based titles (most notably Satisfactory and Icarus) eventually shipped LAN or offline modes once Early Access stabilised. StarRupture's roadmap mentions improvements to dedicated server tooling over the coming content updates, and community feature requests for LAN-only play are high on the visible list. Until then, treat "no true LAN" as the default assumption when planning a hosting setup.
Decision Table
| Your Setup | Recommended Approach | Internet Required? |
|---|---|---|
| Two PCs in same home, normal broadband | Enable hairpin NAT on router | Yes |
| CGNAT home (5G, Starlink, some fibre) | Use UDP tunnel with public IP override | Yes |
| Travelling, café or hotel Wi-Fi | Rent a VM or use managed hosting | Yes |
| Crew spread across multiple cities | Managed dedicated server with dedicated IPv4 | Yes |
| Strict no-internet LAN party | Not supported by StarRupture today | - |
FAQ
Can my kid join my LAN server without the internet being up?
Not in the current Early Access build. EOS is required for every session join. If you need fully offline local play with children, StarRupture is not the right fit yet - look at Satisfactory's LAN mode or Factorio's direct IP connect for now.
Why does Steam show the host as "online" even when the LAN connect fails?
Steam presence is independent of the in-game session discovery. EOS and Steam presence use different backends, so Steam can correctly show the host online while the game itself still fails to negotiate a session.
Will Tailscale or ZeroTier help at all?
They help if you set up the mesh such that all EOS traffic originates from the same public IP on both host and client. In practice that is hard to configure cleanly and most users give up and use a tunnel service or managed hosting instead.
Is there a port I can block to force direct-LAN mode?
No. Blocking EOS endpoints causes the join to fail entirely rather than fall back to LAN. The client has no fallback path today.
Managed StarRupture hosting on Supercraft gives every player - LAN, remote, and visiting - the same public endpoint, so you never have to reason about hairpinning or CGNAT for your crew. See the StarRupture server hosting page.