← All coursesBack to the simulator →

When the network breaks: troubleshooting

Method instead of guessing: turning a complaint into a fault description, scope, bottom-up and top-down approaches and halving the problem. Then layer by layer: cable, port and admin down, an access port in the wrong VLAN and a trunk without the allowed VLAN, address, mask, gateway and a missing route, the name-versus-address test, a silent resolver and a stale cached answer, and finally the default deny and the shadowing rule on a firewall – including isolation, documentation and escalation when nothing helps.

This is a text preview of the lessons for reading. The full version – an interactive simulator with animations, exercises and quizzes – runs in the app.

▶ Launch the interactive version

Lesson 1: Method instead of guessing

What actually happened

PC-APC-BSWGWFWWEBDNSuser reports: “the internet is down”

Before you start: this course builds on basics from the beginner courses (addresses and mask, gateway, VLANs, ports, DNS, firewall) – if any feels unfamiliar, check those first. “The internet is down.” As a network admin you will hear this sentence more than any other – and it is simultaneously the least useful piece of information in the world. Before you touch a single device, you need to turn it into a fault description you can work with. Ask four things. Who has the problem: one person, one department, or the whole building? What exactly fails: a specific application, a specific website, or absolutely everything? Since when has it failed and what changed before that – a new wall socket, a new device, new rules, a replaced cable? And finally: did it ever work? A new thing that never worked is almost always a configuration mistake; a thing that worked this morning is a fault or someone’s change. While doing this, separate the symptom (what the user sees – “the page will not load”) from the impact (what it means for the business – “nobody can invoice”). The symptom helps you search, the impact tells you how much to hurry. And the most important habit right from the start: write down what you found and what you tried. In an hour you will not remember whether you already re-plugged that cable.

Step by step

  1. It starts with a sentence that says almost nothing. Your first job is not to fix, but to find out what actually happened.
  2. Ask four things: who, what exactly fails, since when and what changed before. Only that is a fault description.
  3. A new thing that never worked is usually a configuration mistake. A thing that worked this morning is usually a fault or someone’s change.
  4. Separate the symptom from the impact and write everything down. Without notes you will not know in an hour what you already tried.

Scope: one user, or the whole network?

PC-APC-BSWGWFWWEBDNSonly PC-A: search at it (cable, port, address)

The second question after “what happened” is how far it reaches. The scope of a fault is the cheapest and most powerful tool you have: it narrows the suspects before you touch anything. Proceed simply. Does it fail for one user while the colleague next to them is fine? Then the fault is almost certainly with them – their cable, their switch port, their address settings, their application. Checking the router makes no sense; that would down everyone. Does it fail for a whole group (one floor, one VLAN, one switch)? Then look for what they share and others do not – a shared switch, a shared VLAN, a shared gateway. Does it fail for absolutely everyone? Then the fault is upstream, on the shared path: the gateway, the firewall, the provider link, DNS. And beware of a trap that catches nearly every beginner: “it fails for everyone” does not mean “the whole network is broken”. When a single DNS server goes down, everyone is affected, yet the network itself is perfectly fine – nobody can just turn a name into an address. So scope does not show you the culprit, but the direction: down toward the user, or up toward the shared devices.

Step by step

  1. Fails for one user while the neighbor is fine? The fault is at them – their cable, port, settings. The router is innocent.
  2. Fails for a whole group? Look for what they share and others do not – one switch, one VLAN, one gateway.
  3. Fails for everyone? Suspect the shared path above: the gateway, the firewall, the uplink. All traffic meets there.
  4. Trap: “it fails for everyone” ≠ “the network is broken”. When DNS is silent, all suffer, yet paths and addresses work fine.

Bottom-up, top-down and halving

PC-APC-BSWGWFWWEBDNSbottom-up: cable, port, address, name

