Client vs server networking
Topic: Networking basics
Summary
Clients initiate connections to a server's IP and port; servers listen on a port and accept connections. Learn the roles so you can configure listen addresses, firewall rules, and NAT correctly and debug 'connection refused' vs 'no route to host.' Use this when deploying or troubleshooting any service.
Intent: How-to
Quick answer
- Server: binds to an address and port and listens; typically one well-known port (e.g. 22, 80); must be reachable from clients (firewall allow inbound, NAT port forward if behind NAT).
- Client: picks an ephemeral source port and connects to server IP:port; outbound only; needs route and possibly NAT to reach the server; firewall must allow outbound and often 'established' for return traffic.
- Connection refused: server not listening or firewall blocking. No route to host: routing or server down/unreachable. Timeout: path broken, firewall dropping, or server not responding.
Steps
-
Define server role
The server process binds to an address (0.0.0.0 for all interfaces or a specific IP) and a port, then listens. Incoming SYN packets to that IP:port are accepted and a connection is established; the server then serves the client.
-
Define client role
The client initiates: it picks a source IP and an ephemeral port and sends a SYN to the server's IP and port. The client needs a route to the server; if behind NAT, the router does SNAT so the server sees the router's IP.
-
Apply to firewall
Server host: allow inbound to the listen port (e.g. 22, 80). Client host: allow outbound; allow established/related so replies are permitted. For a server behind NAT, the router must forward the port and allow the traffic.
-
Debug by role
Connection refused: nothing listening on that port on the server (or firewall drop). No route to host: no route to server or server down. Timeout: path broken, middlebox dropping, or server not responding.
Summary
Servers listen on an address and port; clients initiate connections to the server’s IP and port. Firewall and NAT rules must allow server inbound and client outbound (and established return traffic). Use this when configuring or debugging any TCP or UDP service.
Prerequisites
- None; this is a foundation concept.
Steps
Step 1: Define server role
The server binds to an address (0.0.0.0 for all interfaces, or a specific IP) and a port, and calls listen. When a SYN arrives for that IP:port, the kernel accepts it and the server can serve the client. The server must be reachable: correct listen address, firewall allowing inbound to that port, and if behind NAT, port forwarding.
Step 2: Define client role
The client chooses a source port (ephemeral) and connects to the server’s IP and port. The client needs a route to the server. If the client is behind NAT, the router rewrites the source so the server sees the router’s IP; return traffic is translated back.
Step 3: Apply to firewall
On the server host: allow inbound to the listen port. On the client host: allow outbound; allow established/related so return packets are permitted. For a server behind NAT, configure port forwarding and allow the forwarded traffic.
Step 4: Debug by role
- Connection refused: No process listening on that port on the server (or firewall dropping before the server).
- No route to host: No route to the server or the server (or path) is down.
- Timeout: Path broken, firewall or NAT dropping, or server not responding.
Verification
- You can state the difference between client and server; you know that “connection refused” means no listener (or drop) and “no route to host” means routing or reachability.
Troubleshooting
Server not reachable from internet — Check listen address (0.0.0.0 vs 127.0.0.1); firewall allow; if behind NAT, port forward and forward to the correct internal IP and port.
Client cannot connect — Check client has route to server; outbound and established allowed; if server is behind NAT, the client must connect to the public IP and forwarded port.