Bird
Raised Fist0
Interview Prepcomputer-networksmediumAmazonGoogleMicrosoftFlipkartSwiggy

NAT - Network Address Translation, Types & Port Forwarding

Choose your preparation mode3 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
▶
Steps
setup

Initialize Network Nodes and NAT Device

The network topology is set up with a client, NAT router, and external server. The NAT device is configured with a port forwarding rule mapping external port 8080 to internal IP 192.168.1.100 port 80.

💡 Setting up nodes and NAT rules is essential to simulate how packets will be translated and forwarded.
Line:nat_device = NAT(public_ip='203.0.113.1') nat_device.add_port_forwarding_rule(8080, '192.168.1.100', 80)
💡 The NAT device is ready to translate packets from the private network to the public network using port forwarding.
📊
NAT - Network Address Translation, Types & Port Forwarding - Watch the Algorithm Execute, Step by Step
Watching the packet flow and NAT translation step-by-step reveals how NAT modifies packet headers and manages port mappings, which is difficult to grasp from code or static diagrams alone.
Step 1/10
·Active fill★Answer cell
Network nodes initialized and NAT port forwarding rule configured.
Hop: 0
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
Client sends original packet to NAT router.
Hop: 1
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
📦Packet
↗ fromclient
↘ tonat_router
📄 payloadTCP Packet 192.168.1.100:12345 → 8.8.8.8:80
🔌 protocolTCP
Packet created at client: 192.168.1.100:12345 → 8.8.8.8:80
NAT router checks port forwarding rules for incoming packet.
Hop: 2
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
📦Packet
↗ fromclient
↘ tonat_router
📄 payloadTCP Packet 192.168.1.100:12345 → 8.8.8.8:80
🔌 protocolTCP
Packet received at NAT router.
Port forwarding rule matched for external port 8080.
NAT router rewrites packet source to public IP and port per port forwarding.
Hop: 3
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
📦Packet
↗ fromnat_router
↘ toserver
📄 payloadTCP Packet 203.0.113.1:8080 → 8.8.8.8:80
🔌 protocolTCP
Packet source IP and port translated to 203.0.113.1:8080.
NAT table updated with port forwarding entry.
Packet forwarded to external server with NAT translation.
Hop: 4
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
📦Packet
↗ fromnat_router
↘ toserver
📄 payloadTCP Packet 203.0.113.1:8080 → 8.8.8.8:80
🔌 protocolTCP
Translated packet sent from NAT router to server.
Server responds to NAT router's public IP and port.
Hop: 5
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
📦Packet
↗ fromserver
↘ tonat_router
📄 payloadTCP Packet 8.8.8.8:80 → 203.0.113.1:8080
🔌 protocolTCP
Server sends response packet to NAT router.
NAT router looks up NAT table to translate response packet.
Hop: 6
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
📦Packet
↗ fromserver
↘ tonat_router
📄 payloadTCP Packet 8.8.8.8:80 → 203.0.113.1:8080
🔌 protocolTCP
Response packet received at NAT router.
NAT table entry found for port 8080.
NAT router rewrites response packet destination to internal client.
Hop: 7
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
📦Packet
↗ fromnat_router
↘ toclient
📄 payloadTCP Packet 8.8.8.8:80 → 192.168.1.100:12345
🔌 protocolTCP
Response packet destination translated back to internal client IP and port.
NAT router forwards response packet to client.
Hop: 8
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
📦Packet
↗ fromnat_router
↘ toclient
📄 payloadTCP Packet 8.8.8.8:80 → 192.168.1.100:12345
🔌 protocolTCP
Translated response packet sent to internal client.
Communication cycle complete; client received server response via NAT.
Hop: 9
Client 192.168.1.100
NAT Router 203.0.113.1
Server 8.8.8.8
Client received response packet.

Key Takeaways

✓ NAT translates private IP addresses and ports to public IP and ports to enable communication with external networks.

This insight is hard to see from code alone because the dynamic rewriting of packet headers and maintenance of NAT tables is abstracted away.

✓ Port forwarding allows external hosts to reach specific internal hosts by mapping external ports to internal IP and ports.

Visualizing the packet flow shows how port forwarding selectively translates packets, which is difficult to understand from static diagrams.

✓ NAT maintains state for bidirectional communication, translating packets both outbound and inbound to preserve session continuity.

Watching the response packet being reverse translated clarifies how NAT supports seamless two-way communication.

Practice

(1/5)
1. Which component in a CDN architecture is primarily responsible for serving cached content closest to the user to reduce latency?
easy
A. Edge server located near the user's geographic region
B. Origin server that stores the master copy of content
C. DNS server that resolves domain names to IP addresses
D. Load balancer distributing requests among origin servers

Solution

  1. Step 1: Identify the role of the origin server

    The origin server holds the original content but is usually far from the user, causing higher latency.
  2. Step 2: Understand the edge server's function

    Edge servers cache content closer to users geographically, reducing latency by serving requests locally.
  3. Step 3: Clarify DNS server's role

    DNS servers resolve domain names but do not serve content directly.
  4. Step 4: Load balancer's responsibility

    Load balancers distribute traffic among origin servers but do not cache content at the edge.
  5. Final Answer:

    Option A -> Option A
  6. Quick Check:

    Edge servers reduce latency by caching content near users, which is the core CDN principle.
