Hacker DirectoryHacker Directory
Continue learning
TRSave HTML ↓

WEB / WEB-02.02

IP, routes and NAT

Destination IP and the first neighbor may differ. Select a next hop from a route table and track address/port changes under NAT/PAT.

CORE · RED · BLUE · ARTIFACT · PRACTICE

1. Core · Mechanism

Read every scenario without motion

Remote IPv4 · default + PAT

  1. Original TCP tuple ready

    Destination is 198.51.100.200:443; host source is 192.0.2.10:51000. Addresses and ports are synthetic; no connection is executed.

    Source host
    192.0.2.10:51000 → 198.51.100.200:443
    Gateway / router
    No IP packet received
    Selected endpoint
    No IP packet received
  2. Local longest-prefix lookup

    Neither the connected /24 nor 198.51.100.0/25 matches this destination. Default /0 selects next hop 192.0.2.1; IP destination stays remote.

    Source host
    Route /0 · next hop 192.0.2.1 · dst 198.51.100.200
    Gateway / router
    No IP packet received
    Selected endpoint
    No IP packet received
  3. Gateway received the original packet

    First-hop delivery completed. Link addressing identifies the neighbor; the incoming IP/TCP summary retains the untranslated source tuple.

    Source host
    Original tuple sent to first hop
    Gateway / router
    Received: 192.0.2.10:51000 → 198.51.100.200:443
    Selected endpoint
    No IP packet received
  4. Router lookup and PAT are local

    The selected egress route and binding rewrite source to 203.0.113.5:45000. Destination stays 198.51.100.200:443. The rewrite itself is not a network transfer.

    Source host
    Inside tuple 192.0.2.10:51000
    Gateway / router
    PAT: 192.0.2.10:51000 ↔ 203.0.113.5:45000
    Selected endpoint
    No IP packet received
  5. Endpoint received the translated tuple

    Delivery over the toy egress path completed. Intermediate routers and checksum bytes are omitted; this observer sees the outside tuple.

    Source host
    Inside tuple 192.0.2.10:51000
    Gateway / router
    Mapping ready · outside 203.0.113.5:45000
    Selected endpoint
    Received: 203.0.113.5:45000 → 198.51.100.200:443
  6. Reply reached the gateway

    The selected reply goes from 198.51.100.200:443 to 203.0.113.5:45000. Its existence is a fixture condition; no HTTP response bytes are shown.

    Source host
    Reply has not reached the host
    Gateway / router
    Reply received: dst 203.0.113.5:45000
    Selected endpoint
    Selected reply summary sent
  7. Local reverse mapping

    The same binding maps the outside destination back to inside endpoint 192.0.2.10:51000. Remote source is preserved; no permission decision is shown.

    Source host
    Reply has not reached the host
    Gateway / router
    Reply destination rewritten: 192.0.2.10:51000
    Selected endpoint
    Selected reply summary sent
  8. Inside endpoint received the reply

    Reverse delivery completed. NAT and firewall policy are separate functions; this scene produces no firewall verdict.

    Source host
    Reply received: 198.51.100.200:443 → 192.0.2.10:51000
    Gateway / router
    Reverse mapping used
    Selected endpoint
    Selected reply summary sent

Local /24 · no gateway needed

  1. On-link destination selected

    Address 192.0.2.20 matches this host’s configured /24 route. Local/remote is a routing context rather than an address’s appearance.

    Source host
    Dst 192.0.2.20 · route lookup pending
    Gateway / router
    No transit packet received
    Selected endpoint
    Local peer · no packet received
  2. Local on-link lookup

    Longest match is 192.0.2.0/24; next hop is destination 192.0.2.20 itself. This branch assumes an available neighbor mapping.

    Source host
    Route /24 · next hop 192.0.2.20 · no NAT
    Gateway / router
    No transit packet received
    Selected endpoint
    Local peer · no packet received
  3. Local peer received the packet

    On-link delivery completed without the gateway. IP addresses remain 192.0.2.10 → 192.0.2.20.

    Source host
    Local frame summary sent
    Gateway / router
    No transit packet received
    Selected endpoint
    Received: IP 192.0.2.10 → 192.0.2.20

