DHCP, DNS, and the Default Gateway: A Practical Small-Network Troubleshooting Guide

When a user says, “I am connected but there is no internet,” three services or settings often matter: DHCP, DNS, and the default gateway. A Wi-Fi or Ethernet connection only confirms that the device has a link. It does not prove that the device received usable network settings or can reach another network.

These parts work together, but each has a different job. Checking them in order helps avoid changing the wrong setting.

Start with the IP configuration

An IP address identifies a device on a network. A normal home or office address might look like 192.168.1.25 or 10.0.10.50.

The subnet mask defines which addresses are part of the local network. Devices in the same subnet can usually communicate locally. Traffic for another network normally needs to go through the default gateway.

On Windows, use ipconfig /all to inspect:

• IPv4 address.
• Subnet mask.
• Default gateway.
• DNS servers.
• Whether DHCP is enabled.
• The DHCP server, when one is listed.

Check these values together. One missing or incorrect setting can make the entire connection appear broken.

What DHCP provides

DHCP automatically supplies network settings to client devices. It commonly provides:

• IP address.
• Subnet mask.
• Default gateway.
• DNS servers.
• Lease time.

A DHCP scope is the pool of addresses available to clients. For example, a small network might hand out addresses from 192.168.1.100 to 192.168.1.200. A lease is the temporary assignment of one of those addresses to a device, and clients normally renew their leases automatically.

In a small network, DHCP may run on a router, firewall, or server. A homelab might use a home router, pfSense or OPNsense, Windows Server DHCP, or a Linux DHCP service. Running more than one DHCP server on the same network without a deliberate design can give clients inconsistent settings.

If a Windows device shows a 169.254.x.x address, it likely did not receive normal settings from DHCP. That is a DHCP-reachability clue, not a DNS problem. The cause might still be a cable, Wi-Fi connection, switch port, VLAN, driver, scope, relay, or DHCP service.

DHCP across VLANs

Each VLAN or subnet needs a way to reach DHCP. That may be:

• A DHCP server directly on that network.
• A DHCP relay or helper address.
• A router or firewall providing DHCP for each interface.

If a new VLAN has no working DHCP path, clients may connect but fail to receive usable IP settings. A small office that adds a switch and then finds that several PCs cannot get addresses may need to check the switch uplink, VLAN, or port configuration before assuming the DHCP service itself has failed.

What the default gateway does

The default gateway is the router, firewall, Layer 3 switch, or virtual gateway a client uses to reach networks outside its local subnet.

A device with a valid local IP address but no correct gateway may still reach some local resources while failing to reach websites, cloud services, or another office network. On Windows, the gateway appears under the active adapter in ipconfig output.

If the gateway is blank or wrong, check the DHCP-provided settings, any static configuration, the VLAN, and the router or firewall interface.

What DNS does

DNS translates names into IP addresses. It lets a computer find a website or internal service by name.

DNS is not the same as the gateway:

• The gateway routes traffic outside the local subnet.
• DNS resolves a name to an address.

If a device can reach an allowed IP address but cannot reach the corresponding service by name, DNS may be part of the problem. If the device has a 169.254.x.x address or no gateway, fix the basic IP configuration first.

A practical troubleshooting flow

1. Confirm the scope. Check whether the problem affects one device, several devices, one VLAN, or the entire network.
2. Inspect the active adapter. Run ipconfig /all and confirm the IP address, subnet mask, gateway, DNS servers, and DHCP status.
3. Look for an APIPA address. A 169.254.x.x address points toward DHCP reachability. Follow the focused APIPA troubleshooting guide if that symptom appears.
4. Test the local gateway. Use ping <gateway> where allowed. A failed reply is a clue, although a firewall may block ping.
5. Test permitted outside reachability. If the gateway works, test an approved external or remote IP address.
6. Test name resolution. Use nslookup with a domain or internal name allowed in the environment.
7. Compare with a known-good device. Check a working device on the same cable, Wi-Fi network, VLAN, or desk.
8. Check shared infrastructure when the scope is broad. Review DHCP service status, scope availability, VLAN support, relay configuration, and the relevant router, firewall, switch, or access-point path.
9. Escalate with evidence. Record the affected scope, IP information, tests performed, and results.

Reading common result patterns

• 169.254.x.x address: Investigate why DHCP did not reach the device.
• Valid IP but no default gateway: The device may reach its local subnet but not other networks.
• Gateway reachable but an outside IP is not: Investigate routing, upstream connectivity, or firewall policy.
• An IP works but a name does not: Investigate DNS resolution.
• Every client on one VLAN fails DHCP: Check the scope, relay, gateway interface, and VLAN path.

Common mistakes

• Treating “connected” as proof that the full network path works.
• Changing DNS before confirming the IP address and gateway.
• Assuming a failed ping always means the destination is offline.
• Running two DHCP servers on the same network without a deliberate configuration.
• Focusing on one client when several devices share the same symptom.

FAQ

Is DHCP required?

No. Static IP addresses can be used, but DHCP is easier to manage for most client devices.

Can DHCP provide DNS and gateway settings?

Yes. DHCP commonly provides both settings along with the IP address and subnet mask.

Is the default gateway always a router?

In many small networks it is a router or firewall. Larger environments may use a Layer 3 switch or virtual gateway.

Can the internet work when DNS is broken?

The underlying IP path may still work, but services that depend on names can fail and make the connection appear down.