Linux Networking for Windows Users: IP, Routes, DNS and Connections

Start with the network state, not with a reset command

When a Windows machine cannot reach the network, many users instinctively reach for a reset sequence. On Linux, it is usually more useful to inspect the current state first: which interfaces exist, whether they are up, which addresses are assigned, which route is selected, which DNS resolver is in use and whether a local service is listening on the expected port.

This approach preserves evidence. If you change several settings before observing the problem, you may fix the symptom while losing the information that explains why it happened.

ipconfig maps to several Linux views

Windows ipconfig combines information that Linux exposes through multiple interfaces. The ip utility is the modern starting point for addresses, links and routes. ip addr shows addresses, ip link shows interfaces and link state, and ip route shows the routing table.

That separation is useful because each command can focus on one layer. If an interface is down, address troubleshooting comes later. If the address is correct but the default route is missing, changing DNS will not solve the problem.

route print becomes ip route

The routing table decides where packets go. A Linux system may have several routes for local subnets, VPNs, containers and a default gateway. Read the route that matches the destination rather than assuming the default route is always used.

For a quick test, compare local-link reachability, gateway reachability and an external IP address. If an external IP works but a hostname does not, the routing layer is probably not the first place to look next.

netstat is usually replaced by ss

Linux still has older networking utilities on some systems, but ss is the modern tool for inspecting sockets. It can show listening TCP and UDP ports, established connections and process information when permissions allow it.

When troubleshooting a server application, first confirm that the process is listening on the expected address and port. A service bound only to 127.0.0.1 will not accept connections arriving on another interface even if the firewall is open.

DNS has a resolver layer of its own

A Linux desktop may receive DNS settings from DHCP, a VPN, NetworkManager or a local resolver service. Systems using systemd-resolved can expose resolver state through resolvectl. Other distributions may use different arrangements, so do not assume that editing /etc/resolv.conf directly is the correct permanent fix.

A useful troubleshooting split is: test an IP address first, then test a hostname. If IP connectivity works but name resolution fails, inspect the resolver configuration and the DNS server being queried.

NetworkManager is common on desktops and laptops

Many Linux desktop distributions use NetworkManager. Its command-line interface, nmcli, can show devices, active connections and saved connection profiles. Graphical network settings often modify the same underlying profiles.

Server distributions may use different network configuration systems. Follow the distribution documentation rather than copying a desktop-specific configuration file into a server installation.

Firewall tools differ by distribution and policy

Linux packet filtering is provided by kernel networking facilities, while user-facing management tools vary. Fedora commonly uses firewalld. Ubuntu may use UFW in some workflows. Lower-level nftables rules may also be present. These layers are not interchangeable configuration files.

Before adding a firewall rule, verify that the application is actually listening and that the route is correct. Opening a port cannot make a stopped service start, and a service listening only on localhost will still be unreachable remotely.

A practical troubleshooting sequence

1. Confirm that the interface exists and is up.
2. Inspect the assigned IPv4/IPv6 addresses and prefix lengths.
3. Inspect the route chosen for the destination.
4. Test the local gateway or next hop.
5. Test an external IP address.
6. Test DNS resolution separately.
7. For server problems, confirm the listening socket and bind address.
8. Only then inspect firewall rules, VPN policy or application configuration.

This sequence moves from the lowest useful layer toward the application and avoids changing unrelated settings.