Opens this plan in Hirezen, where one click makes it a position.
Network Administrator interview questionsIncident review — the branch file copy that stalls round
A 60 min interview plan with a time-boxed script, what each question is for, and the signals to score against. Key skills: Troubleshooting a VPN file-transfer stall from packet captures: reading three captures of one copy against each other, finding a path MTU black hole behind a missing MSS clamp, proving the fix from the user's side, and writing an ICMP policy that security can live with..
Three captures of one copy
What this section is for
Purpose
Runs over a capture pack sent 24 hours ahead, with Wireshark or any capture reader allowed. Build it in a lab with two firewalls or routers, a tunnel between them and an access list, or edit real captures — either way, write down what is in it. The story: a 35-person branch reaches head office over a route-based IPsec tunnel. Last Saturday the branch's old router, which ran the tunnel and carried an MSS adjustment of 1360 on its tunnel interface, was replaced by a firewall; the change record says "tunnel parameters copied". The tunnel interface MTU on both ends is 1400. Since Monday, branch users can log in to the file server (10.10.5.40) and browse folders, but copying a 40 MB file from the share stalls at 0%, and opening a PDF attachment in the finance application, on the same server VLAN, hangs; copying a file to the share works, slowly at first; web browsing and calls, which break out locally at the branch, are fine. Three files. `branch-laptop.pcapng`, taken on the user's laptop (10.52.0.37): the handshake with MSS 1460 in both directions, a successful SMB negotiate, session setup, tree connect and directory listing, the read request, then nothing from the server except small segments, until the laptop eventually resets the connection. Before sharing, turn TCP checksum validation on in the profile you share, so every frame the laptop sent is flagged with a bad checksum — the capture was taken on the sending host with checksum offload, and this is the first red herring. `hq-fileserver-span.pcapng`, a SPAN of the file server's switch port: the same handshake and SMB exchange, then full-size 1514-byte frames with DF set leaving the server towards the laptop and retransmitted with the gap roughly doubling each time; no ICMP at all; and, in its first seconds, "ACKed unseen segment" warnings on an unrelated backup flow that started before the capture — the second red herring. `hq-fw-inside.pcapng`, on the head office firewall's inside interface (10.10.254.1), filtered to the laptop's address or ICMP: each full-size frame from the server arrives, and for each one the firewall sends ICMP type 3 code 4, "fragmentation needed", next-hop MTU 1400, to 10.10.5.40 — nine in all. Hold two cards for when they are asked for: the core switch's log for the server VLAN's outbound access list, added in July's hardening sweep, showing "deny icmp 10.10.254.1 -> 10.10.5.40 (3/4)" with nine hits; and pings run with DF set — from the laptop to the server, a 1372-byte payload replies and 1373 returns "Packet needs to be fragmented but DF set"; from the server to the laptop, 1372 replies and 1373 simply times out. The tunnel itself is deliberately healthy: up since Saturday, no rekey failures. Book 70 minutes; the close sits outside the 60.
I'm [YOUR_NAME] and I run the network at [COMPANY_NAME]. You've had the captures since yesterday. This hour is one ticket that three people have already looked at, and I'm interested in what you saw in the packets, not in a list of things that can go wrong with VPNs.
What this section is for
Purpose
Makes the captures the subject from the first minute, so a candidate cannot substitute a general troubleshooting method for what is actually in the files.
One thing before we start: tell me which of the three captures you opened first, and why that one.
What this section is for
Purpose
Scores the reading order without a question of its own. A candidate who has done this starts from the side where the data should appear and does not, or from the device in the middle; the answer is noted, not debated.
Tell me why a copy from the share stalls when a copy to it works — and show me the packets in these captures that prove it.
What this question is for, and what to listen for
Purpose
The load-bearing question. Anyone can say "MTU issue" to a ticket about a VPN; the separator is whether the candidate reads the three captures against each other, explains the one-directional failure from where the ICMP is sent and where it disappears, and sets aside the two things Wireshark highlights that have nothing to do with it.
Signals to score
- Uses the direction of the failure as evidence: small exchanges succeed and only large transfers towards the branch fail
- Reads the MSS of 1460 in both handshakes and says nothing on the path lowered it
- Points to full-size frames with DF set that leave the server and never reach the laptop
- Finds the fragmentation-needed messages in the firewall capture and their absence at the server port
- Concludes that something between the firewall's inside interface and the server drops the ICMP, and asks for that device's log
- Explains why uploads work: the branch side's own fragmentation-needed messages reach the laptop, which lowers its segment size
- Dismisses the bad checksums as an artifact of capturing on the sending host with offload
- Dismisses the unseen-segment warnings as a capture that started mid-flow
- Connects the stall to the replaced router and the MSS adjustment that was not carried over
- Proposes the DF ping test at 1372 and 1373 bytes, and predicts both results before seeing them
Follow-up questions
- Every frame the laptop sent has a bad checksum. Why isn't that the problem?
- Where is the ICMP in these captures, and where isn't it?
- Why does a copy to the share work at all?
- What would a ping with DF set at 1372 bytes and at 1373 bytes show, from each end?
- The old router had worked for years. What did it do that the new firewall doesn't?
The fix, and the proof
What this section is for
Purpose
Moves from diagnosis to repair. Two fixes are available and both are needed for different reasons; the round also scores whether the candidate proves the user's problem is gone rather than that a line of configuration changed.
What do you change, on which device, with what number — and how do you show the branch that it's fixed, rather than just that the config changed?
What this question is for, and what to listen for
Purpose
Tests whether the candidate can derive the clamp value from the tunnel MTU instead of remembering one, knows what MSS clamping does not fix, and verifies from the user's side of the problem.
Signals to score
- Derives the clamp from the tunnel MTU: 1400 minus 20 bytes of IPv4 header and 20 of TCP header is 1360
- Puts the clamp on the tunnel interface, and says one end suffices for TCP but configures both
- Says clamping only rewrites TCP handshakes, so other traffic still depends on fragmentation-needed reaching the sender
- Fixes the access list as well as clamping, rather than choosing one
- Rejects lowering the server's MTU, and says who that would affect
- Verifies with a new capture showing MSS 1360 in the handshake at both ends
- Asks the user to repeat the 40 MB copy and the PDF attachment rather than trusting a test file
- Watches the firewall's fragmentation-needed count and the access list's ICMP deny count stop rising
- Adds a check for the next router or firewall replacement, such as DF pings through every tunnel
Follow-up questions
- Where does 1360 come from, and would it be different for IPv6 traffic inside the tunnel?
- You've clamped MSS. Why still touch the access list?
- The server team offers to set the server's MTU to 1400. Do you accept?
- What does a new capture have to show for you to close the ticket?
- What goes on the checklist for the next time a branch router is replaced?
The rule that dropped it
What this section is for
Purpose
Turns the incident into policy. The deny came from a sound instinct written too broadly, and the security lead who asked for it is not wrong about everything. This section scores firewall-policy judgment: which ICMP a network needs, which it can refuse, and how to write the rule so the next hardening sweep does not remove it again.
July's hardening sweep followed an audit finding that said "ICMP permitted to server networks". The security lead wants all ICMP to stay blocked and has asked you to find another way.
What this section is for
Purpose
Presents the security objection as a colleague's position with a real audit behind it, so the candidate has to negotiate a policy rather than simply overrule it.
Write me the ICMP policy for the server networks: what you permit, what you keep blocked, from where — and how you make it survive the next audit.
What this question is for, and what to listen for
Purpose
Tests whether the candidate knows which ICMP messages the network depends on and which carry real risk, treats IPv4 and IPv6 differently where they differ, and writes the exception so its reason travels with it.
Signals to score
- Separates error messages the network needs from query messages it can refuse
- Permits destination unreachable, including fragmentation-needed, towards servers from the internal path
- Permits time exceeded so traceroute keeps working for the people who troubleshoot
- Limits echo request and reply to monitoring and management ranges rather than everyone
- Blocks redirects, and the timestamp and address mask queries, with a reason for each
- Says that ICMPv6 Packet Too Big must never be filtered, because IPv6 routers do not fragment
- Keeps neighbour discovery working on IPv6 segments, and cites guidance such as RFC 4890
- Offers rate limiting as the answer to flooding concerns instead of a blanket deny
- Records the reason and the incident in the rule's comment and in the hardening standard the auditors read
- Answers the audit finding in its own terms instead of calling the finding wrong
Follow-up questions
- The security lead says ICMP is an attack vector. Which part of that is true?
- What breaks if you block time exceeded as well?
- Is your answer different for IPv6?
- Who is allowed to ping a server, and why them?
- Next July someone runs the same sweep. What stops them deleting your rule?
That's the pack. What would you like to ask about how changes to tunnels and firewalls get checked here? Anything goes — who reviews them, whether anyone ran a DF ping after Saturday, how our hardening standard gets written.
What this section is for
Purpose
A candidate who has lived through this kind of ticket asks about the checks after a change and who owns the standard; one who has not asks which firewall vendor we use. Naming the topics makes the choice the signal.
One honest thing before you go: [name one true, unflattering fact about your own network — a tunnel nobody has tested at full packet size, a hardening rule nobody can explain, a replacement whose config was copied by hand]. You'd inherit it. I'd rather tell you now than have you find it in week two.
What this section is for
Purpose
Ends on a real weakness in the team's own network, which is the honest pitch to the candidate this round is looking for and a warning to one who wanted it tidy. Only say it if it is still true.
Network Administrator interviews — common questions
- Who is this Network Administrator interview plan for?
- It is written for the interviewer, not the candidate: the hiring manager, engineer or panel member running the Incident review — the branch file copy that stalls round for a Network Administrator role. It gives you a 60 min script to follow in the conversation — 3 questions with what each one is for and the signals to score against — so you are not writing the round from scratch the night before.
- What does the Incident review — the branch file copy that stalls round assess?
- This round is focused on: Troubleshooting a VPN file-transfer stall from packet captures: reading three captures of one copy against each other, finding a path MTU black hole behind a missing MSS clamp, proving the fix from the user's side, and writing an ICMP policy that security can live with.. It works through Three captures of one copy, The fix, and the proof and The rule that dropped it, scoring against 29 observable signals, with follow-up prompts on all 3 questions for going deeper where an answer is thin.
- How is the 60 min split up?
- Three captures of one copy (24 min), The fix, and the proof (16 min), The rule that dropped it (20 min). The timings are there so the round stays on schedule and every candidate gets the same shape of interview — which is what makes two candidates comparable afterwards.
- What other rounds should I run for a Network Administrator?
A single round does not cover a whole role. The other rounds in this library for a Network Administrator: