Establish Network Connections

Getting a user online is one of the fastest ways IT support proves its value. When email won't send, printers can't connect, or cloud apps time out, the fix often starts with the network. This section aligns with CompTIA A+ Core 2 (220-1202), Domain 1, Objective 1.7, where you're expected to establish network connections quickly and safely.

You'll learn how to connect a device using wired Ethernet, Wi-Fi, VPN, and cellular (WWAN). Along the way, you'll see what to check first, what settings matter most, and how to confirm the connection works. The goal isn't theory, it's repeatable steps you can use at a help desk, on-site, or while supporting remote users.

Just as important, you'll practice the mindset the exam rewards: verify the link, confirm IP settings, then test access to the right resource. By the end, you should be able to spot common causes of failure (like bad cables, wrong SSID or password, captive portals, VPN misconfigurations, and weak signal) and apply fixes that hold up under time pressure.

Connection Basics

For CompTIA A+ Core 2 (220-1202), Domain 1, Objective 1.7, you need to recognize what any device must have before it can establish a network connection. In practice, that means three layers working together: a working network interface (Ethernet, Wi-Fi, or cellular), a valid path to another network (often a router or VPN), and correct addressing settings so traffic knows where to go.

Most connection tickets fail for simple reasons. The device either is not physically linked (bad cable, Wi-Fi off, airplane mode on), not allowed onto the network (wrong password, captive portal, VPN policy), or not configured correctly (IP or DNS issues). Start basic, confirm the link, then move up to settings.

Know your network types and when to use them

Network types sound abstract until you tie them to where the traffic goes. Keep the definitions simple, because Objective 1.7 focuses on how you connect (wired, wireless, VPN, WWAN), not on memorizing theory.

Here is a quick way to frame the three most common network scopes:

Network type	What it means in plain terms	Everyday example	Common Objective 1.7 connection method
LAN (Local Area Network)	A network in a small area, like one home or one office	A desktop plugged into a switch in an office	Wired Ethernet
WLAN (Wireless LAN)	A LAN that uses Wi-Fi instead of cables	A laptop joining "HomeWiFi" through a router	Wireless (Wi-Fi)
WAN (Wide Area Network)	A network that spans long distances, connecting many LANs	A branch office reaching the company network across the internet	VPN or WWAN/cellular

A LAN is usually the most stable because the signal stays on copper. When you plug a PC into an Ethernet port, you are typically joining a LAN. That is why wired connections often become the "known good" reference during troubleshooting. If Wi-Fi fails, a quick wired test can separate radio problems from routing or DNS problems.

A WLAN is still a LAN, but Wi-Fi adds extra failure points. Signal strength, interference, and security settings matter. Even when a user sees the Wi-Fi icon, they may be connected to the wrong SSID, stuck behind a captive portal, or connected with weak signal that drops under load.

A WAN connects networks over distance. In many small environments, the "WAN" is simply the ISP connection to the internet. In business settings, the WAN often includes private links and secure tunnels. This is where VPN fits. A VPN creates an encrypted path across the internet so a remote device can act like it is on the office network. Meanwhile, WWAN/cellular matters when Wi-Fi is unavailable or untrusted, such as on travel or at a client site.

A useful mental model: LAN is the building, WLAN is the building without cables, WAN is the road system between buildings.

IP addressing and DNS, the two settings that break everything

Once the device joins a network, it still needs correct addressing to communicate. Four settings explain most "connected but not working" cases: IP address, subnet mask, default gateway, and DNS.

An IP address identifies a device on a network, similar to a street address. The subnet mask tells the device which addresses are local. If the destination is local, the device talks directly. If it is not local, the device sends traffic to the default gateway (usually the router). DNS translates names (like www.example.com) into IP addresses. Without DNS, the internet can work by IP but "the web" feels broken.

In most environments, DHCP supplies these settings automatically. DHCP reduces mistakes and prevents address conflicts. It also changes behavior in a predictable way, because clients renew leases and stay aligned with the network's plan.

Static settings can still make sense, but they raise risk. A bad static configuration can strand a device even when Wi-Fi or Ethernet shows "connected." Common causes include:

Wrong IP or subnet mask: The device may fail local access, because it thinks the router is "not local."
Wrong default gateway: Local devices work, but nothing beyond the subnet works.
Wrong DNS server: The device can reach IPs, but websites fail by name.

Quick symptom patterns help you narrow the fault without deep command work:

Can reach the router, but not websites: Often a gateway, ISP, or VPN routing issue. It can also be a captive portal.
Can open sites by IP, but not by name: Strong sign of DNS failure.
Can resolve names, but pings fail to some targets: Could be firewall rules, VPN policy, or blocked ICMP. Name resolution alone does not prove full access.
Self-assigned address behavior (often 169.254.x.x): Often indicates DHCP failure, such as a bad cable, wrong VLAN, or blocked DHCP.

The key point for Objective 1.7 is practical: if a wired or wireless link looks fine, check DHCP vs static next. Many real tickets end when you switch back to DHCP and renew the settings, or correct DNS to the expected servers.

A quick pre-check list before changing settings

Before you edit IP, DNS, or VPN profiles, run a short pre-check. This prevents avoidable mistakes and keeps your troubleshooting clean. It also matches the exam mindset, start with simple causes, then move to configuration.

Use this flow in order:

Confirm airplane mode is off (especially on laptops and tablets).
Confirm the correct adapter is enabled, Wi-Fi on or Ethernet connected.
If using Wi-Fi, verify the correct SSID (not a guest network by accident).
If using Ethernet, reseat the cable and check the port is seated on both ends.
Look for link lights on the NIC, switch, or dock (no lights often means no physical link).
Re-enter the correct Wi-Fi password (watch for saved, outdated credentials).
Reboot the device (fast and often effective after sleep or driver issues).
If policy allows, reboot the modem/router or access point, then wait for it to fully return.
Only then, check IP and DNS settings (DHCP vs static, correct gateway, correct DNS).
If remote access is involved, confirm the VPN status (connected, correct profile, no split-tunnel mismatch).
If using mobile data, confirm WWAN/cellular is on and the plan has signal and data service.

This order matters because it protects you from chasing the wrong problem. A wrong SSID can look like a DNS issue. A loose cable can look like a DHCP failure. When you follow a consistent pre-check, you reduce repeat tickets and you document clear reasoning.

Change settings last. First, prove the device has a working link and joined the right network.

Wired Connections

For CompTIA A+ Core 2 (220-1202), Domain 1, Objective 1.7, wired Ethernet is the quickest way to prove a device can join a network. A good cable link removes most wireless variables, such as weak signal or interference. In practice, you want a connection that works on the first try because it saves time, reduces repeat tickets, and gives you a stable baseline for later testing (DNS, gateway access, or VPN reachability).

A wired setup is simple: the device's network adapter connects to a wall jack or a switch port, then the network provides an IP configuration (usually through DHCP). When any part of that chain fails, the symptoms tend to be clear if you know where to look.

Plug-in steps and what "link" tells you

A wired connection has a physical path you can trace with your eyes and hands. Most office setups follow one of these two patterns:

PC to wall jack: PC (or dock) → Ethernet cable → wall jack → building cabling → patch panel → switch.
PC direct to switch: PC (or dock) → Ethernet cable → switch port.

Start by seating both ends of the cable firmly. A half-click connection is common on laptops and docks, especially when the cable gets pulled. Next, check for link indicators, because they tell you whether the physical layer works.

Here is what "link" typically looks like in the real world:

Link lights on the NIC, dock, or switch: A solid or blinking light usually means the port detects a connection. Blinking often indicates traffic, not just a link.
Operating system network icon: It may show "connected," "no internet," or "disconnected." Treat this as a clue, not final proof.
Speed indicator (if shown): Some switches show 10/100/1000 Mbps by color. A lower speed than expected can point to a damaged cable pair.

When the link light stays off, focus on three likely causes: cable, port, or adapter. In other words, the device and switch are not "handshaking" at the physical level.

A simple, repeatable approach is to swap only one thing at a time:

Try a known-good Ethernet cable.
Move to a known-good port on the wall jack or switch.
Test with a known-good adapter, such as a different dock or USB-to-Ethernet adapter.

If link lights appear after a swap, you found the weak link. If link lights never appear, suspect the adapter is disabled, the port is shut down, or the wall jack has a wiring issue.

No link light usually means no physical connection, not a DNS problem, not a browser issue, and not an "internet outage."

Even with link lights, you still need to confirm the device negotiated correctly. A device can show link but still fail to pass traffic if the port configuration blocks it. That is why you should also glance at the network status in the OS. "Connected" plus an assigned IP address is a stronger sign than "connected" alone.

DHCP vs static on wired networks

On most wired networks, clients use DHCP because it reduces mistakes and scales cleanly. With DHCP, the network assigns the IP address, subnet mask, default gateway, and DNS servers. As a result, the PC can join almost any standard port and work without manual edits.

Static IP settings still matter, but they belong to specific use cases:

Printers and copiers: A static IP prevents the address from changing, which helps print queues stay stable.
Servers and network appliances: Stable addressing supports monitoring, remote access, and firewall rules.
Lab setups and isolated networks: Static settings help when DHCP is not present or when testing requires fixed values.

The risk with static settings is not subtle. A single wrong value can make the device look "connected" while nothing works beyond the local link. Two errors cause the most wasted time:

Wrong default gateway: Local devices may respond, but the internet and remote subnets fail.
Wrong DNS server: Websites and cloud apps fail by name, even if the internet works by IP.

Static settings also increase the chance of an IP conflict, where two devices share the same address. That can cause random drops, duplicate address warnings, or intermittent access that comes and goes.

A safe workflow is simple and disciplined: document current settings before changing anything. If you need to switch from static to DHCP (or back), record what you started with so you can undo changes quickly.

A practical documentation habit includes:

IP address and subnet mask
Default gateway
DNS servers
Any notes about "special" values (for example, a DNS server that points to an internal domain controller)

After that, prefer the least risky fix first. If a user reports a sudden outage on a normal office port, DHCP is usually the expected state. Switching a general user workstation back to DHCP often resolves issues caused by accidental static entries, old imaging templates, or VPN client changes that did not revert cleanly.

Still, avoid assumptions in managed environments. Some networks assign access based on device type or port. If a device used to require static settings for a lab or a secure segment, changing it can break access rules. That is another reason documentation comes first.

Common wired problems and quick fixes

Wired problems often look dramatic to users, but most have quick, visible causes. The goal is to clear the easy faults first, then escalate with clean evidence.

Start with these first checks, because they solve a high percentage of tickets:

Reseat the cable on both ends until it clicks.
Swap the cable with a known-good one.
Try a different port (on the switch or wall jack).
Restart the device if the adapter looks stuck after sleep or docking changes.

If those steps fail, the next issues are still common, but they require sharper observation.

Bad cable (internal break or wrong type)
A cable can look fine and still fail. Repeated bending near the connector is a classic cause. In addition, some environments still have older cabling that cannot hold gigabit speeds. If the link comes up at a lower speed than expected, replace the cable and re-test.

Bent pins, damaged plugs, or worn wall jacks
Look closely at the RJ-45 plug. A broken locking tab causes loose fits. Bent contacts can prevent a pair from making contact. Wall jacks also wear out, especially in shared rooms.