IPv6 · selected no-NAT

  1. IPv6 destination ready

    Source is 2001:db8:1::10, destination 2001:db8:2::20. This fixture assumes determined on-link context and next hop.

    Source host
    IPv6 2001:db8:1::10 → 2001:db8:2::20
    Gateway / router
    No IPv6 packet received
    Selected endpoint
    No IPv6 packet received
  2. Local IPv6 next-hop lookup

    Selected next hop is 2001:db8:1::1 with an available ND mapping. ARP is not used; full IPv6 route discovery is omitted.

    Source host
    Next hop 2001:db8:1::1 · ND ready
    Gateway / router
    No IPv6 packet received
    Selected endpoint
    No IPv6 packet received
  3. IPv6 gateway received the packet

    First-hop delivery completed; source/destination are unchanged.

    Source host
    IPv6 summary sent
    Gateway / router
    Received: 2001:db8:1::10 → 2001:db8:2::20
    Selected endpoint
    No IPv6 packet received
  4. Local forwarding · no translation

    The router uses the selected egress path; Hop Limit handling is conceptual without bytes. This path applies no NAT, not a universal claim about IPv6 deployments.

    Source host
    Source 2001:db8:1::10 preserved
    Gateway / router
    Egress ready · translation false
    Selected endpoint
    No IPv6 packet received
  5. IPv6 endpoint saw the original addresses

    Selected routed delivery completed. Filtering and application authorization require separate evaluation.

    Source host
    Source 2001:db8:1::10 preserved
    Gateway / router
    No-NAT forwarding complete
    Selected endpoint
    Received: 2001:db8:1::10 → 2001:db8:2::20

No default · no matching route

  1. Default route omitted in this case

    Destination remains 198.51.100.200. This variant differs from the normal artifact table by retaining only /24 and /25; the changed condition is explicit.

    Source host
    Dst 198.51.100.200 · no default
    Gateway / router
    No packet received
    Selected endpoint
    No packet received
  2. Local lookup found no match

    Neither /24 nor /25 matches. With no next hop, this fixture makes no network transfer and asserts no OS error code.

    Source host
    No route · delivery did not start
    Gateway / router
    No packet received
    Selected endpoint
    No packet received

ACTORS · STATE · DATA FLOW

What does an IP address identify?

IP carries source and destination addresses at the network layer. IPv4 uses 32 bits, IPv6 128. Forms such as 192.0.2.10 and 2001:db8:1::10 are readable representations. An interface can have multiple addresses; an address is not a permanent identity of a host, person or account.

All IPv4 examples use TEST-NET blocks and IPv6 uses documentation 2001:db8::/32. Inside/outside label diagram roles. 192.0.2.0/24 is not an RFC1918 private block, and the examples are not real Internet destinations. They define a synthetic model, not live routability.

Subnet and on-link decisions

In this simple IPv4 configuration, 192.0.2.10/24 supplies connected route 192.0.2.0/24. The first 24 bits are the prefix, with mask 255.255.255.0. Destination 192.0.2.20 matches and is an on-link next hop. 198.51.100.200 needs another route.

Local/remote means on-link routing, not geographic proximity. A VPN or more-specific route can change the decision. In IPv6, an address prefix alone is not sufficient evidence that every same-prefix destination is on-link; learned on-link routes/prefixes and ND router information matter. Do not copy the IPv4 mask exercise to every IPv6 topology.

The route table and default gateway

The artifact has connected 192.0.2.0/24, a special 198.51.100.0/25 route via 192.0.2.254, and default 0.0.0.0/0 via 192.0.2.1. In this single-table model, select the longest matching prefix. 198.51.100.20 matches /25; 198.51.100.200 does not and uses default. Default does not override all other matches.

Route lookup is local processing, followed by neighbor resolution on the selected link. The first frame uses a gateway MAC for a remote destination, while IP destination remains remote. A router builds the next link header and decrements IPv4 TTL. Ordinary routing does not replace target IP with gateway IP. Missing route, unresolved neighbor and unresponsive service are different failure boundaries.

NAT translates addresses; PAT also translates ports

Routing selects the path; NAT performs address translation along it. Basic NAT translates IP addresses. NAPT, commonly called PAT, translates address+port tuples for TCP/UDP examples, separating inside flows behind an outside IP. The next lesson expands ports; here they distinguish the local endpoint for returning traffic.

