Network misconfigurations: IP, DNS, DHCP and VLANs

Why this matters

When the cable is good, the link light is on and the server still cannot be reached, the problem is almost always configuration. The administration domain covered how addressing, DNS, DHCP and VLANs should be set up. This lesson covers how each goes wrong, the symptoms each produces, and how to tell them apart, since several of them look identical from the user's side: the server "cannot be reached".

Work through the layers in order. There is no point examining DNS records for a server whose default gateway is wrong, or firewall rules on a server sitting in the wrong VLAN. The lesson follows that order: addressing, then name resolution, then DHCP, then VLANs, and finally the firewall that may be blocking traffic that everything else would deliver.

The lesson

A wrong address, mask or gateway

Each part of a server's IP configuration produces a characteristic symptom when it is wrong.

• Wrong IP address. An address in the wrong subnet leaves the server unable to reach anything, since it believes its neighbours are elsewhere. An address already in use by another device causes an IP address conflict: Windows warns of a duplicate address, and both devices suffer intermittent connectivity as switches and neighbours learn one MAC address and then the other.
• Wrong subnet mask. The server miscalculates which addresses are local. It may reach some neighbours and not others, or try to reach local machines through the gateway, or remote ones directly, producing confusing, partial failures.
• Wrong or missing default gateway. The server can reach everything on its own subnet, but nothing beyond it. This is the clearest pattern of all: local works, remote fails.

Check the configuration with ipconfig /all on Windows, or ip addr and ip route on Linux, and compare it with the documented configuration, as the addressing lesson recommended recording it.

Then test outward, one step at a time: ping the loopback address, then the server's own address, then the default gateway, then a remote address, then a remote name. The first step that fails points to the layer with the problem.

DNS records pointing the wrong way

If the server can be reached by IP address but not by name, or by name but at the wrong machine, the problem is DNS.

Common DNS faults:

• Missing or wrong A records: a record never created, deleted, or still pointing at an old address after the server moved. The DNS lesson's TTL planning exists to prevent the last case.
• Stale cache: the record is right on the authoritative server, but resolvers and clients still hold the old answer until their cached copy expires.
• Wrong DNS servers configured on the server or clients, such as an external resolver that knows nothing about internal names, or an address of a DNS server that no longer exists.
• Missing SRV records in Active Directory, which stop clients finding domain controllers and break logons while every server appears to run correctly.
• Missing PTR records, breaking services that check reverse lookups.
• A hosts file entry overriding DNS on one machine.

Diagnose with the DNS lesson's comparison: query the authoritative server and the client's resolver directly with nslookup or dig, and compare the answers with what the record should be. Flush the client cache with ipconfig /flushdns or resolvectl flush-caches once the record is corrected.

DHCP scope exhaustion and rogue DHCP servers

DHCP problems usually appear as clients that cannot get an address, or get the wrong one.

Scope exhaustion. When every address in a scope is leased, new clients receive no answer. Windows and many other clients then assign themselves an APIPA address in the 169.254.0.0/16 range, which lets them talk only to other self-assigned devices. A 169.254 address on a machine that should use DHCP is therefore a strong clue that DHCP failed. Causes include a scope too small for the number of devices, lease times too long for a network where devices come and go, and stale leases. Enlarge the scope, shorten lease times, or remove stale leases.

DHCP server unreachable. If clients on a subnet other than the DHCP server's get no addresses while local clients do, check the DHCP relay, or IP helper, on that subnet's router, as the DHCP lesson described. Also check that the DHCP service is running and, in Active Directory, that the server is authorised.

Rogue DHCP servers. An unauthorised DHCP server, such as a consumer router plugged into the network or a misconfigured lab machine, answers clients with wrong addresses, gateways or DNS servers. Symptoms are clients with addresses from an unexpected range, or the wrong gateway, often intermittently, depending on which server answers first. Find it by checking which server issued the lease, shown in ipconfig /all, and tracing that address or MAC to a switch port. DHCP snooping on the switches prevents it recurring.

VLAN mismatches and trunk misconfiguration

A server in the wrong VLAN has a working link and a correct configuration, and still cannot reach anything, because it is on a different logical network from everything it expects. It may also receive a DHCP address from the wrong scope, which is a useful clue.

Common VLAN faults, as the VLAN lesson warned:

• an access port assigned to the wrong VLAN;
• a server sending tagged frames to an access port, or untagged frames to a trunk expecting tags;
• the VLAN missing from the trunk's allowed list, so traffic for it is not carried between switches;
• a native VLAN mismatch between the two ends of a trunk, which some switches log as a warning;
• on virtualisation hosts, a guest's virtual NIC given the wrong VLAN ID on the virtual switch.

Check the switch port's mode, VLAN and allowed list, with commands such as a switch's show interfaces or show vlan output, and compare the server's or guest's VLAN configuration with the design. A useful test is whether other devices in the same VLAN can reach each other. If they can, and the server cannot reach them, the server's port or tagging is the problem.

Firewall rules blocking legitimate traffic

When addressing, DNS and VLANs are all correct, and a particular service still cannot be reached, the most likely cause is a firewall rule: on the server itself, or on a network firewall along the path.

Symptoms that point to a firewall:

• the server answers ping but a specific port does not respond, or the reverse, since ICMP and service traffic are allowed separately;
• a service works from some networks or hosts and not others;
• connections time out, rather than being refused. A refusal means the packet reached the server and nothing was listening, while a timeout often means something dropped it.

To diagnose:

• test the exact port with Test-NetConnection with -Port on Windows, or nc -zv or curl on Linux;
• check that the service is listening on the port, and on the right address, with netstat or ss, as the application lesson described;
• review the host firewall: Windows Defender Firewall's rules and logging, or firewall-cmd --list-all and nft list ruleset on Linux;
• check network firewalls and cloud security groups on the path, and their logs, which usually record denied traffic.

Firewall problems often follow changes: a new rule, a hardening baseline applied, or a new server that was never added to the rules. The change records, as ever, are the first place to look. When fixing, add a rule for the specific port and source that need it, and resist disabling the firewall "to test" on a production server.