02 / IP addresses, subnets and return paths

Addresses tell us where; routes tell us the next step

Prerequisite: lesson 1. An IP address identifies an interface in this exercise. A subnet is a group described by a network prefix. In a /24, the first 24 bits are network bits: 10.77.10.10/24 has subnet 10.77.10.0/24 and mask 255.255.255.0. It has usable host addresses .1 through .254; .0 is the network and .255 the broadcast address in this conventional subnet. Do not generalize that last-octet rule to every prefix.

A gateway is a router on the local subnet used to reach another network. A route selects a next hop for a destination prefix. The client sends the remote server’s packet via 10.77.10.1; the server replies via 10.77.20.1. The destination IP stays the remote endpoint; link-layer delivery uses the gateway on each local link. A default route is a fallback, not a requirement here.

Keep these terms beside the explorer

Prefix

The network part of an address, written with a bit count such as /24. Here /24 corresponds to mask 255.255.255.0.

Next hop

The local router or directly attached receiver selected for the next link. It is not automatically the final IP destination.

Connected route

A route associated with an attached, addressed interface. In this baseline FortiGate connects both /24 lab networks.

Neighbor cache

Stored mappings between local neighbor IP and link-layer address. A cached entry can avoid a new ARP exchange.

TTL

IPv4 Time To Live, a forwarding-lifetime field that decreases when a router forwards the packet. No actual starting value is assumed in this pack.

Return path

The route choices needed to carry a reply back to the initiating endpoint. It must work in addition to the forward path.

Build the idea: subnet arithmetic without guessing

An IPv4 address has 32 bits, written here as four decimal octets. The prefix /24 says that 24 bits identify the network. The mask is 255.255.255.0. For this example, 10.77.10.10/24 belongs to 10.77.10.0/24; 10.77.20.10/24 belongs to 10.77.20.0/24. These are different networks. The “first three octets” shortcut is specific to /24; it is not a rule for every prefix.

A route describes where to send traffic for a destination prefix. The client’s route for 10.77.20.0/24 selects gateway 10.77.10.1. That gateway must itself be reachable on the client link. A default route is a fallback for destinations without a more specific match; the experiment needs no Internet default route. If overlapping routes exist, selection requires further checks; the beginner baseline deliberately avoids that complexity.

Two addresses answer different questions

Client frame: C_MAC → FG_P2_MAC answers “who receives this local Ethernet frame next?” Inside it, IP 10.77.10.10 → 10.77.20.10 answers “which endpoints are communicating?” On the server link, the frame becomes FG_P3_MAC → S_MAC. The IP pair does not become a pair of firewall interface addresses. With ordinary IPv4 routing, TTL decreases as the packet is forwarded; no initial TTL or captured numeric value is assumed here.

On the reply, server IP 10.77.20.10 → client IP 10.77.10.10 travels first inside S_MAC → FG_P3_MAC, then FG_P2_MAC → C_MAC. A permitted session cannot repair a missing route on the server. This is why both directions appear in every acceptance check.

Worked failure analysis

Suppose the request can arrive, but the server’s only route to 10.77.10.0/24 is removed and there is no fallback. The server cannot select the intended remote reply path. The client may wait without a useful response. The decisive lesson evidence is the narrow route change plus the server route lookup and successful restoration—not the timeout alone.

Lab 02: inspect, predict, change one route, restore

Conditional practical: complete the exact-build setup and baseline gates first. Until then, use this as guided analysis and leave observed results blank.

Use this lab only on the disposable server after setup acceptance and a passing HTTP baseline. First collect read-only observations on both endpoints. C_IF and S_IF are worksheet placeholders; substitute the actual verified NIC name only in the two mutation commands.

CLIENT:
ip -br address
ip route
ip route get 10.77.20.10
ip neigh show

SERVER:
ip -br address
ip route
ip route get 10.77.10.10
ip neigh show

1. Predict the client and server choices before reading the route-get output. Check whether actual selections match the manifest.
2. Save the server route listing privately. Confirm the manually created target route is exactly the prefix/next hop/interface shown below, with no extra flags, metric, table or fallback. Otherwise stop for an exact inverse.
3. With the helper running, make one fresh client curl request and record the baseline.
4. Remove only the verified server remote route. If deletion fails, do not assume the route changed and do not add a duplicate.
5. Make one fresh bounded client request; inspect the server route lookup. Record the actual result without inventing an error string.
6. After successful deletion, restore the same route, compare with the saved listing, repeat both route lookups and retest HTTP.

