Network security troubleshooting: first principles

The fix that arrives first is usually the wrong one. When the printer disappears, the tempting fix is to put it back on the main network.

When the VPN connects but nothing works, the tempting fix is to open everything. Each fix makes the symptom go away by undoing the protection, and each is why many offices have a segmented network on paper and a flat one in practice.

The cases below are ordered by how often they happen. Each gives the symptom, the first thing to check, the likely cause, the fix that keeps the protection, and the fix to refuse.

What to take away

The printer vanished after segmentation

First check: from a work laptop, open the printer's page by address rather than by name.

Likely cause: the printer was found by a broadcast that does not cross segments, or the rule between the work segment and the device segment allows nothing.

Fix: add the printer by address on the laptops, and allow only the print port from the work segment to the device segment. Test on one laptop first.

Refuse: moving the printer back among the work machines, or allowing everything between the two segments.

The VPN connects and nothing is reachable

First check: can the connected device reach the router's own address? If yes, the tunnel works and the problem is a rule. If no, the problem is the tunnel.

Likely cause: the remote segment overlaps with the user's home network range, or the rule from the VPN segment to the work segment was never written.

Fix: give the VPN its own address range that no home router uses by default, and write the specific rule from the VPN segment to what remote users need. Test with one user.

Refuse: allowing the VPN segment to reach everything, including the device segment.

A guest can see the office

First check: put a phone on the guest network and open the printer's page. If it loads, isolation is not doing its job.

Likely cause: client isolation is enabled on the main wireless network but not the guest one, or the guest network is not on its own segment at all and the setting only isolates wireless clients from each other.

Fix: put the guest network on its own segment with a deny rule toward everything internal, and turn isolation on for that network specifically. Repeat the phone test.

Refuse: deciding that guests are few and it does not matter. This is the case that turns a visitor's infected phone into everyone's problem, and the United Kingdom National Cyber Security Centre's guidance on preventing lateral movement is the reason the segment exists.

Everything slowed down after enabling inspection

First check: disable inspection for one segment only and see whether that segment recovers.

Likely cause: the box is a tier smaller than its label once inspection is on, or a single application is generating traffic the inspection engine struggles with.

Fix: keep inspection on the segments where it earns its place, typically the device segment and the way in, and off the work segment if the box cannot manage it. Or buy the tier that can. Test one segment at a time.

Refuse: switching inspection off everywhere and leaving the subscription running.

A site or tool is blocked by the filter

First check: which category the filter put it in, and whether the same request fails on a second device.

Likely cause: a legitimate service classified into a blocked category, or a device using its own resolver on one path and the filter on another.

Fix: allow the specific name, not the category, and record who asked and why. If the category itself is wrong for your policy, change the policy in writing first.

Refuse: disabling the filter for the person who complained loudest.

Locked out of the administrator interface

First check: try from a wired connection directly to the box, because wireless changes often cut the administrator's own connection.

Likely cause: you changed the network you were administering from, or the management interface was restricted to a segment you are no longer on.

Fix: wired laptop, direct cable, the address printed on the box. If that fails, the second administrator's credentials. If that fails, the exported configuration and a reset. Test that you can still log in after every future change, before closing the browser.

Refuse: enabling remote management from the internet to get around it.

A rule change had no effect

First check: the rule order. Most equipment evaluates rules top to bottom and stops at the first match.

Likely cause: a broader rule above the new one already decided the outcome, or the change was saved but not applied.

Fix: move the specific rule above the general one, apply, and test with one device. Read the whole list once; if it cannot be read in sentences, rewrite it while you are there.

Refuse: adding a third rule to work around the second.

Wireless drops on one device after the security upgrade

First check: whether the device supports the newer wireless security mode at all.

Likely cause: an older device that only speaks the previous standard.

Fix: a transitional mode that allows both on that network, or a separate network on the older standard for the one device, kept on the device segment. Never downgrade the whole staff network for one printer.

Devices get the wrong address

First check: what address a freshly connected laptop receives, and from which server.

Likely cause: a second device on the network is handing out addresses: a consumer router someone plugged in as a switch, or an old access point in router mode.

Fix: find the device by its address, unplug it, and put a rule on the switch that only the real server may answer address requests if the switch supports it.

Refuse: leaving it because it usually works.

The log is empty when you need it

First check: the retention setting and whether logging is enabled per rule.

Likely cause: on-box retention measured in hours, or rules that deny silently.

Fix: turn on logging for the deny rules that matter, send logs to storage elsewhere, and note the retention in days. The United States National Institute of Standards and Technology's guide to computer security log management is the reference for deciding which of those questions to answer first. This one is best fixed before it is needed, which is why the check list in network security includes it.

The method behind every case

Two situations deserve a different response. If a symptom appears with no change to explain it, the cause may not be a rule.

Examples include new forwarding rules you did not add, a new administrator account, or a device on the network nobody recognizes. Stop troubleshooting; start the sequence in incident response, because you may be looking at someone else's change.

And if the fix requires touching the router's own credentials, treat that as the privileged operation it is, in the way identity and access describes, rather than something to be done from a shared login in a hurry.

Common questions

Everything works if I put the device back on the main network. Why not do that?

Because the device is on its own segment precisely so that it cannot reach the main network. Putting it back solves the symptom by removing the reason for the setup.

How do we know a change did not break something we have not noticed?

Keep the short list of tests from the setup evening and run it after every change: guest cannot print, device segment cannot see shares, nothing answers from outside, one person can get in. Five minutes.

Should we call the reseller or the internet provider first?

Neither until you can say which segment, which device, and which rule. Half of the calls resolve during the writing of that sentence.

The configuration is too complex to understand. What now?

Export it, keep the export, and rebuild from the drawing on a quiet evening using the order in network security setup. A configuration nobody can read in sentences will be troubleshot by guesswork forever.