Now the main thing: in what order to search. Without an order, troubleshooting turns into guessing and random clicking – the fastest route to being back at the start an hour later, having broken something extra. Three approaches are used. Bottom-up: you begin at the physical layer (cable, port, link state), then addresses and gateway, then names, finally applications and rules. It is slower, but it never skips the stupid cause, which is the most common one. It fits when you know nothing at all, or the report is “nothing works”. Top-down: you begin at the application (“does anything else open?”) and descend. It fits when the network is obviously up – other people are working, only one service misbehaves. And third, a technique you will use constantly: halving the problem. You split the path from the PC to the target and test the middle: does a packet at least reach the gateway? If yes, the whole lower half is healthy and you can stop worrying about it. If no, the upper half is irrelevant. Each such test discards half the suspects, so even a long path takes only a few tries. The golden rule at the end: change one thing at a time and verify immediately what it did. Three changes at once means you no longer know which one helped – or whether another broke something else.

Step by step

  1. Bottom-up: cable and port, then addresses and gateway, then names, finally the app. Slow, but it never skips the stupid cause.
  2. Top-down: start at the application and descend. It fits when others work normally and only one service misbehaves.
  3. Halving: test the middle of the path. Does a packet reach the gateway? Then the lower half is healthy and you cross it off.
  4. The golden rule: change one thing and verify at once. After three changes you know neither which helped nor what you broke.

▶ Open in the simulator

Lesson 2: The physical layer and connections

Cable, port, link state

PC-APC-BSWGWFWWEBDNSa healthy connection: frames flow both ways

Bottom-up starts where it is least elegant and most often correct: at physics. The statistics are merciless – a huge share of “the network is down” reports ends at an unplugged, loose or broken cable. Three terms worth keeping apart (this application uses them consistently): the cable is the physical thing between the sockets; the link on the canvas is the line between two devices as you see it; and the line is that connection’s parameters – speed and a possible outage. What to check, in this order. 1) Is the cable plugged in at both ends? The user moved their desk, the cleaner pulled the plug – these are not jokes, this is Thursday. 2) Is the port up? If the port reports the connection is running (link up), the physical layer has done its job. If it reports link down, examining anything else is pointless – no VLAN setting and no route will revive a dead cable. 3) Does traffic flow both ways? There are nastier cases where the connection is “up” but the line is misconfigured or damaged and part of the frames get lost – that shows up as a slow, unreliable network, not as a total outage. In the simulator you see the connection state right on the canvas, and on a line you can set speed and an outage – that is your physical layer.

Step by step

  1. The healthy state: the cable is in both sockets, the port reports the connection is up, and frames flow both ways.
  2. The single most common cause: an unplugged or broken cable. The port reports link down and you need look no further.
  3. While the link is down, VLANs, addresses and routes are pointless to examine. No setting revives a dead cable.
  4. The nasty case: the connection is “up”, but the line loses some frames. It looks like a slow network, not an outage.

A disabled port and admin down

PC-APC-BSWGWFWWEBDNSit looks just like a cut cable

There is a fault that looks exactly like a cut cable, but the cause is elsewhere: the port has been switched off by an administrator. The technical term is administratively down (“admin down”) and it means the hardware is fine, the cable is plugged in, but the device has been told not to use that port. Why would anyone do that? For many, usually legitimate, reasons: unused ports are disabled deliberately for security (nobody can plug anything into a dead meeting-room socket), a port is disabled temporarily for maintenance and someone forgets to restore it, or a protection mechanism disables it after spotting something suspicious. How do you tell it apart from an unplugged cable? By how the device describes the state: a broken cable is reported as “the connection is not running”, while a disabled port reports “switched off by the administrator” – that is, as a decision, not a fault. And that is exactly why it deserves its own module: mistake it for a bad cable and you will spend half an hour replacing something that is perfectly fine. One more warning at the end: before you enable the port, find out why it was disabled. If someone shut it because of a security incident, your “fix” has just reopened that incident.

Step by step

  1. PC-A is cut off and the symptom matches a bad cable. Except the cable is plugged in and the hardware is fine.
  2. The cause is elsewhere: the port is administratively down. The device reports a decision, not a link fault.
  3. Disabled ports are often intentional: an empty meeting-room socket, maintenance, or a protection response to something suspicious.
  4. Enabling the port fixes it in a second – but first find out why it was off, so you do not reopen an incident.

When one connection is faulty