Our TCP 192.0.2.10:51000→198.51.100.200:443 becomes 203.0.113.5:45000→the same destination. Replies to the outside tuple use the existing mapping to reach the inside tuple. This is a chosen teaching NAT policy, not a universal mapping/filter behavior. State loss or asymmetric paths may break return traffic; changed addresses do not imply encrypted payload.

IPv6, NAT and permission are separate decisions

IPv6’s larger address space does not require IPv4-style NAT for routed communication. Our no-NAT branch preserves 2001:db8:1::10→2001:db8:2::20; ND may still resolve the first-hop link address. This selected path uses no translation; it does not claim translation is absent from every IPv6 deployment.

Presence or absence of a NAT mapping does not replace firewall policy. A firewall permits traffic; application authorization evaluates resource actions. One outside IP in HTTP logs does not establish one user—PAT may represent multiple endpoints. User identity needs verified application context.

2. Red · Trust & Impact

Read every scenario without motion

PAT / authority

  1. The observed peer depends on the layer

    TCP inside 192.0.2.10:51000 translates to outside 203.0.113.5:45000. An HTTP peer observation is not the inside host’s account identity.

    Peer observation
    Outside 203.0.113.5:45000
    Authority gate
    No identity decision
    Route / grant review
    No grant
  2. A mapping does not establish identity

    An address/port/protocol mapping establishes a communication relationship. Multiple inside tuples may share an outside IP; an IP label cannot replace a verified account.

    Peer observation
    Outside 203.0.113.5:45000
    Authority gate
    Peer address ≠ verified principal
    Route / grant review
    No grant
  3. The next hop is not the resource

    DEFAULT selects gateway 192.0.2.1 for 198.51.100.200. Forwarding to the gateway neither locates the web resource there nor grants access to it.

    Peer observation
    Outside 203.0.113.5:45000
    Authority gate
    Peer address ≠ verified principal
    Route / grant review
    nextHop=192.0.2.1 / target=remote
  4. Firewall is a separate control owner

    Tuple translation and explicit traffic filtering are different tasks. Mapping presence does not prove complete isolation, and its absence does not imply universal access; actual policy is separate.

    Peer observation
    Outside 203.0.113.5:45000
    Authority gate
    Translation ≠ filter verdict
    Route / grant review
    nextHop=192.0.2.1 / target=remote
  5. Application authority remained separate

    The application must establish verified principal and resource policy using trusted context. Network observation may assist but is not automatically promoted to account authority.

    Peer observation
    Outside 203.0.113.5:45000
    Authority gate
    Verified context required
    Route / grant review
    nextHop=192.0.2.1 / target=remote
  6. Impact claims stay bounded by evidence

    The tuple fixture shows route/translation scope only. It provides no actual peer identity, service acceptance or data-exposure evidence; those need separate higher-layer observations.

    Peer observation
    Outside 203.0.113.5:45000
    Authority gate
    Verified context required
    Route / grant review
    UNKNOWN: application authority

IPv6 / authority

  1. The observed peer depends on the layer

    IPv6 source=2001:db8:1::10 and destination=2001:db8:2::20 follow translation=false. Absence of NAT grants no application permission.

    Peer observation
    IPv6 translation=false
    Authority gate
    No identity decision
    Route / grant review
    No grant
  2. A mapping does not establish identity

    An address/port/protocol mapping establishes a communication relationship. Multiple inside tuples may share an outside IP; an IP label cannot replace a verified account.

    Peer observation
    IPv6 translation=false
    Authority gate
    Peer address ≠ verified principal
    Route / grant review
    No grant
  3. The next hop is not the resource

    This IPv6 branch uses next hop 2001:db8:1::1 toward remote destination 2001:db8:2::20. Gateway forwarding neither locates the web resource there nor grants application access. This branch does not use the IPv4 DEFAULT route.

    Peer observation
    IPv6 translation=false
    Authority gate
    Peer address ≠ verified principal
    Route / grant review
    nextHop=2001:db8:1::1 / target=2001:db8:2::20
  4. Firewall is a separate control owner

    Tuple translation and explicit traffic filtering are different tasks. Mapping presence does not prove complete isolation, and its absence does not imply universal access; actual policy is separate.

    Peer observation
    IPv6 translation=false
    Authority gate
    Translation ≠ filter verdict
    Route / grant review
    nextHop=2001:db8:1::1 / target=2001:db8:2::20
  5. Application authority remained separate

    The application must establish verified principal and resource policy using trusted context. Network observation may assist but is not automatically promoted to account authority.

    Peer observation
    IPv6 translation=false
    Authority gate
    Verified context required
    Route / grant review
    nextHop=2001:db8:1::1 / target=2001:db8:2::20
  6. Impact claims stay bounded by evidence

    The tuple fixture shows route/translation scope only. It provides no actual peer identity, service acceptance or data-exposure evidence; those need separate higher-layer observations.

    Peer observation
    IPv6 translation=false
    Authority gate
    Verified context required
    Route / grant review
    UNKNOWN: application authority

ASSUMPTION · BOUNDARY · CONTROL

Mistaking the next hop for the final target

A gateway forwards toward another hop. Treating it as the location of the web resource mixes link, IP and application layers. Wrong routes can impair reachability; confidentiality effects depend on peer validation and the actual path.

Verify intended prefix, next hop and interface, and validate application target identity separately. A gateway MAC is not proof of remote-site identity. Many destinations sharing one next hop is normal.

Treating translation as security policy

Tuple translation is a communication mechanism, not proof of every permission boundary. Static inbound mappings or differing filtering behavior may change reachability and need explicit policy.

Conditions and impact depend on reachable endpoint, protocol and port. NAT present does not mean complete isolation; NAT absent does not mean everything is open. Explicit firewall and application authorization are separate controls.

Making an outside IP actor authority

PAT may carry many inside tuples behind one outside IP. Using that IP as authoritative account identity can misattribute activity or create broad allow/deny decisions. IP controls can provide context but cannot replace verified actor identity.

Correlation considers address, port, protocol, time and relevant NAT mappings. Missing mapping or timing leaves the inside host uncertain. This lesson contains no workflow for probing NAT behavior or correlating real target traffic.

3. Blue · Secure development & defense

Read every scenario without motion

Reverse tuple

  1. Prefix selection was checked separately

    SPECIFIC destination=198.51.100.20 selects the longer /25 route with nextHop=192.0.2.254. DEFAULT destination .200 falls outside that /25.

    Route evidence
    SPECIFIC → /25 via .254
    Mapping evidence
    No PAT observation
    Correlation review
    No conclusion
  2. Tuple evidence scope was read

    The PAT fixture supplies TCP inside 192.0.2.10:51000 ↔ outside 203.0.113.5:45000. These are supplied relationships, not a gateway capture.

    Route evidence
    SPECIFIC → /25 via .254
    Mapping evidence
    TCP inside/outside mapping
    Correlation review
    No conclusion
  3. The reply-tuple relationship was separated

    The reply target before translation is 203.0.113.5:45000; afterward it is 192.0.2.10:51000. Source 198.51.100.200:443 stays unchanged; port/protocol scope is retained.

    Route evidence
    SPECIFIC → /25 via .254
    Mapping evidence
    TCP inside/outside mapping
    Correlation review
    Reverse-tuple expectation
  4. The on-link distinction was preserved

    For LOCAL 192.0.2.20, the next hop is the destination itself. Explaining every route via the default gateway would misrepresent ordinary local access.

    Route evidence
    LOCAL → 192.0.2.20
    Mapping evidence
    TCP inside/outside mapping
    Correlation review
    Reverse-tuple expectation
  5. A no-NAT path can be ordinary

    No mapping is expected in ipv6NoNat.translation=false. A missing NAT event is a review gap only where translation is required and coverage is known.

    Route evidence
    LOCAL → 192.0.2.20
    Mapping evidence
    No-NAT IPv6 is a separate baseline
    Correlation review
    Reverse-tuple expectation
  6. The correlation result was bounded

    The supplied forward/reverse tuple expectations are consistent. This proves neither checksums, live routability nor an authenticated account.

    Route evidence
    LOCAL → 192.0.2.20
    Mapping evidence
    No-NAT IPv6 is a separate baseline
    Correlation review
    Route/tuple expectations agree

Mapping absent

  1. Prefix selection was checked separately

    SPECIFIC destination=198.51.100.20 selects the longer /25 route with nextHop=192.0.2.254. DEFAULT destination .200 falls outside that /25.

    Route evidence
    SPECIFIC → /25 via .254
    Mapping evidence
    No PAT observation
    Correlation review
    No conclusion
  2. Tuple evidence scope was read

    This branch omits PAT observation. A route table alone establishes neither observed outside port=45000 nor inside attribution.

    Route evidence
    SPECIFIC → /25 via .254
    Mapping evidence
    PAT scope missing
    Correlation review
    No conclusion
  3. The reply-tuple relationship was separated

    The reply target before translation is 203.0.113.5:45000; afterward it is 192.0.2.10:51000. Source 198.51.100.200:443 stays unchanged; port/protocol scope is retained.

    Route evidence
    SPECIFIC → /25 via .254
    Mapping evidence
    PAT scope missing
    Correlation review
    Reverse-tuple expectation
  4. The on-link distinction was preserved

    For LOCAL 192.0.2.20, the next hop is the destination itself. Explaining every route via the default gateway would misrepresent ordinary local access.

    Route evidence
    LOCAL → 192.0.2.20
    Mapping evidence
    PAT scope missing
    Correlation review
    Reverse-tuple expectation
  5. A no-NAT path can be ordinary

    No mapping is expected in ipv6NoNat.translation=false. A missing NAT event is a review gap only where translation is required and coverage is known.

    Route evidence
    LOCAL → 192.0.2.20
    Mapping evidence
    No-NAT IPv6 is a separate baseline
    Correlation review
    Reverse-tuple expectation
  6. The correlation result was bounded

    Route choice is known; PAT attribution remains UNKNOWN. An HTTP source IP is not used to guess an inside actor; a mapping with matching observation point/time/protocol is required.

    Route evidence
    LOCAL → 192.0.2.20
    Mapping evidence
    No-NAT IPv6 is a separate baseline
    Correlation review
    UNKNOWN: inside attribution

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Route and translation are separate observations

A route table specifies intended next hop/interface; a frame can show that link’s neighbor. A NAT table links inside/outside tuples, and HTTP logs show the application-visible peer. None automatically proves every field of the others.

TCP 51000→45000 is our selected mapping, not a captured gateway log. Production pre/post NAT field names, hook location and time semantics need the vendor schema.

Local, default and more-specific baselines

Expect on-link for 192.0.2.20, /25 via .254 for 198.51.100.20, and default via .1 for 198.51.100.200. Intended mapping is a positive outcome; a more-specific route overriding default is a benign variation. No route is a distinct result.

No NAT record does not always mean deny: the no-NAT IPv6 branch or another untranslated path can be normal. A mapping with no response does not establish NAT as the cause; downstream, firewall and service evidence is needed.

Compare expected fields

Calculate prefix matches and check that route and next-hop explanations agree. The NAT reverse tuple should return to the inside endpoint derived from the forward mapping. This proves neither wire checksums nor live routability.

Review route scope, NAT state, return paths and firewall policy together. Changes to default behavior must preserve intended on-link and more-specific access. A timeout without further evidence is not malicious activity.

NOW APPLY IT TO THE CASE

Where does address-translation evidence end?

Host 192.0.2.10 uses the selected route for a remote destination. PAT may change the source port, while the IPv6 example has no translation. Neither network address replaces verified user identity or application permission.

