NAT in Cloud and Hosting: Private Instances Talking to the Internet

Why NAT Shows Up Everywhere in Cloud and Hosting

In hosting and cloud networks, many instances live on private IPs that are not reachable from the public internet. NAT (Network Address Translation) is the mechanism that rewrites IP addresses (and often ports) so private systems can either reach the internet (outbound) or be reached from it (inbound). In cloud terms, NAT commonly appears as egress NAT (for outbound access) and as public endpoints (load balancers, reverse proxies, or port-forward rules) for inbound access.

Think of NAT as a controlled “address boundary” between private networks and public networks. The key operational skill is recognizing which direction you need (outbound vs inbound), what device/service performs the translation (NAT gateway, firewall, load balancer, reverse proxy), and how to verify it using logs and routing/policy checks.

SNAT: Outbound Internet Access from Private IPs

What SNAT does

SNAT (Source NAT) rewrites the source address of outbound packets. A private instance (for example, 10.10.1.10) sends traffic to the internet, but the internet cannot route back to that private address. SNAT replaces the source IP with a public IP owned by your NAT device/service, so replies return to that public IP and can be translated back to the original private instance.

In cloud environments, SNAT is typically provided by a managed NAT gateway, a firewall appliance, or sometimes by a node acting as an egress router. The private instance usually has a default route pointing to a private gateway, and that gateway (or a route table) forwards “internet-bound” traffic to the NAT service.

Common cloud/hosting patterns

• Private subnets + NAT gateway: Instances have no public IP. Their route table sends 0.0.0.0/0 to a NAT gateway in a public subnet (or equivalent construct).
• Firewall as egress: A virtual firewall does SNAT and enforces outbound policy (allowed destinations/ports).
• Kubernetes/containers egress: Pods have internal IPs; node or egress gateway performs SNAT so outbound traffic appears from node/NAT public IP.

Step-by-step: validating SNAT for a private instance

The goal is to confirm: (1) the instance routes internet traffic to the NAT path, (2) NAT is translating, and (3) return traffic is allowed.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• Step 1 — Confirm the instance is truly private: verify it has only a private IP and no direct public IP assignment.
• Step 2 — Check the instance’s default route: the default route should point to the VPC/VNet gateway or next hop that leads to NAT (not to a dead-end or isolated route table).
• Step 3 — Verify the subnet/route table has an internet egress path: ensure 0.0.0.0/0 (and ::/0 for IPv6 if used) points to the NAT service or firewall that performs SNAT.
• Step 4 — Test outbound connectivity by IP and by name: use an IP-based test (to avoid DNS confusion) and then a name-based test (to include DNS). For example, test HTTPS to a known external IP and then to a domain.
• Step 5 — Verify the observed public source IP: from the instance, call an external “what is my IP” endpoint. The returned IP should match the NAT gateway’s public IP (or one of its egress IPs).
• Step 6 — Check NAT/firewall logs and counters: look for a session/flow showing private source translated to public source, and confirm return traffic is permitted.

Failure signature: can ping gateway but cannot reach external sites (missing NAT route)

This is a classic symptom in private subnets: local connectivity works (the gateway is reachable), but there is no functional path to the internet.

• What it usually means: the subnet route table does not send 0.0.0.0/0 to a NAT gateway/firewall, or the NAT gateway is not attached/healthy, or egress is blocked by policy.
• How it looks: ping to the default gateway works; ping/traceroute to an external IP fails; TCP connections time out.
• What to check: route table association for the subnet, presence of a default route to NAT, NAT service health/attachment, and any egress firewall rules/policies.

Troubleshooting SNAT with source IP verification

When outbound is “sort of working” or intermittently failing, verifying the source IP seen by external systems is one of the fastest ways to confirm which egress path is being used.

• Web server logs on an external endpoint: confirm the client IP is the NAT public IP, not an unexpected address.
• Cloud flow logs/firewall logs: confirm a translation entry exists (private source → NAT public source) and that return traffic is allowed.
• Multiple NAT IPs: if the NAT service uses a pool, confirm all egress IPs are allowlisted by any third-party services you call.

DNAT / Port Forwarding: Inbound Access to Private Services

What DNAT does

DNAT (Destination NAT) rewrites the destination address (and often port) of inbound traffic. A client connects to a public IP (or public VIP) and the NAT device forwards that traffic to a private IP/port behind it. This is the basis of port forwarding and many “public endpoint → private service” designs.

In cloud hosting, DNAT is commonly implemented by:

• Public load balancers: clients connect to a public VIP; traffic is forwarded to private backends.
• Reverse proxies with public IPs: NGINX/HAProxy/Envoy receives on a public interface and proxies to private upstreams.
• Firewall DNAT rules: a firewall maps public IP:port to private IP:port.

Step-by-step: publishing a private service with DNAT/port forwarding

This checklist focuses on the minimum moving parts: a public endpoint, a translation/forwarding rule, and allowed inbound traffic.