PC-APC-BSWGWFWWEBDNSthe connection is up, it just loses frames

The last physical case is the trickiest, because it does not look like a network fault. One connection somewhere in the middle is faulty or overloaded: it does not go down, but part of the frames vanish along the way. Users describe it in entirely different words: “the internet feels slow”, “the call stutters”, “downloads keep breaking”, “the page loads on the second try”. Nobody says “we have a line fault” – which is precisely why such a thing takes so long to find. How to approach it? Use scope and halving from the first lesson. A faulty connection affects everyone who crosses it and nobody else – so when you notice that the people with problems happen to be exactly those whose traffic runs through one particular stretch, you have your suspect. Then test in pieces: first the device before the suspect connection, then the one behind it. If the nearer target is fine while the farther one behaves unreliably, the fault lies between them. And beware of two classic traps. First: an occasional lost packet is not a fault – networks routinely drop some traffic and upper layers resend it; a fault is only repeated, measurable loss. Second: before you start swapping hardware, verify that more traffic is not simply crossing that connection than it can carry. An overloaded line looks faulty, but the cable is not to blame.

Step by step

  1. A faulty connection does not go down – part of the frames simply vanish. Users report “slow internet” or “a stuttering call”.
  2. Scope helps: a faulty connection affects everyone who crosses it and nobody else. That is your suspect stretch.
  3. Test in pieces: the target before the suspect connection, then behind it. The fault sits between the last good and first bad.
  4. Two traps: occasional packet loss is normal and an overloaded line looks faulty. Check both before swapping hardware.

▶ Open in the simulator

Lesson 3: L2: VLANs and ports

An access port in the wrong VLAN

PC-APC-BSWGWFWWEBDNScable holds, port is up – physics is fine

The cable is fine, the port is up – and still the PC gets nowhere. Welcome to layer two, home of one of the most common and most treacherous faults there is: the port is in the wrong VLAN. A one-line reminder of what that means (you know it in depth from the Switching and VLANs course): a VLAN splits one physical switch into several separate networks, and each access port belongs to exactly one of them. When someone moves a port from VLAN 10 to VLAN 20 – by mistake while re-patching, or through automation that classified the device elsewhere – the computer suddenly finds itself in an entirely different network. And here is the treachery: from the outside everything looks healthy. The cable holds, the port is up, the device may even get an address (just from a different range, because a different network hands it out). The user merely reports being unable to reach a server they used yesterday. There are two telltale signs. First: the PC has an address from a different range than its colleagues in the same office. Second: the PC sees devices it has no business seeing, and cannot see “its own”. And beware of the trap this fault sets: it looks like an addressing problem, and many people start rewriting the IP address by hand. That only masks the problem – the device still sits in the wrong network and keeps behaving oddly. The fix belongs on the switch port, not in the computer’s settings.

Step by step

  1. The physical layer is clean: the cable holds, the port is up. Still PC-A gets nowhere – we look further up.
  2. Someone moved the access port to another VLAN. The computer landed in a whole different network with nothing physically changed.
  3. The telltale sign: PC-A has an address from a different range than the colleague next door and sees foreign devices.
  4. The trap: it looks like an addressing problem. Rewriting the IP only masks it – fix the port assignment on the switch.

A trunk that does not carry what it should

PC-APC-BSWGWFWWEBDNSinside one switch everything works

When VLANs stretch across several switches, a trunk connects them – a link that carries traffic of several VLANs at once between devices, each frame tagged with the VLAN it belongs to. And because a trunk has its own list of allowed VLANs, a peculiar fault appears here: the trunk is up, the connection is healthy, frames flow across it – but your particular VLAN is not allowed on it, so its frames never reach the other side. The symptom is very specific and worth memorizing: everything works inside one switch, nothing works between switches, and only for some groups of users, while other VLANs happily cross the very same connection. Someone searching blindly can chase this all day, because every individual device looks correctly configured. The second classic form of the same fault is a mismatch at the two ends: one end of the connection is set as a trunk, the other as an ordinary access port. Then frames of one VLAN arrive where they should not, and others vanish entirely. So the procedure is simple: first confirm the problem really crosses the boundary between switches (fine inside, broken outward), and only then look at both ends of the trunk – whether both are trunks and whether both allow the same set of VLANs.