Hint: Edge servers = cached content near users -> low latency
Common Mistakes:
  • Confusing origin server with edge server
  • Assuming DNS servers serve cached content
  • Thinking load balancers cache content
2. You are designing a live video streaming app where minimal delay is critical, and occasional frame loss is acceptable. Which transport protocol is most suitable?
easy
A. TCP, because it uses congestion control to avoid packet loss
B. TCP, because it guarantees delivery and order of packets
C. UDP, because it provides faster transmission without waiting for acknowledgments
D. UDP, because it establishes a connection before sending data

Solution

  1. Step 1: Identify the key requirement -- minimal delay with acceptable occasional loss

    Live video streaming prioritizes speed over perfect reliability.
  2. Step 2: Analyze TCP characteristics

    TCP guarantees delivery and order but introduces delay due to acknowledgments and retransmissions.
  3. Step 3: Analyze UDP characteristics

    UDP is connectionless and does not wait for acknowledgments, enabling faster transmission at the cost of possible packet loss.
  4. Step 4: Evaluate options

    UDP, because it provides faster transmission without waiting for acknowledgments correctly matches the scenario needs. TCP options prioritize reliability over speed. UDP does not establish a connection before sending data, so that option is incorrect.
  5. Final Answer:

    Option C -> Option C
  6. Quick Check:

    UDP is preferred for real-time applications where speed matters more than reliability.
Hint: Use UDP for speed when some loss is okay; TCP for reliability when loss is not acceptable.
Common Mistakes:
  • Assuming TCP is always better because it guarantees delivery
  • Believing UDP establishes a connection like TCP
  • Confusing congestion control with speed priority
3. Why might NAT64 not be a suitable long-term solution for IPv6 transition despite enabling IPv6-only clients to access IPv4 servers?
medium
A. Because NAT64 requires all IPv4 addresses to be globally routable, which is not always true
B. Because NAT64 increases header size significantly, causing fragmentation issues
C. Because NAT64 cannot translate IPv6 multicast addresses to IPv4
D. Because NAT64 requires dual-stack support on all devices

Solution

  1. Step 1: Understand NAT64 limitations

    NAT64 translates IPv6 to IPv4 but depends on reachable IPv4 addresses.
  2. Step 2: Analyze options

    Because NAT64 requires all IPv4 addresses to be globally routable, which is not always true correctly identifies the limitation that many IPv4 addresses are private or non-routable, limiting NAT64's reach. Because NAT64 increases header size significantly, causing fragmentation issues is incorrect; NAT64 does not increase header size significantly. Because NAT64 cannot translate IPv6 multicast addresses to IPv4 is true but less critical as multicast translation is rare. Because NAT64 requires dual-stack support on all devices is false; NAT64 is used to avoid dual-stack on clients.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    NAT64 depends on globally routable IPv4 addresses, which limits its scope.
Hint: NAT64 needs reachable IPv4 addresses, which aren't always available [OK]
Common Mistakes:
  • Assuming NAT64 requires dual-stack everywhere
  • Overestimating header overhead in NAT64
  • Ignoring IPv4 address reachability constraints
4. Which of the following statements about IPv6 headers is INCORRECT?
medium
A. IPv6 headers have a fixed length of 40 bytes, simplifying processing
B. IPv6 headers include a checksum field to ensure header integrity
C. IPv6 removes the header checksum present in IPv4 to reduce processing overhead
D. IPv6 headers support extension headers to add optional information

Solution

  1. Step 1: Recall IPv6 header structure

    IPv6 headers have fixed length and no checksum field.
  2. Step 2: Analyze options

    IPv6 headers have a fixed length of 40 bytes, simplifying processing is correct; IPv6 headers are fixed at 40 bytes. IPv6 headers include a checksum field to ensure header integrity is incorrect; IPv6 does not have a checksum field. IPv6 removes the header checksum present in IPv4 to reduce processing overhead is correct; checksum was removed to speed up processing. IPv6 headers support extension headers to add optional information is correct; extension headers provide optional info.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    IPv6 relies on upper-layer checksums, not header checksum.
Hint: IPv6 headers have no checksum field [OK]
Common Mistakes:
  • Assuming IPv6 headers have checksums like IPv4
  • Confusing extension headers with fixed header fields
5. Which of the following statements about the OSI Model is INCORRECT?
medium
A. The Data Link Layer is responsible for error detection and correction on the physical link.
B. The Network Layer is responsible for end-to-end reliable data delivery.
C. The Session Layer manages the establishment, maintenance, and termination of sessions.
D. The Physical Layer transmits raw bits over a physical medium.

Solution

  1. Step 1: Review Network Layer responsibilities

    The Network Layer handles routing and forwarding but does NOT guarantee reliable delivery.
  2. Step 2: Identify which layer ensures reliability

    Transport Layer provides end-to-end reliability, not Network Layer.
  3. Step 3: Validate other statements

    Data Link Layer handles error detection/correction on physical links, Session Layer manages sessions, Physical Layer transmits bits.
  4. Final Answer:

    Option B -> Option B
  5. Quick Check:

    Network Layer does NOT guarantee reliability [OK]
Hint: Reliability is Transport Layer's job, not Network Layer's [OK]
Common Mistakes:
  • Assuming Network Layer guarantees reliable delivery
  • Confusing Session Layer with Transport Layer
  • Misunderstanding Data Link Layer's error handling