How to Run a CS 1.6 Server Behind NAT / a Home Router

Hosting a CS 1.6 server on a machine behind a home router means the server has a private LAN address (like 192.168.1.50) 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.

1. Give the server machine a static LAN IP

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 .50 to .51 after a reboot, your forward now points at nothing.

2. Forward the game port on the router

CS 1.6 uses UDP 27015 by default. In the router's port-forwarding section, add a rule:

Protocol:    UDP
External:    27015
Internal IP: 192.168.1.50   // your server machine
Internal:    27015

UDP is the game traffic and is mandatory. Forward TCP 27015 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.

3. Leave LAN mode off

A server with sv_lan 1 refuses outside connections and never registers with the master list. In server.cfg:

sv_lan 0

This is required for the server to be reachable and listed publicly, exactly as on a VPS.

4. Bind and advertise the correct IP

By default HLDS binds all interfaces, which is usually fine behind NAT. The mistake is forcing the private address on the command line. If you pass +ip, it must be the machine's LAN IP for binding — never the public IP, which the machine does not own:

./hlds_run -game cstrike +ip 192.168.1.50 +port 27015 +maxplayers 16 +map de_dust2

In most home setups you can omit +ip entirely and let it bind everything. Players connect to your public IP; the router translates that to the private one via your forward. See the command-line parameters guide for the full flag list.

5. Test from outside your network

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:

connect YOUR_PUBLIC_IP:27015

Find your public IP from the router's status page or any "what is my IP" service, not from the server machine's ifconfig, which shows the private one.

6. Handle double-NAT and CGNAT

Two common home situations block hosting even with a perfect forward:

• Double-NAT — 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 both devices in a chain.
• CGNAT (carrier-grade NAT) — 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.

Common errors

• Server works on LAN, invisible online — sv_lan 1 is set, or the router forward is missing/wrong. Set sv_lan 0 and re-check the forward's internal IP.
• Forward is correct but still unreachable, and you tested from your own PC — NAT hairpinning is disabled on your router. Test from an outside network before concluding it is broken.
• Bind error on startup — you passed the public IP to +ip. Use the machine's LAN IP or drop the flag.
• Only you can join, nobody else — likely double-NAT; forward on the outer modem too or bridge it.
• No public IP at all / IP starts with 100.64.x.x — you are on CGNAT. Contact the ISP for a public IP or host through a VPS tunnel.

Verification

From an outside network, run connect YOUR_PUBLIC_IP:27015 and confirm you join. Then check the server appears in the internet server browser once sv_lan 0 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 VPS install avoids all of this.