Step by step

  1. Inside one switch everything works. That is important information: addresses and ports are most likely fine.
  2. Outward it fails, though – and only for one group. Other VLANs cross the same connection without trouble.
  3. The cause: the trunk is up, but your VLAN is not allowed on it. Its frames simply never reach the other side.
  4. Check both ends: whether both are trunks and allow the same VLAN set. A mismatch of ends is the second classic.

Where the frame gets lost

PC-APC-BSWGWFWWEBDNSstep 1: do two devices in one VLAN see each other?

Let us condense layer two into a procedure you can use whenever “physics is fine but it still fails”. Ask: how far does the frame get and where does it end? Look for the answer in three steps. 1) Do two devices in the same VLAN see each other? If yes, switching inside works and the problem is higher up (addresses, gateway, routes, rules). If no, you are in the right place. 2) Are they really in the same VLAN? Check the assignment of both ports – not only the one someone complained about. A classic mistake is fixing the user’s port and missing that it was actually the server’s port that moved. 3) Must the frame cross the boundary between switches? Then look at the trunk and the allowed VLANs. Add two things that get mixed into layer two and deserve a quick check: port security features (a protection that blocks the port when an unexpected device shows up behind it – the port then looks dead although the cable is fine) and the already mentioned configuration mismatch at the two ends of one connection. And finally a rule that saves you many dead ends: when two devices cannot see each other even within one VLAN, worrying about the gateway or routes is pointless. Move up there only once you know the lower floor holds.

Step by step

  1. Step 1: do two devices in the same VLAN see each other? If yes, layer two holds and the problem is higher.
  2. Step 2: verify both port assignments. A common mistake: you fix the user’s port when the server’s port moved.
  3. Step 3: must the frame cross the boundary between switches? Then look at the trunk and the allowed VLANs.
  4. A closing rule: while devices cannot see each other in one VLAN, leave the gateway and routes alone. Move up only after verifying.

▶ Open in the simulator

Lesson 4: L3: addresses, gateway, paths

A wrong IP or mask

PC-APC-BSWGWFWWEBDNSno address: the device assigns itself a fallback

Layer three starts by asking whether the device even has a sensible address. Three cases cover nearly everything. The address is missing entirely – the device was to get one automatically but did not (assignment is broken, or it cannot reach the server handing addresses out). It is easy to spot: the device assigns itself a fallback address that gets it nowhere. The address is from a different range than it should be – either someone typed it in wrong, or the device is in the wrong VLAN (which you can now find from the previous lesson). The mask is wrong – and this is the subtle variant worth dissecting. The mask says which part of the address is the network number: by it the device decides whether the target is on its own network (send directly) or elsewhere (send to the gateway). When the mask is too narrow, the device treats its own neighbors as strangers and needlessly sends to them via the gateway. When it is too wide, it treats devices from other networks as neighbors, tries to address them directly – and the reply never comes. The result is eerie either way: some things work and some do not, with no obvious logic. And when two devices have matching addresses but differing masks, they may see each other in one direction only. So always check the address and mask together, never just the address.

Step by step

  1. Case one: the address is missing entirely. The device assigns itself a fallback address that gets it nowhere.
  2. Case two: the address is from a different range. Either someone typed it manually, or the device is in the wrong VLAN.
  3. A mask that is too narrow: the device treats its own neighbors as strangers and needlessly routes them via the gateway.
  4. A mask that is too wide: the device addresses a foreign network directly and gets no reply. Always check address and mask.

A missing or wrong gateway

PC-APC-BSWGWFWWEBDNSwithin its own network everything works