SERVER only; replace S_IF with the actual verified server NIC:
sudo ip route del 10.77.10.0/24 via 10.77.20.1 dev S_IF

Exact inverse after successful deletion:
sudo ip route add 10.77.10.0/24 via 10.77.20.1 dev S_IF

sudo requests local administrative authority. ip route del removes the specified runtime route; add restores it. via names the next hop and dev names the interface. No persistent network file is edited. If the inverse reports “file exists,” inspect the table instead of repeating adds. If the original state is uncertain, stop and use the private change ledger; do not remove another route to make a command succeed.

Acceptance: original route choice and HTTP response restored, with no management/default-route or firewall-policy change. Cleanup: leave the known-good route restored and stop only the helper when finished. No global session clear is required.

See the conversation

Detailed diagram: scroll horizontally to inspect full-size labels. The text path below reflows on phones.

Slow packet film: 13 steps, six seconds per step (78 seconds total). Pause to inspect the headers, or use the explorer above at 10/15 seconds per step. Film timing is instructional; it is not measured network latency.

No autoplay. Use native pause or leave the static diagram visible. Reusable GIF download. The static diagram and caption are the reduced-motion alternative; GIFs are not embedded.

Practical 02 • inspect and remove one owned route

Conditional practical: complete the exact-build setup and baseline gates first. Until then, use this as guided analysis and leave observed results blank.

On each Ubuntu console, ip -br address lists interface names and addresses; ip route lists routes. Do not assume eth0. Record the verified client interface as C_IF and server interface as S_IF in the private lab worksheet; these are placeholders, never literal commands.

CLIENT read-only:
ip -br address
ip route
ip route get 10.77.20.10

SERVER read-only:
ip -br address
ip route
ip route get 10.77.10.10

ip route get asks Linux which path it would use; it does not send a service request. Expected client choice: via 10.77.10.1 and the verified client NIC, source 10.77.10.10. Expected server choice: via 10.77.20.1, source 10.77.20.10.

1. Start from a passing HTTP baseline with the helper running. Save both route listings.
2. Only if the server has exactly the manually created route shown below, with no fallback route, remove it. Replace S_IF with the real interface name. If the route has other metrics, tables or flags, stop and prepare an exact inverse instead.
3. Run one bounded client curl from lesson 1. Expected failure or missing reply; corroborate the server route-get result. Do not call this a firewall block.
4. Restore exactly the removed route; repeat both route-get and HTTP checks. Acceptance: original route and HTTP 200 restored. No persistent network files changed.

SERVER only, after baseline check; replace S_IF:
sudo ip route del 10.77.10.0/24 via 10.77.20.1 dev S_IF

Exact inverse, same console:
sudo ip route add 10.77.10.0/24 via 10.77.20.1 dev S_IF

sudo authorizes a local administrative action. del removes this one prefix/next-hop route; add restores it; dev names the verified NIC. If deletion fails, do not add a duplicate route. These temporary commands affect only the disposable server’s runtime route table.

Diagnosis, cleanup and practice

Check at most: interface address/up state, route-get choice, then the known helper/policy baseline. Stop if a default route or unexpected NIC appears. Cleanup is the exact route restoration above, followed by the baseline comparison; stop the helper only after testing. Practice: why can a request reach the server while its reply fails? The forward and return route choices are separate. Does a ping to 10.77.10.10 from that same client test the firewall? No. Which prefix holds 10.77.20.10/24? 10.77.20.0/24.

Evidence and boundaries

Use the evidence worksheet. Write prediction before observation; record time, exact command, endpoints, policy ID if available and a redacted result. Leave actual-result cells blank until tested. Never paste passwords, license files, serials, full configurations or recovery backups into the preview.

Stop after one failed attempt and up to three focused checks. A timeout alone is inconclusive: service, route, host filtering or firewall policy may be responsible. Restore the stated fault before trying a different hypothesis.

More practice • explain before revealing the answer