How to Configure a Router and Switch for a Small Office Network

 Almost every badly built small office network was assembled in the same wrong order: hardware first, plan never.

Someone buys equipment, racks it, cables it, and then begins configuring — discovering halfway through that the addressing conflicts with the VPN, the switch has no management address, and nobody wrote down which port serves which desk. Six months later the person who built it has left, and nobody can safely change anything.

Building a small office network properly costs perhaps two extra hours at the start. This is the order that works.

Step Zero: The Plan on Paper

Before touching a device, write down:

• The address range, chosen to avoid conflicting with home routers your remote users will have.
• The subnets and what each is for, with gateway addresses assigned.
• Which devices need fixed addresses, and whether they will be DHCP reservations or typed static.
• The VLAN scheme, if you are using one.
• What internet service you have, and how it is delivered — static address, DHCP, or authenticated session.
• What must be reachable from outside, if anything.
• Administrative credentials, stored somewhere secure and shared with at least one other person.

This takes twenty minutes and prevents most of what goes wrong later.

Physical Layout

Keep the cabling logic simple, because complexity here compounds.

The internet service enters the building and connects to your router's external interface. The router's internal interface connects to the switch. Everything else connects to the switch — computers, printers, access points, servers.

Do not chain switches unnecessarily, do not connect two switch ports to each other, and do not let users plug consumer routers into wall sockets. That last one introduces a competing DHCP server and is a recurring source of chaos.

Label both ends of every cable as you install it. This is tedious and it is the single most appreciated thing you can do for whoever supports the network later.

Router Configuration

Work through these in order, because later steps depend on earlier ones.

The external interface. Configure according to what your provider supplies — a static address with mask and gateway, DHCP if they assign dynamically, or PPPoE with credentials if the service requires authentication. Confirm the router obtains connectivity before proceeding.

The internal interface. Assign the gateway address from your plan, matching the subnet you chose. This is the address every internal device will use as its default gateway.

DHCP. Define the scope, set the pool boundaries, and configure exclusions covering any statically addressed devices. Set the DNS servers that clients should use, and the domain name if you have one. Choose a lease duration — eight days suits a stable office, shorter for high turnover.

DNS. If you run internal DNS servers, point clients at them and configure those servers to forward external queries. If you do not, point clients at a public resolver directly. Never point domain-joined machines at public resolvers.

Address translation. Usually enabled by default, converting internal private addresses to your single public one. Verify it is working rather than assuming.

Firewall rules. The default posture should be: outbound permitted, inbound denied except what you explicitly publish. Resist the temptation to open ports "temporarily."

The Router Settings That Actually Matter for Security

These are the ones that get skipped, and each has featured in real incidents:

1. Change the default administrator password immediately, before connecting the device to the internet. Automated scanning finds new devices within minutes.
2. Disable remote management on the external interface. If you need remote access, use a VPN. Management exposed to the internet is the single most common way small business firewalls are compromised.
3. Update the firmware before deployment, and establish a routine for checking afterwards.
4. Disable UPnP unless something specifically requires it. It allows internal devices to open inbound ports without your knowledge.
5. Disable WPS on any wireless capability.
6. Turn off unused services — the built-in web server on the external side, legacy protocols, anything you are not using.
7. Enable logging and send it somewhere that survives the device being replaced.

Switch Configuration

Unmanaged switches need nothing, which is their appeal and their limitation. A managed switch requires configuration and repays it many times over.

Management address. Assign an address on your management subnet so you can reach the switch. Without this, you cannot configure or monitor it, and a switch you cannot see is a switch you cannot troubleshoot.

Administrator credentials. Change defaults. Create individual accounts if the platform supports it.

Firmware. Update before deployment.

Spanning tree. Leave it enabled. It prevents loops, which are catastrophic — a loop in a switched network produces a broadcast storm that takes the segment down completely within seconds. Enable portfast, or the equivalent edge port setting, on ports connecting to end devices so they come up immediately.

Disable unused ports. An enabled port in an accessible area is an invitation. Shutting them down takes minutes and removes an entire category of risk.

Port descriptions. Label each port in the configuration with what it connects to. Six months later this will be the most useful thing in the file.

