RCON is UDP on the game port in 8 tutorials
Browse SourceGoldSrc RCON is connectionless UDP on the game port (challenge, then rcon <challenge> <password> <command>); HLDS does not listen on TCP. Removed the TCP 27015 rules and the RCON-is-TCP explanations; rcon-from-linux-cli and discord-rcon-bot already said this correctly.
8 changed files
with 20 additions and 30 deletions
M
cs16-server-firewall-ports/en.md
+9 -14
M
fix-server-only-visible-on-lan/en.md
+2 -3
M
install-cs16-dedicated-server-linux-steamcmd/en.md
+1 -2
M
install-cs16-server-docker/en.md
+2 -2
M
install-cs16-server-ubuntu-24-04/en.md
+2 -4
M
migrate-cs16-server-to-new-vps/en.md
+1 -1
M
multiple-cs16-servers-one-vps/en.md
+2 -3
M
run-cs16-server-behind-nat/en.md
+1 -1
cs16-server-firewall-ports/en.md
M
| @@ -6,42 +6,37 @@ tags: "firewall, ports" | ||
| 6 | 6 | image: "" |
| 7 | 7 | read_time: "8 min read" |
| 8 | 8 | --- |
| 9 | -<p>CS 1.6 firewalling confuses people because the game is UDP but RCON is TCP on the same port number, and because "open the port" on a VPS means two different things — the host firewall and the provider's network filter. This is the complete, minimal port list, why each one exists, and how to confirm it is genuinely reachable from outside.</p> | |
| 9 | +<p>CS 1.6 firewalling confuses people because many guides tell you to open TCP 27015 for RCON (GoldSrc RCON actually travels over UDP on the game port), and because "open the port" on a VPS means two different things — the host firewall and the provider's network filter. This is the complete, minimal port list, why each one exists, and how to confirm it is genuinely reachable from outside.</p> | |
| 10 | 10 | |
| 11 | 11 | <h2>The ports that matter</h2> |
| 12 | 12 | <table> |
| 13 | 13 | <thead><tr><th>Port</th><th>Protocol</th><th>Direction</th><th>Purpose</th></tr></thead> |
| 14 | 14 | <tbody> |
| 15 | -<tr><td>27015</td><td>UDP</td><td>Inbound</td><td>Game traffic and Steam A2S queries. The one non-negotiable port.</td></tr> | |
| 16 | -<tr><td>27015</td><td>TCP</td><td>Inbound</td><td>RCON. Same number as the game, different protocol.</td></tr> | |
| 15 | +<tr><td>27015</td><td>UDP</td><td>Inbound</td><td>Game traffic, Steam A2S queries and RCON. The one non-negotiable port.</td></tr> | |
| 17 | 16 | <tr><td>27020</td><td>UDP</td><td>Inbound</td><td>HLTV / SourceTV, if you run a spectator proxy. Default; configurable.</td></tr> |
| 18 | 17 | <tr><td>26900</td><td>UDP</td><td>Inbound</td><td>Legacy client/query port range some setups use. Harmless to allow.</td></tr> |
| 19 | 18 | <tr><td>27011 / 27015-27016</td><td>UDP</td><td>Outbound</td><td>Heartbeats to the Steam master servers. Needs outbound UDP, not inbound.</td></tr> |
| 20 | 19 | </tbody> |
| 21 | 20 | </table> |
| 22 | -<p>For a single default server, the honest minimum is <strong>UDP 27015 inbound</strong> (game) and <strong>TCP 27015 inbound</strong> (RCON). Everything else is situational.</p> | |
| 21 | +<p>For a single default server, the honest minimum is <strong>UDP 27015 inbound</strong> (game, queries and RCON). Everything else is situational.</p> | |
| 23 | 22 | |
| 24 | 23 | <h2>1. UDP is the game; do not forget it</h2> |
| 25 | 24 | <p>All gameplay — movement, shooting, the A2S query that populates the server browser — is UDP 27015. If only TCP is open, the server browser shows nothing and no one connects. This is the mistake people make when they reuse a web-server firewall template that only thinks in TCP.</p> |
| 26 | 25 | |
| 27 | -<h2>2. RCON is TCP on the same number</h2> | |
| 28 | -<p>Remote console uses a TCP connection to the same port number as the game. So a fully working server needs both <code>27015/udp</code> and <code>27015/tcp</code> open. If players connect fine but your web-based RCON tool times out, TCP 27015 is closed.</p> | |
| 26 | +<h2>2. RCON uses the same UDP port</h2> | |
| 27 | +<p>GoldSrc remote console is connectionless UDP on the game port: the tool asks the server for a challenge, then sends the password and command as UDP packets to 27015. HLDS does not listen on TCP at all, so a <code>27015/tcp</code> rule does nothing. If players connect fine but your RCON tool times out, the tool is probably speaking the Source-style TCP RCON protocol, which GoldSrc does not understand; see <a href="/tutorials/rcon-from-linux-cli">RCON from the Linux command line</a>.</p> | |
| 29 | 28 | |
| 30 | 29 | <h2>3. ufw (Ubuntu / Debian)</h2> |
| 31 | -<pre>sudo ufw allow 27015/udp | |
| 32 | -sudo ufw allow 27015/tcp</pre> | |
| 30 | +<pre>sudo ufw allow 27015/udp</pre> | |
| 33 | 31 | <p>Running <a href="/tutorials/multiple-cs16-servers-one-vps">several servers</a>? Open the whole range:</p> |
| 34 | -<pre>sudo ufw allow 27015:27020/udp | |
| 35 | -sudo ufw allow 27015:27020/tcp</pre> | |
| 32 | +<pre>sudo ufw allow 27015:27020/udp</pre> | |
| 36 | 33 | <p>Check the result:</p> |
| 37 | 34 | <pre>sudo ufw status numbered</pre> |
| 38 | 35 | |
| 39 | 36 | <h2>4. iptables (no ufw)</h2> |
| 40 | 37 | <pre>sudo iptables -A INPUT -p udp --dport 27015 -j ACCEPT |
| 41 | -sudo iptables -A INPUT -p tcp --dport 27015 -j ACCEPT | |
| 42 | 38 | # for a range of servers: |
| 43 | -sudo iptables -A INPUT -p udp --dport 27015:27020 -j ACCEPT | |
| 44 | -sudo iptables -A INPUT -p tcp --dport 27015:27020 -j ACCEPT</pre> | |
| 39 | +sudo iptables -A INPUT -p udp --dport 27015:27020 -j ACCEPT</pre> | |
| 45 | 40 | <p>Persist the rules with <code>iptables-save</code> or your distro's <code>netfilter-persistent</code> so they survive a reboot — a firewall that forgets its rules on restart is a classic "it worked yesterday" report.</p> |
| 46 | 41 | |
| 47 | 42 | <h2>5. Outbound must be allowed too</h2> |
| @@ -56,7 +51,7 @@ sudo iptables -A INPUT -p tcp --dport 27015:27020 -j ACCEPT</pre> | ||
| 56 | 51 | <h2>Common errors</h2> |
| 57 | 52 | <ul> |
| 58 | 53 | <li><strong>Server in list, but nobody can connect (or vice versa)</strong> — you opened TCP but not UDP. Gameplay and browser queries are UDP; open <code>27015/udp</code>.</li> |
| 59 | -<li><strong>Players connect, RCON times out</strong> — TCP 27015 is closed. Open it.</li> | |
| 54 | +<li><strong>Players connect, RCON times out</strong> - not a closed port: RCON shares UDP 27015 with the game. The tool may speak Source-style TCP RCON, the password may be wrong, or the server banned your IP after failed attempts (<code>sv_rcon_maxfailures</code>). See <a href="/tutorials/rcon-from-linux-cli">RCON from the Linux command line</a>.</li> | |
| 60 | 55 | <li><strong>Direct connect works, server never lists</strong> — outbound UDP to the master is blocked, or <code>sv_lan 1</code>. Allow egress and set <code>sv_lan 0</code>.</li> |
| 61 | 56 | <li><strong>Works until reboot</strong> — iptables rules were not persisted. Save them.</li> |
| 62 | 57 | <li><strong>ufw open, still unreachable</strong> — the provider's network firewall is blocking UDP. Fix it in their panel.</li> |
fix-server-only-visible-on-lan/en.md
M
| @@ -22,14 +22,13 @@ read_time: "8 min read" | ||
| 22 | 22 | |
| 23 | 23 | <h2>3. Open UDP 27015 inbound</h2> |
| 24 | 24 | <p>The internet list only shows servers the master can reach back on their game port. UDP 27015 must be open <strong>inbound</strong>:</p> |
| 25 | -<pre>sudo ufw allow 27015/udp | |
| 26 | -sudo ufw allow 27015/tcp</pre> | |
| 25 | +<pre>sudo ufw allow 27015/udp</pre> | |
| 27 | 26 | <p>On Windows:</p> |
| 28 | 27 | <pre>New-NetFirewallRule -DisplayName "HLDS UDP 27015" -Direction Inbound -Protocol UDP -LocalPort 27015 -Action Allow</pre> |
| 29 | 28 | <p>Many cloud providers also have a separate security-group/firewall in their control panel — the OS firewall being open does not help if the provider blocks the port upstream. Open UDP 27015 there too.</p> |
| 30 | 29 | |
| 31 | 30 | <h2>4. NAT / port forwarding</h2> |
| 32 | -<p>If the server is at home behind a router, forward UDP 27015 (and TCP 27015 for RCON) to the machine's LAN IP. Without a forward, the master server's reachability probe never arrives and the server is dropped from the list even though it heartbeats. Bind explicitly so there is no ambiguity:</p> | |
| 31 | +<p>If the server is at home behind a router, forward UDP 27015 (RCON uses the same UDP port) to the machine's LAN IP. Without a forward, the master server's reachability probe never arrives and the server is dropped from the list even though it heartbeats. Bind explicitly so there is no ambiguity:</p> | |
| 33 | 32 | <pre>./hlds_run -game cstrike -ip 0.0.0.0 -port 27015 +sv_lan 0 +map de_dust2 +maxplayers 20</pre> |
| 34 | 33 | |
| 35 | 34 | <h2>5. Confirm the port is really listening</h2> |
install-cs16-dedicated-server-linux-steamcmd/en.md
M
| @@ -79,9 +79,8 @@ mp_logdetail 3</pre> | ||
| 79 | 79 | <p><code>hlds_run</code> is a shell wrapper that restarts <code>hlds_linux</code> after a crash and writes <code>debug.log</code>. <code>-strictportbind</code> makes the server fail loudly instead of silently taking port 27016 when 27015 is busy. Parameters are explained in <a href="/tutorials/hlds-command-line-parameters">the command line reference</a>.</p> |
| 80 | 80 | |
| 81 | 81 | <h2>8. Open the firewall</h2> |
| 82 | -<p>CS 1.6 is UDP-only for gameplay; RCON also uses TCP on the same port number.</p> | |
| 82 | +<p>CS 1.6 uses UDP only: gameplay, server queries and RCON all go over the game port.</p> | |
| 83 | 83 | <pre>sudo ufw allow 27015/udp |
| 84 | -sudo ufw allow 27015/tcp | |
| 85 | 84 | sudo ufw allow 26900/udp</pre> |
| 86 | 85 | <p>26900 is the outbound client port range used for master-server communication on some setups; it costs nothing to allow. Details: <a href="/tutorials/cs16-server-firewall-ports">which ports to open</a>.</p> |
| 87 | 86 |
install-cs16-server-docker/en.md
M
| @@ -52,7 +52,7 @@ exec /home/steam/hlds/hlds_run -game cstrike \ | ||
| 52 | 52 | cs16-server</pre> |
| 53 | 53 | <p>With <code>--network host</code> the container shares the host's network stack, UDP 27015 is bound directly, and A2S/heartbeat traffic has the correct source. If you cannot use host networking (for example on a platform that forbids it), you must publish UDP <strong>and</strong> keep the same internal and external port number, and expect to fight master-list visibility:</p> |
| 54 | 54 | <pre>docker run -d --name cs16 \ |
| 55 | - -p 27015:27015/udp -p 27015:27015/tcp \ | |
| 55 | + -p 27015:27015/udp \ | |
| 56 | 56 | -v cs16-data:/home/steam/hlds \ |
| 57 | 57 | cs16-server</pre> |
| 58 | 58 | |
| @@ -74,7 +74,7 @@ volumes: | ||
| 74 | 74 | <ul> |
| 75 | 75 | <li><strong>Container runs, server never appears in the internet list</strong> — you are on bridge networking with port publishing. Switch to <code>--network host</code>. This is the single most common Docker-specific failure.</li> |
| 76 | 76 | <li><strong><code>./hlds_linux: No such file or directory</code></strong> — the i386 runtime is missing from the image. That ELF-interpreter error means <code>/lib/ld-linux.so.2</code> is absent; add the i386 packages to the Dockerfile.</li> |
| 77 | -<li><strong>Players connect but the server ignores <code>rcon</code></strong> — RCON is TCP; under bridge networking you only published UDP. Publish TCP 27015 too, or use host networking.</li> | |
| 77 | +<li><strong>Players connect but the server ignores <code>rcon</code></strong> - not a missing TCP port: GoldSrc RCON shares UDP 27015 with the game, so publishing UDP is enough. Check the password, that your tool speaks GoldSrc (UDP) RCON rather than Source-style TCP RCON, and that <code>sv_rcon_maxfailures</code> has not banned your IP.</li> | |
| 78 | 78 | <li><strong>Re-downloads the game every start</strong> — you baked the install into the image layer instead of a volume, or the entrypoint's "already installed" check does not match your path.</li> |
| 79 | 79 | </ul> |
| 80 | 80 |
install-cs16-server-ubuntu-24-04/en.md
M
| @@ -49,9 +49,8 @@ ls /home/steam/hlds/hlds_run /home/steam/hlds/hlds_linux</pre> | ||
| 49 | 49 | <p><code>sv_lan 0</code> is mandatory to appear on the master list; with <code>sv_lan 1</code> the server never heartbeats and Steam clients are refused.</p> |
| 50 | 50 | |
| 51 | 51 | <h2>7. Firewall with ufw</h2> |
| 52 | -<p>24.04 ships ufw. Open the game port for both protocols (UDP is gameplay, TCP is RCON):</p> | |
| 53 | -<pre>sudo ufw allow 27015/udp | |
| 54 | -sudo ufw allow 27015/tcp</pre> | |
| 52 | +<p>24.04 ships ufw. Open the game port over UDP (gameplay, server queries and RCON all use it):</p> | |
| 53 | +<pre>sudo ufw allow 27015/udp</pre> | |
| 55 | 54 | <p>Details and the optional HLTV/query ports are in <a href="/tutorials/cs16-server-firewall-ports">which ports to open</a>.</p> |
| 56 | 55 | |
| 57 | 56 | <h2>Why 24.04 needs this when older boxes did not</h2> |
| @@ -61,7 +60,6 @@ sudo ufw allow 27015/tcp</pre> | ||
| 61 | 60 | <p>24.04 ships ufw disabled by default. If you enable it, set a default-deny inbound policy and then open only what you need, or you will lock yourself out of SSH:</p> |
| 62 | 61 | <pre>sudo ufw allow OpenSSH |
| 63 | 62 | sudo ufw allow 27015/udp |
| 64 | -sudo ufw allow 27015/tcp | |
| 65 | 63 | sudo ufw enable</pre> |
| 66 | 64 | <p>Run the server as the unprivileged <code>steam</code> user (step 1), keep the OS patched, and put the launch behind a <a href="/tutorials/hlds-systemd-service">systemd unit</a> rather than a login shell so a dropped SSH session never takes the server down with it.</p> |
| 67 | 65 |
migrate-cs16-server-to-new-vps/en.md
M
| @@ -14,4 +14,4 @@ cstrike/addons/amxmodx/data/ // csstats.dat, vault.ini, sqlite dbs</pre><p>Th | ||
| 14 | 14 | tar czf cs16-backup.tar.gz cstrike/</pre><h2>4. Sync the state across with rsync</h2><p>Copy directly between hosts rather than downloading and re-uploading. From the old server, push the directories that hold state:</p><pre>rsync -avz --progress \ |
| 15 | 15 | cstrike/addons cstrike/maps cstrike/*.cfg \ |
| 16 | 16 | user@NEW_VPS_IP:~/hlds/cstrike/</pre><p>The <code>-a</code> flag preserves timestamps and permissions; <code>-z</code> compresses over the wire. Run it again just before cutover to catch bans and stats that changed while you were setting up — rsync only transfers the differences the second time.</p><h2>5. Fix ownership and make the data writable</h2><p>Files land owned by the transfer user, which is rarely the account that runs HLDS. Correct it or the server cannot write stats or save bans:</p><pre>chown -R hlds:hlds ~/hlds/cstrike |
| 17 | -chmod -R u+rw ~/hlds/cstrike/addons/amxmodx/data</pre><p>A read-only <code>data/</code> directory is the classic cause of "ranks reset on every restart" after a move — the engine simply cannot persist <code>csstats.dat</code>.</p><h2>6. Update the IP and open the ports</h2><p>The new VPS has a new public IP. Update <code>server.cfg</code>, any <code>sv_downloadurl</code> mirror, and anything that hard-codes the old address, then open <strong>UDP 27015</strong> (and TCP if you run RCON or HLTV) on the new firewall as in <a href="/tutorials/cs16-server-firewall-ports">the firewall ports guide</a>. If you advertised the old IP to players, follow <a href="/tutorials/change-server-ip-keep-players">changing the IP while keeping players</a> so they are redirected rather than lost.</p><h2>7. Cut over</h2><p>Start the new server, confirm it is healthy and shows in the master list, then stop the old one. Point your DNS or community listing at the new address last, once you have verified the new box is serving. Leave the old VPS untouched for a few days as a hot rollback.</p><h2>Common errors</h2><ul><li><strong>Ranks are all zero after the move</strong> — <code>csstats.dat</code> was not copied, or <code>addons/amxmodx/data/</code> is not writable by the HLDS user. Re-sync it and fix permissions.</li><li><strong>Server starts but no plugins load</strong> — you copied <code>cstrike/addons</code> but the new engine has a different Metamod path, or <code>metamod.dll</code>/<code>.so</code> line in <code>liblist.gam</code> was not migrated. Re-check the Metamod install on the new box.</li><li><strong>"Bad load" on every plugin</strong> — the modules were compiled for a different architecture. Reinstall AMX Mod X natively rather than copying binaries between mismatched distros.</li><li><strong>Bans came back or vanished</strong> — you copied <code>banned_user.cfg</code> but not <code>listip.cfg</code>, or vice versa. Engine SteamID and IP bans live in separate files.</li><li><strong>Players cannot connect at all</strong> — the new firewall or provider security group blocks UDP 27015. Verify with the firewall guide.</li></ul><h2>Verification</h2><p>From a client, connect to the new IP and play a round. Type <code>say /rank</code> (if you run stats) and confirm your old numbers survived. Check a banned test SteamID still cannot join. Restart the new server and confirm plugins load and stats persist — if a rank resets, the data directory is not writable. Only once the new box has passed a full map rotation should you decommission the old VPS.</p> | |
| 17 | +chmod -R u+rw ~/hlds/cstrike/addons/amxmodx/data</pre><p>A read-only <code>data/</code> directory is the classic cause of "ranks reset on every restart" after a move — the engine simply cannot persist <code>csstats.dat</code>.</p><h2>6. Update the IP and open the ports</h2><p>The new VPS has a new public IP. Update <code>server.cfg</code>, any <code>sv_downloadurl</code> mirror, and anything that hard-codes the old address, then open <strong>UDP 27015</strong> (RCON uses it too; add your HLTV UDP port if you run one) on the new firewall as in <a href="/tutorials/cs16-server-firewall-ports">the firewall ports guide</a>. If you advertised the old IP to players, follow <a href="/tutorials/change-server-ip-keep-players">changing the IP while keeping players</a> so they are redirected rather than lost.</p><h2>7. Cut over</h2><p>Start the new server, confirm it is healthy and shows in the master list, then stop the old one. Point your DNS or community listing at the new address last, once you have verified the new box is serving. Leave the old VPS untouched for a few days as a hot rollback.</p><h2>Common errors</h2><ul><li><strong>Ranks are all zero after the move</strong> — <code>csstats.dat</code> was not copied, or <code>addons/amxmodx/data/</code> is not writable by the HLDS user. Re-sync it and fix permissions.</li><li><strong>Server starts but no plugins load</strong> — you copied <code>cstrike/addons</code> but the new engine has a different Metamod path, or <code>metamod.dll</code>/<code>.so</code> line in <code>liblist.gam</code> was not migrated. Re-check the Metamod install on the new box.</li><li><strong>"Bad load" on every plugin</strong> — the modules were compiled for a different architecture. Reinstall AMX Mod X natively rather than copying binaries between mismatched distros.</li><li><strong>Bans came back or vanished</strong> — you copied <code>banned_user.cfg</code> but not <code>listip.cfg</code>, or vice versa. Engine SteamID and IP bans live in separate files.</li><li><strong>Players cannot connect at all</strong> — the new firewall or provider security group blocks UDP 27015. Verify with the firewall guide.</li></ul><h2>Verification</h2><p>From a client, connect to the new IP and play a round. Type <code>say /rank</code> (if you run stats) and confirm your old numbers survived. Check a banned test SteamID still cannot join. Restart the new server and confirm plugins load and stats persist — if a rank resets, the data directory is not writable. Only once the new box has passed a full map rotation should you decommission the old VPS.</p> |
multiple-cs16-servers-one-vps/en.md
M
| @@ -66,9 +66,8 @@ sudo systemctl enable --now hlds@server2 | ||
| 66 | 66 | sudo systemctl enable --now hlds@server3</pre> |
| 67 | 67 | |
| 68 | 68 | <h2>5. Open the ports</h2> |
| 69 | -<pre>sudo ufw allow 27015:27017/udp | |
| 70 | -sudo ufw allow 27015:27017/tcp</pre> | |
| 71 | -<p>The TCP range is for RCON. If you also run HLTV per instance, allocate a second block (27020+) and open it too — see <a href="/tutorials/cs16-server-firewall-ports">which ports to open</a>.</p> | |
| 69 | +<pre>sudo ufw allow 27015:27017/udp</pre> | |
| 70 | +<p>RCON shares each server's UDP port, so no TCP rule is needed. If you also run HLTV per instance, allocate a second block (27020+) and open it too — see <a href="/tutorials/cs16-server-firewall-ports">which ports to open</a>.</p> | |
| 72 | 71 | |
| 73 | 72 | <h2>Common errors</h2> |
| 74 | 73 | <ul> |
run-cs16-server-behind-nat/en.md
M
| @@ -9,4 +9,4 @@ read_time: "8 min read" | ||
| 9 | 9 | <p>Hosting a CS 1.6 server on a machine behind a home router means the server has a private LAN address (like <code>192.168.1.50</code>) while the internet only sees your router's public IP. Nothing reaches the server until you tell the router to forward the game traffic and tell the server to advertise itself publicly. This covers port forwarding, the cvars that matter, and the two situations — double-NAT and CGNAT — where a home connection genuinely cannot host without help.</p><h2>1. Give the server machine a static LAN IP</h2><p>Port forwarding points at one internal address, so that address must not change. Either set a static IP on the server machine or create a DHCP reservation in the router keyed to its MAC. If the machine's LAN IP drifts from <code>.50</code> to <code>.51</code> after a reboot, your forward now points at nothing.</p><h2>2. Forward the game port on the router</h2><p>CS 1.6 uses <strong>UDP 27015</strong> by default. In the router's port-forwarding section, add a rule:</p><pre>Protocol: UDP |
| 10 | 10 | External: 27015 |
| 11 | 11 | Internal IP: 192.168.1.50 // your server machine |
| 12 | -Internal: 27015</pre><p>UDP is the game traffic and is mandatory. Forward <strong>TCP 27015</strong> as well only if you use RCON over TCP or run an HLTV proxy on that port. If you run multiple servers on 27016, 27017, and so on, forward each of those UDP ports too.</p><h2>3. Leave LAN mode off</h2><p>A server with <code>sv_lan 1</code> refuses outside connections and never registers with the master list. In <code>server.cfg</code>:</p><pre>sv_lan 0</pre><p>This is required for the server to be reachable and listed publicly, exactly as on a VPS.</p><h2>4. Bind and advertise the correct IP</h2><p>By default HLDS binds all interfaces, which is usually fine behind NAT. The mistake is forcing the <em>private</em> address on the command line. If you pass <code>+ip</code>, it must be the machine's LAN IP for binding — never the public IP, which the machine does not own:</p><pre>./hlds_run -game cstrike +ip 192.168.1.50 +port 27015 +maxplayers 16 +map de_dust2</pre><p>In most home setups you can omit <code>+ip</code> entirely and let it bind everything. Players connect to your <em>public</em> IP; the router translates that to the private one via your forward. See <a href="/tutorials/hlds-command-line-parameters">the command-line parameters guide</a> for the full flag list.</p><h2>5. Test from outside your network</h2><p>You cannot properly test from inside your own LAN — many routers do not loop a public-IP connection back inward (no NAT hairpinning), so it "fails" from your own PC while working fine for everyone else. Have a friend connect to your public IP, or use a phone on mobile data:</p><pre>connect YOUR_PUBLIC_IP:27015</pre><p>Find your public IP from the router's status page or any "what is my IP" service, not from the server machine's <code>ifconfig</code>, which shows the private one.</p><h2>6. Handle double-NAT and CGNAT</h2><p>Two common home situations block hosting even with a perfect forward:</p><ul><li><strong>Double-NAT</strong> — an ISP modem in router mode sits in front of your own router, so you forwarded on the inner router but the outer one still drops the traffic. Fix it by putting the ISP modem in bridge mode, or by forwarding 27015 on <em>both</em> devices in a chain.</li><li><strong>CGNAT (carrier-grade NAT)</strong> — the ISP shares one public IP across many customers, so you have no forwardable public address at all. No amount of local configuration fixes this. You need the ISP to give you a real public IP, or you tunnel out through a VPS with a public address. Mobile and many fibre connections are CGNAT by default.</li></ul><h2>Common errors</h2><ul><li><strong>Server works on LAN, invisible online</strong> — <code>sv_lan 1</code> is set, or the router forward is missing/wrong. Set <code>sv_lan 0</code> and re-check the forward's internal IP.</li><li><strong>Forward is correct but still unreachable, and you tested from your own PC</strong> — NAT hairpinning is disabled on your router. Test from an outside network before concluding it is broken.</li><li><strong>Bind error on startup</strong> — you passed the public IP to <code>+ip</code>. Use the machine's LAN IP or drop the flag.</li><li><strong>Only you can join, nobody else</strong> — likely double-NAT; forward on the outer modem too or bridge it.</li><li><strong>No public IP at all / IP starts with 100.64.x.x</strong> — you are on CGNAT. Contact the ISP for a public IP or host through a VPS tunnel.</li></ul><h2>Verification</h2><p>From an outside network, run <code>connect YOUR_PUBLIC_IP:27015</code> and confirm you join. Then check the server appears in the internet server browser once <code>sv_lan 0</code> has propagated. If the connection times out from outside but the server console shows it running, the traffic is being dropped before the machine — walk back through the forward, the double-NAT check, and finally the CGNAT test. For anything more than a small private server, a <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">VPS install</a> avoids all of this.</p> | |
| 12 | +Internal: 27015</pre><p>UDP is the game traffic and is mandatory. RCON uses the same UDP port, so no TCP forward is needed. If you run an HLTV proxy, forward its UDP port (27020 by default) too. If you run multiple servers on 27016, 27017, and so on, forward each of those UDP ports too.</p><h2>3. Leave LAN mode off</h2><p>A server with <code>sv_lan 1</code> refuses outside connections and never registers with the master list. In <code>server.cfg</code>:</p><pre>sv_lan 0</pre><p>This is required for the server to be reachable and listed publicly, exactly as on a VPS.</p><h2>4. Bind and advertise the correct IP</h2><p>By default HLDS binds all interfaces, which is usually fine behind NAT. The mistake is forcing the <em>private</em> address on the command line. If you pass <code>+ip</code>, it must be the machine's LAN IP for binding — never the public IP, which the machine does not own:</p><pre>./hlds_run -game cstrike +ip 192.168.1.50 +port 27015 +maxplayers 16 +map de_dust2</pre><p>In most home setups you can omit <code>+ip</code> entirely and let it bind everything. Players connect to your <em>public</em> IP; the router translates that to the private one via your forward. See <a href="/tutorials/hlds-command-line-parameters">the command-line parameters guide</a> for the full flag list.</p><h2>5. Test from outside your network</h2><p>You cannot properly test from inside your own LAN — many routers do not loop a public-IP connection back inward (no NAT hairpinning), so it "fails" from your own PC while working fine for everyone else. Have a friend connect to your public IP, or use a phone on mobile data:</p><pre>connect YOUR_PUBLIC_IP:27015</pre><p>Find your public IP from the router's status page or any "what is my IP" service, not from the server machine's <code>ifconfig</code>, which shows the private one.</p><h2>6. Handle double-NAT and CGNAT</h2><p>Two common home situations block hosting even with a perfect forward:</p><ul><li><strong>Double-NAT</strong> — an ISP modem in router mode sits in front of your own router, so you forwarded on the inner router but the outer one still drops the traffic. Fix it by putting the ISP modem in bridge mode, or by forwarding 27015 on <em>both</em> devices in a chain.</li><li><strong>CGNAT (carrier-grade NAT)</strong> — the ISP shares one public IP across many customers, so you have no forwardable public address at all. No amount of local configuration fixes this. You need the ISP to give you a real public IP, or you tunnel out through a VPS with a public address. Mobile and many fibre connections are CGNAT by default.</li></ul><h2>Common errors</h2><ul><li><strong>Server works on LAN, invisible online</strong> — <code>sv_lan 1</code> is set, or the router forward is missing/wrong. Set <code>sv_lan 0</code> and re-check the forward's internal IP.</li><li><strong>Forward is correct but still unreachable, and you tested from your own PC</strong> — NAT hairpinning is disabled on your router. Test from an outside network before concluding it is broken.</li><li><strong>Bind error on startup</strong> — you passed the public IP to <code>+ip</code>. Use the machine's LAN IP or drop the flag.</li><li><strong>Only you can join, nobody else</strong> — likely double-NAT; forward on the outer modem too or bridge it.</li><li><strong>No public IP at all / IP starts with 100.64.x.x</strong> — you are on CGNAT. Contact the ISP for a public IP or host through a VPS tunnel.</li></ul><h2>Verification</h2><p>From an outside network, run <code>connect YOUR_PUBLIC_IP:27015</code> and confirm you join. Then check the server appears in the internet server browser once <code>sv_lan 0</code> has propagated. If the connection times out from outside but the server console shows it running, the traffic is being dropped before the machine — walk back through the forward, the double-NAT check, and finally the CGNAT test. For anything more than a small private server, a <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">VPS install</a> avoids all of this.</p> | |
| 13 | 13 |