Which network path carries the case response? Evaluate byte, IP-route, socket and firewall evidence separately from the application returning the correct book.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Route table and one PAT mapping

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations
{
  "host": {
    "address": "192.0.2.10",
    "prefixLength": 24,
    "mask": "255.255.255.0",
    "interface": "eth-demo"
  },
  "routeSelection": "single table; longest destination-prefix match; ties/policy routing omitted",
  "routes": [
    {
      "prefix": "192.0.2.0/24",
      "via": null,
      "interface": "eth-demo"
    },
    {
      "prefix": "198.51.100.0/25",
      "via": "192.0.2.254",
      "interface": "eth-demo"
    },
    {
      "prefix": "0.0.0.0/0",
      "via": "192.0.2.1",
      "interface": "eth-demo"
    }
  ],
  "cases": [
    {
      "id": "LOCAL",
      "destination": "192.0.2.20",
      "expectedPrefix": "192.0.2.0/24",
      "expectedNextHop": "192.0.2.20"
    },
    {
      "id": "SPECIFIC",
      "destination": "198.51.100.20",
      "expectedPrefix": "198.51.100.0/25",
      "expectedNextHop": "192.0.2.254"
    },
    {
      "id": "DEFAULT",
      "destination": "198.51.100.200",
      "expectedPrefix": "0.0.0.0/0",
      "expectedNextHop": "192.0.2.1"
    }
  ],
  "pat": {
    "protocol": "TCP",
    "inside": {
      "ip": "192.0.2.10",
      "port": 51000
    },
    "outside": {
      "ip": "203.0.113.5",
      "port": 45000
    },
    "remote": {
      "ip": "198.51.100.200",
      "port": 443
    },
    "replyBeforeTranslation": {
      "sourceIp": "198.51.100.200",
      "sourcePort": 443,
      "destinationIp": "203.0.113.5",
      "destinationPort": 45000
    },
    "replyAfterTranslation": {
      "sourceIp": "198.51.100.200",
      "sourcePort": 443,
      "destinationIp": "192.0.2.10",
      "destinationPort": 51000
    }
  },
  "ipv6NoNat": {
    "source": "2001:db8:1::10",
    "destination": "2001:db8:2::20",
    "nextHop": "2001:db8:1::1",
    "translation": false
  },
  "addressPurpose": "Documentation-only; inside/outside roles do not reclassify TEST-NET as private/global-routable."
}
prefix / via / interface
Match scope, gateway or on-link route, and egress interface.
expectedPrefix / expectedNextHop
Deterministic longest-prefix result, not live route-cache data.
inside / outside / remote
Three tuple roles in this TCP mapping, not a universal NAT schema.
replyBeforeTranslation / replyAfterTranslation
Reverse mapping of the destination tuple back to the inside endpoint.
ipv6NoNat.translation
No translation on this selected IPv6 branch, not a universal deployment rule.

Inert synthetic route/NAT table, not forwarding evidence, checksums, TTL bytes or firewall decisions. Single-table LPM and one mapping omit policy routing, ECMP, NAT filtering variants and full IPv6 next-hop rules.

Two reality checks

A remote IP packet’s destination becomes the first gateway’s IP.

Ordinary routing preserves the remote IP target while first-hop link addressing identifies the gateway. Separate translation such as NAT may change fields.

NAT automatically provides firewall and authorization.

Translation, filtering and resource permission are distinct functions with separately verified policy and enforcement.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Which route is selected for 198.51.100.20?

  1. 198.51.100.0/25; next hop 192.0.2.254.
  2. Always default gateway 192.0.2.1 because the destination is remote.
Read the explained answer

198.51.100.0/25; next hop 192.0.2.254. — This destination belongs to the /25; the default /0 is less specific and is not selected.

Which endpoint is restored in this reply translation?

Selected lesson artifact fields; teaching example

pat.replyBeforeTranslation
{"sourceIp":"198.51.100.200","sourcePort":443,"destinationIp":"203.0.113.5","destinationPort":45000}
pat.replyAfterTranslation
{"sourceIp":"198.51.100.200","sourcePort":443,"destinationIp":"192.0.2.10","destinationPort":51000}
  1. 192.0.2.10:51000 replaces 203.0.113.5:45000.
  2. The remote server IP changes to 192.0.2.10.
Read the explained answer

192.0.2.10:51000 replaces 203.0.113.5:45000. — The PAT mapping translates the destination tuple to the inside endpoint; the remote source stays unchanged.

In the selected IPv6 no-NAT profile, translation=false. Why are routing and firewall still separate questions?

Read the explained answer

This profile does not change IPv6 source/destination; a next hop is still needed. A firewall separately determines forwarding permission. No NAT does not mean all traffic is allowed or all IPv6 deployments are identical.

□ I bounded no-NAT to the selected profile.

□ I separated routing, translation and permission.

Open the application console · request / response / browser
Also open request, URL, cookie and DOM examples

Sources and scope