Memorize this symptom, because it is utterly typical: a device sees everything on its own network but nothing outside it. The colleague next door answers, the shared printer works, but a server in another network and the internet do not exist. Almost always the default gateway is to blame – the address of the device to which the computer hands everything that is not on its own network. The mistake takes three forms. The gateway is missing: the computer has nowhere to send outbound traffic, so it simply does not send it. The gateway address is wrong: it points to a device that does not exist or cannot route; traffic leaves and never arrives. The gateway is outside its own network: the address is valid but, by the mask, sits in a different network – which the computer cannot reach, because reaching it would again require a gateway. In numbers: the computer has 192.168.1.20 with a /24 mask, so its network is 192.168.1.0 – but its configured gateway is 192.168.2.1, which by the same mask belongs to a different network (192.168.2.0). It cannot address it directly, nor via a gateway, because that gateway IS the one in question. A classic circular absurdity that looks innocent in the configuration. Test in this order. First verify you can reach the gateway: if not, you are back in layer two (VLAN, port, cable). If yes, try something beyond the gateway. And if you reach the gateway but no further, you have narrowed it to two options: the gateway does not route where it should (the next module), or something along the way discards the traffic (the final lesson). A closing note: when one computer has a wrong gateway, the mistake is in its settings; when everyone has it, what hands it out is wrong.

Step by step

  1. The typical symptom, part one: within its own network everything works. The colleague answers, the printer prints.
  2. Part two: outside the network nothing exists – no server, no internet. This pair almost always points at the gateway.
  3. Three forms: the gateway is missing, mistyped, or outside its own network – and thus unreachable.
  4. Procedure: try the gateway first, then something beyond it. Gateway fine but nothing further leaves a route or a rule.

A missing route

PC-APC-BSWGWFWWEBDNSyou reach the gateway, but no further

You reached the gateway but no further. Now the route enters – an entry in the routing table telling the router “send traffic for this network this way”. When a route is missing, the router has nowhere to hand the packet and drops it. And here is the crucial difference from the earlier faults: a missing route need not be on your side. Traffic is bidirectional. Your request may reach the target perfectly well – but if the target’s router does not know the way back to your network, the reply never returns. From the outside it looks as if the target were dead. So watch for this pattern: “I get no reply” does not automatically mean “the request never arrived”. The second typical form is asymmetry: it works from one network and not from another, because only one half of the pair of paths is missing. How to search in practice? Use halving. Watch how far the traffic gets – the last device that still answers is your marker. The fault lies between the last one that replies and the first one that stays silent. Then look at that device’s routing table: does it know the way to the target network? And does the target know the way back? In the simulator you have a big advantage over a real network – you see the whole topology at once, so you can literally trace the path with your finger and compare it against what the individual routers know. And from now on the path test does it for you: the result includes a Route (traceroute) block – device by device, with the TTL counting down. Where the route stops, that is where to look.

Step by step

  1. The starting state: you reach the gateway but no further. Now the routing table enters the picture.
  2. When the route is missing, the router has nowhere to hand the packet and drops it. The target is perfectly fine.
  3. The catch: the request arrives, but the far side knows no way back – the reply never returns and the target looks dead.
  4. Procedure: watch how far traffic gets. The fault lies between the last device that replies and the first that stays silent.

▶ Open in the simulator

Lesson 5: The IP works, the name does not

Testing by name vs by address

PC-APC-BSWGWFWWEBDNSstep 1: translate the name to an address (DNS)

There is one test that can settle a huge share of “the internet is down” reports in ten seconds – and it is so simple that beginners skip it. It goes: try it by name, then try the same thing by address. A reminder of why. People use names (you type a website address), but the network knows only numbers (IP addresses). DNS does the translation. That means every “open this page” is really two separate operations: first translate the name to an address, only then connect to that address. And when one of the two fails, the user describes it identically – “it does not work”. The test reveals which one it was. The name fails, the address works → the network is healthy, paths and rules are fine, what is broken is name resolution. Stop searching the network, go straight to DNS. Neither works → the problem is in the network; go back to cables, VLANs, gateway and routes from the earlier lessons. The name works, the address does not → a rarity, but it happens: usually a different address hides behind the name (because the target has several addresses, or the one you tried is stale). Remember this test as a signpost: it fixes nothing, but within moments it tells you which half of the world to search. That is the most valuable information at the start.