Adding VLANs

If you are segmenting — and most offices with more than twenty people should be — the sequence is:

• Create the VLANs in the switch's VLAN database.
• Assign access ports to the appropriate VLAN, one VLAN per port for end devices.
• Configure the link to the router as a trunk, carrying the VLANs that need to reach it.
• Set the native VLAN on the trunk to an unused VLAN, matching on both ends.
• Restrict the allowed VLAN list on the trunk to only those required.
• Create the routing interfaces on the router or Layer 3 switch, one per VLAN, each acting as that VLAN's gateway.
• Create DHCP scopes for each VLAN, with relay configured if the DHCP service sits elsewhere.

Test each VLAN individually before moving to the next. Building all of them and then testing produces a debugging session rather than a deployment.

Wireless

Access points connect to switch ports, typically drawing power over the same cable.

The configuration decisions that matter:

• Use WPA3 where supported, WPA2 with a strong passphrase otherwise. Never leave a network open, and never use WEP.
• Create a separate guest network with client isolation enabled, placed in its own VLAN with no route to internal resources.
• Plan channels deliberately. In the 2.4 GHz band use only channels 1, 6, and 11. In 5 GHz, spread access points across available channels rather than letting them all choose automatically and collide.
• Reduce transmit power rather than maximising it. Access points shouting at full power interfere with each other and with neighbours, and a client cannot shout back as loudly.
• Place access points for coverage, not convenience. The ceiling in the middle of a space beats the cupboard by the door.

Choosing the Hardware

Since the plan comes first, hardware selection becomes a matter of matching it rather than guessing.

The router or firewall. Size it by throughput with inspection features enabled, not by the headline figure on the box. A device rated for a gigabit of raw forwarding may manage a fraction of that with content inspection active, and that lower number is the one that matters. Check that it supports the number of VLANs and VPN connections you planned for.

The switch. Count the ports you need today, then add capacity — a 24-port switch in a 20-person office is already full on the day it is installed. Decide whether you need Power over Ethernet, and if so, check the total power budget rather than just the per-port rating. Eight access points drawing thirty watts each will exhaust a modest budget.

Managed or unmanaged. Unmanaged switches are cheaper and blind. If you want VLANs, monitoring, port security, or any ability to diagnose a problem remotely, you need managed. The price difference is small relative to a single site visit.

Access points. Count by coverage area and device density rather than by floor area alone. A meeting room holding thirty people needs capacity a corridor does not, regardless of square metres.

One further consideration: buy equipment from a single vendor family where you can. Mixed environments work, and they cost you the integration and single-pane management that makes a small team effective.

Testing Before You Hand It Over

1. Confirm a client receives the right address, mask, gateway, and DNS from DHCP.
2. Ping the gateway from a client.
3. Ping a public IP address to confirm routing and translation.
4. Resolve a hostname to confirm DNS.
5. Test each VLAN independently, and confirm that segments which should not reach each other genuinely cannot.
6. Verify the guest network has internet access and no internal access.
7. Test wireless in the far corners, not just next to the access point.
8. Confirm any published services are reachable from outside.
9. Reboot the router and verify everything returns automatically.

That final test is the one people skip, and it is the one that catches configuration saved in running memory but never written to permanent storage.

Backup and Documentation

Export the configuration from every device and store it somewhere that is not on this network. A configuration backup on a file server behind the firewall you are trying to rebuild is not a backup.

Document, at minimum: the address plan, VLAN assignments, port map, administrative credentials location, internet service details and provider contacts, and a simple diagram.

Then repeat the backup after every change. A configuration exported once at installation and never again describes a network that no longer exists.

The Mistakes That Recur

• Using 192.168.1.0/24, guaranteeing VPN conflicts later.
• No management address on the switch, making it invisible.
• Leaving default passwords on any device.
• Remote management exposed to the internet.
• Unused ports left enabled in reception areas.
• No configuration backup, discovered when hardware fails.
• Building everything before testing anything.
• Undocumented port assignments, turning every future change into an investigation.

None of these is difficult to avoid. All of them are common, and each one turns a straightforward small office network into something the next person will dread touching.