Routing and NAT

Brief

At Halcyon Clinics, a backup transfer to 10.24.6.70 takes the wrong exit after a network change. The change owner points to a healthy default route and declares routing proven. Meanwhile, the security manager calls the shared public address a firewall and wants to close the segmentation finding. Neither claim establishes where the transfer went or who could initiate it.

You will reconstruct the forwarding decision from prefixes and next hops, identify what changing routes and expiring packet lifetimes actually do, and follow an address-and-port translation in both directions. The evidence pack must distinguish reachability, translation, and permission: a successful connection demonstrates a path, not an approved security policy.

A route selects a path; translation changes packet addressing; a firewall enforces traffic policy. Test each claim separately.

Choose the most specific route, not the cheapest-looking row

An IPv4 forwarding table associates a destination prefix with a next hop and outgoing interface. For 10.24.6.70, entries for 10.24.0.0/16, 10.24.6.0/24, and 10.24.6.64/26 all match. The /26 wins because its 26 fixed bits are the longest matching prefix; its range is 10.24.6.64-10.24.6.127. A /24 with metric 1 does not beat this /26 with metric 50. Route-source preferences and protocol metrics help choose candidate routes for the same prefix; they do not overturn longest prefix match across different prefix lengths.

The default route 0.0.0.0/0 matches every IPv4 destination but wins only when no more-specific usable route matches. A host at 10.24.6.10/24 sends directly to an on-link destination; for an off-link address it normally resolves the local next hop's link-layer address and sends the frame to its default gateway, 10.24.6.1. The IP destination remains the remote host, not the gateway. The gateway is a device address; the default route is a table entry. More-specific host routes can override that usual default behavior.

For a segmentation review, retain the active forwarding table, relevant interface addresses, and a timestamped route lookup for the protected destination. Ask: which exact prefix and next hop handled this flow at the time? A configuration export alone can miss an inactive route or an unreachable next hop; a default-route screenshot cannot prove the protected subnet took the inspected path.

Learned paths change; TTL limits the damage of loops

A static route is configured explicitly and does not learn alternative topology by itself. It is predictable for a small stub network but can blackhole traffic after a failure unless reachability tracking or another recovery mechanism changes it. Dynamic routing exchanges reachability and recalculates paths as topology changes. Distance-vector protocols exchange destination distances with neighbors; RIP is a hop-count example, with 16 representing unreachable. Link-state protocols such as OSPF flood link information within their scope and compute shortest paths from a topology database. Dynamic does not mean instant convergence or automatically trusted advertisements.

During convergence, inconsistent tables can form a loop. An IPv4 packet arriving with TTL 3 can be forwarded by the first router with TTL 2, then by the next with TTL 1; the following router discards it rather than forwarding a zero-lifetime packet, normally returning ICMP Time Exceeded. TTL is a per-packet forwarding bound, not a routing metric, session timeout, or repair mechanism. A route-tracing tool exploits successive expiration points, but filtered or rate-limited ICMP responses mean a missing response is not conclusive proof of a broken hop.

Change controls should record routing neighbors, permitted advertisements, route changes, and measured failover behavior. Restrict protocol participation and authenticate routing exchanges where supported. An auditor can ask whether a newly learned prefix could divert protected traffic and how the team tested convergence. Correlate time-stamped route changes with probes and packet captures; a TTL-expired counter establishes looping symptoms, not the cause or its resolution.

Translate tuples without mistaking them for identities or permissions

NAT rewrites IP addressing. A static one-to-one mapping can associate an internal address with one external address; dynamic address translation can allocate an address from a pool. PAT, also called address-and-port translation, lets multiple internal sessions share an external IP by distinguishing transport ports. For TCP, 10.24.6.10:51514 to 203.0.113.80:443 might leave as 198.51.100.10:40001 to the same destination. Another internal host can use external port 40002. Translation updates affected checksums and maintains enough mapping state to reverse the rewrite for return traffic.

A reply to 198.51.100.10:40001 is mapped back to 10.24.6.10:51514 while the mapping exists. Mappings expire, ports can be reused, and finite port space can cause exhaustion. An external IP alone therefore cannot identify an internal host. Investigations need synchronized timestamps, protocol, inside and outside address-port pairs, and often the remote endpoint to disambiguate sessions. These logs associate a network endpoint with traffic; separate asset and authentication records are needed to associate a person.

NAT is not a firewall. The lack of a dynamic inbound mapping may incidentally prevent some unsolicited connections, but static translations or port forwards can expose a service and translation itself does not express least-privilege policy. Require explicit traffic rules and positive and negative tests across the boundary. Audit evidence should pair translation records with the actual filtering policy and deny logs; ask whether the same exposure would be blocked if the addresses were not translated.

Answers are graded on the server: the answer key never reaches your browser.