Step by step

  1. Every “open this page” is two operations. First: translate the name to an address – that is DNS.
  2. The second operation: connect to the address you got. When either fails, the user describes it the same way.
  3. Name fails, address works: the network is healthy and name resolution is broken. Leave the network, go to DNS.
  4. Neither works: the problem is in the network. Go back to cables, VLANs, gateway and routes from earlier lessons.

When the resolver stays silent

PC-APC-BSWGWFWWEBDNSthe computer asks the resolver for an address

Say the test from the previous module pointed at names. Now we ask: where exactly does it stall? A recap of the setup. The computer asks a resolver – a server that looks the name up for it and returns an address. The computer usually receives the resolver’s address automatically – by the same mechanism (DHCP) as its IP address and gateway, as you know from the How networks work course. From that come the three most common faults. 1) The resolver is down or unreachable. A classic you will meet again and again: the network is perfectly fine, but because nobody turns names into addresses, “nothing works” for everyone. Recall the trap from lesson one – a scope of “it affects everyone” can send you hunting a broken router that is working flawlessly. 2) The computer has the wrong resolver configured. The address points at a server that does not exist, or at one that has no answers for your internal names. Typically it shows up with eerie logic: external websites work, but internal company names do not (or the other way round). 3) The resolver answers, but the answer is wrong. Either nobody created the record, or it points at an old address. The procedure is the same halving as always. First: does the resolver answer at all? If not, you are back to ordinary reachability hunting – a resolver is just another device on the network with its own cable, VLAN, address and rules. If yes, ask: does it return the right address? And if names fail on one computer while the neighboring one is fine, look at which resolver each of them has configured.

Step by step

  1. The setup: the computer asks a resolver, which looks the name up and returns an address. Its address usually arrives automatically.
  2. Fault 1: the resolver is silent. Everyone suffers, yet the network is flawless – exactly the “broken router” trap.
  3. Fault 2: the wrong resolver configured. External sites work but internal company names do not – or vice versa.
  4. Halving here too: does the resolver answer at all? And if so, does it return the right address? Two questions, two directions.

Cache and the stale answer

PC-APC-BSWGWFWWEBDNSthe answer is cached with a TTL validity

And now a fault that can drive you mad, because it looks as if physics stopped applying: you fix the record and nothing changes. Or worse – it works for you and not for your colleague, though you sit side by side. The explanation is called the cache. Answers to name queries get stored, so the same question need not be asked over and over. The resolver stores them, and so does the computer itself. Every answer carries a TTL – how long it may be considered valid. And until the TTL expires, you keep getting the old, stored answer, even if the truth changed ten times meanwhile. The typical scenario: a server got a new address, you dutifully fixed the record – but users holding the old stored answer keep going to an address where nobody lives anymore. And because everyone’s cache is of a different age, it manifests beautifully absurdly: “it works for some and not for others”, or “it works for me but not for the client”. How do you recognize a cache? By two signs. First: behavior differs by device, not by network. Second: the problem disappears on its own over time, as TTLs expire on individual machines. The cure is to flush the cache (on the computer and on the resolver) and wait for old answers to expire. And a lesson for next time: before you move a service, lower the TTL in advance – the change then spreads fast and this kind of mystery never finds you.

Step by step

  1. Name answers are stored in a cache, and each carries a TTL – how long it stays valid.
  2. The server got a new address and you dutifully fixed the record. Logically it should be done – but it is not.
  3. PC-A holds a stale answer and goes where nobody lives. PC-B has a fresh one. Hence “it works for some”.
  4. The telltale: it differs by device and fades over time. The cure: flush the cache, and next time lower the TTL in advance.

▶ Open in the simulator

Lesson 6: When a rule is to blame

The firewall and default deny

PC-APC-BSWGWFWWEBDNSpermitted traffic passes without trouble