• Step 1 — Identify the private target: private IP and port of the service (for example, 10.10.2.20:443).
• Step 2 — Choose the public entry point: a public IP (or load balancer VIP) and listening port (for example, 203.0.113.10:443).
• Step 3 — Configure DNAT/forwarding: map public IP:port → private IP:port. Ensure the forwarding device has reachability to the private subnet.
• Step 4 — Open inbound policy at the edge: allow the internet source ranges you want (0.0.0.0/0 for public services, or restricted ranges for admin access) to the public IP:port.
• Step 5 — Open policy on the private side: allow traffic from the forwarding device/load balancer to the private target port (often the source will be the load balancer subnet or firewall inside interface).
• Step 6 — Validate from outside: test from a network not inside your cloud/VPC/VNet. Confirm TCP handshake and application response.
• Step 7 — Confirm what the backend sees as the client IP: depending on the device, the backend may see the load balancer/proxy IP unless client IP preservation headers/proxy protocol are enabled.

Failure signature: outbound works but inbound fails (no DNAT/public endpoint)

It’s common to have private instances that can reach the internet via SNAT, but nothing can reach them from the internet because no public endpoint exists.

• What it usually means: you have egress NAT, but you did not create a public IP, load balancer, reverse proxy, or DNAT rule to publish the service.
• How it looks: the instance can download updates and call APIs, but external clients time out when connecting to the service.
• What to check: existence of a public listener (public IP/VIP), correct forwarding rule to the private target, and inbound security policy at the edge.

Troubleshooting DNAT with logs and source verification

Inbound issues are easiest to isolate by checking each hop: public listener → translation/forwarding → backend acceptance.

• Edge device/load balancer logs: confirm the connection arrives at the public endpoint and is forwarded to the backend target.
• Backend service logs: confirm whether requests arrive at all. If they arrive, check whether the backend is rejecting them (TLS mismatch, host header mismatch, auth, etc.).
• Client IP visibility: if the backend only sees the proxy IP, enable and trust the appropriate mechanism (for example, X-Forwarded-For or PROXY protocol) so you can correlate client behavior and apply rate limits correctly.

Load Balancers and Reverse Proxies as “NAT-like” Address Translation

How they relate to NAT concepts

Load balancers and reverse proxies often behave like specialized NAT devices:

• Public VIP to private backends: clients connect to a public address; the device forwards to private addresses (similar to DNAT).
• Connection termination and re-origination: many reverse proxies terminate TCP/TLS and open a new connection to the backend. From the backend’s perspective, the source may be the proxy, not the original client (a form of source address “hiding”).
• Health checks and target selection: unlike simple DNAT, load balancers choose among multiple backends and remove unhealthy ones.

Practical implications you actually troubleshoot

• Backend allowlists: if your backend firewall only allows “the internet,” it may still block traffic because the immediate source is the load balancer/proxy subnet. Ensure backend rules allow the load balancer/proxy source addresses.
• Client IP preservation: if you need real client IPs for logging, geo rules, or rate limiting, configure the load balancer/proxy to pass client IP information and configure the app to trust it only from the proxy.
• Asymmetric expectations: a load balancer might be reachable publicly, but backends might not have return routing or security policy to respond to the load balancer health checks, causing “unhealthy targets” even though the app is running.

Failure signatures tied to load balancers/reverse proxies

• Public endpoint responds, but app logs show no client IPs: the proxy is not forwarding client IP headers, or the app is not configured to log them.
• Load balancer shows unhealthy backends: health check port/path is blocked, wrong, or the backend only allows traffic from a different source range than the load balancer uses.
• Works from inside the VPC/VNet but not from the internet: you are testing the private service directly internally, but the public listener/forwarding rule (DNAT/load balancer listener) is missing or misconfigured.

Focused Troubleshooting Workflow: Egress Routes/Policies and Source IP Checks

When outbound fails from private instances

• Verify routing: confirm the subnet has a default route to the NAT service/firewall and that the NAT service has a path to the internet.
• Verify egress policy: confirm outbound rules allow the destination IP/port (and that return traffic is allowed/stateful tracking is working).
• Verify translation: check NAT logs/flow logs for a translation entry and confirm the public egress IP is what you expect.

When inbound fails to a private service

• Verify a public entry point exists: public IP/VIP and listener port must exist (DNAT rule, load balancer listener, or reverse proxy bind).
• Verify forwarding to the correct private target: correct private IP and port, correct target group membership, correct health check configuration.
• Verify backend acceptance: backend security policy allows traffic from the forwarding device, and the service is listening on the expected interface/port.
• Verify source IP expectations: confirm whether the backend should see client IP or proxy IP; configure headers/proxy protocol and logging accordingly.

# Quick source-IP verification ideas (conceptual, tool-agnostic)  1) From the private instance, call an external IP-echo service and record the public IP.  2) In NAT/firewall logs, find the session and confirm private-src -> public-src translation.  3) For inbound via proxy/LB, compare: edge logs (client IP) vs backend logs (seen source IP).  4) If backend sees only proxy IP, enable X-Forwarded-For / PROXY protocol and update app log format.