One big group of faults remains, for which “broken” is entirely the wrong word: the network is doing exactly what you told it to. You just told it something other than you thought. A firewall works with a list of rules it walks from top to bottom (you know exactly what a rule looks like and why it reads top-down from the Network security course), ending with a default deny: whatever no rule explicitly permits is dropped. This principle is security-wise absolutely right – only what is needed gets allowed – but it causes a typical fault: someone added a new service and forgot to add a rule for it. The symptom is easy to recognize: everything else works, only that one thing does not. The user reaches the web, mail flows, but one specific application is silent. That is nearly the firewall’s signature. How to tell it from a network fault? By two clues. First selectivity: a network fault usually kills everything toward a given target, whereas a rule hits only a certain kind of traffic. Second the failure mode: dropped traffic often shows up as a long wait and then a give-up, because a dropped packet sends nobody anything. And take this advice to heart: when you find a rule is to blame, do not just write “allow everything”. Add the narrowest possible rule – a specific source, a specific target, a specific service. A broad “allow all” removes the fault and simultaneously opens a hole nobody will remember in a month.

Step by step

  1. A firewall walks its rules from top to bottom. What is explicitly permitted passes without trouble.
  2. At the end sits the default deny: what no rule permits is dropped. A new service without a rule stays silent.
  3. The firewall’s signature: everything else works, only that one thing does not. A network fault would kill it all.
  4. The fix: add the narrowest possible rule – a specific source, target and service. “Allow all” opens a hole for months.

The shadowing rule

PC-APC-BSWGWFWWEBDNSthe firewall reads top down and uses the first match

This case is the most frustrating of all, because the rule you need is there – and still does not apply. Recall that a firewall reads rules top to bottom and uses the first one matching the traffic; it never even reads the rest. So when a broader rule sits above yours and matches the same traffic, that one decides and your rule is never used. It is called a shadowing rule (and the shadowed one a dead rule). The most common shape: a broad deny at the top (“block everything to this network”) and a specific permit below (“allow the server on this port”). The configuration looks perfectly reasonable, a person reads it and swears access is permitted – it just does not work. The opposite, security-wise worse direction exists too: a broad permit at the top shadowing a specific deny below it. You then believe you are blocking something while it has been passing all along – a hole nobody sees until somebody uses it. How to find shadowing? Take concrete traffic (from where, to where, which service) and walk the list top to bottom exactly as the firewall does. The first matching rule is the one in force. It is usually a different one than you expected. The practical lesson: specific rules belong at the top, general ones at the bottom. And after every change verify what works – including what must not.

Step by step

  1. The firewall reads rules top to bottom and uses the first one matching the traffic. It never reads the rest.
  2. A broad deny sits on top, matching the same traffic. It decides – and your permit is never used at all.
  3. Your rule is dead: it exists, it looks right, but it is never reached. Hence the frustration.
  4. Fix and prevention: specific rules to the top, general ones below. And after the change verify what must not work too.

When nothing helps

PC-APC-BSWGWFWWEBDNSyou checked everything and still do not know

The last module is about a situation that will find you sooner or later: you went through everything and still do not know. First the good news – this is not a failure. Only one reaction is wrong: desperately trying random changes. Proceed in three steps instead. 1) Isolate. Simplify the situation until the problem disappears. Connect the device directly, remove an intermediate element, try another cable, another port, another computer in the same spot, the same computer in another spot. Each such swap splits the world in half – exactly what you need. 2) Document. Write down what you verified and with what result, including what worked. When you hand the case on, this is the most valuable thing you can give – you spare the next person repeating everything you already did. And when the same problem returns in a year, you will thank yourself. 3) Escalate. Hand it on when you run out of authority (you may not touch the suspect device), of knowledge (you are on technology you do not know), or when the impact grows faster than your progress. Escalation is not an admission of defeat, it is the right decision. And two things at the very end. Do not forget the possibility that something changed – for mysteries that arose “by themselves” it pays to ask who touched what recently. And once you clear the fault, restore everything you temporarily disabled or permitted along the way. Unfinished cleanup after troubleshooting is the quietest security hole there is.

Step by step

  1. You went through physics, VLANs, addresses, names and rules – and still nothing. Not a failure; just do not start guessing.
  2. Isolate: connect directly, skip an element, swap the cable, port or computer. Each swap splits the world in half.
  3. Document the verified steps including what worked. Whoever takes over need not repeat your work.
  4. Escalate when authority or knowledge runs out. And after the fix restore everything you temporarily disabled or permitted.

▶ Open in the simulator