Public IP vs Private IP: What Your Router Is Hiding

Your laptop may have 192.168.1.42 while your internet connection shows a completely different address. That is normal.

In most IPv4 home networks, the router translates private LAN addresses to a provider-facing address, but an ISP VPN, proxy, or carrier-grade NAT can add another boundary. This guide assumes you can view the client and router network state; test only addresses and services you own or are authorized to assess, and save existing firewall, NAT, and VPN rules before changing inbound access.

Quick reference: Private addresses are for inside networks. Public addresses are globally routed. NAT is the translation boundary between them in most home networks.

Interactive quick reference

Public IP vs Private IP: What Your Router Is Hiding

Use this card as the simple mental model, then use the article sections below for the operational details.

Start simpleVerify the result

1. Private address

Devices use private ranges such as 192.168.0.0/16, 10.0.0.0/8, or 172.16.0.0/12.

2. NAT router

The router tracks outbound connections and translates private addresses to the public WAN address.

3. Public address

The internet sees the public address assigned by the ISP or upstream network.

4. CGNAT

Some ISPs put customers behind carrier-grade NAT, which complicates inbound access.

Start Here: The Beginner Foundation

For IPv4, RFC 1918 reserves three blocks for private internets: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Organizations can reuse them without coordinating a globally unique allocation, which is why many unrelated homes contain the same address such as 192.168.1.10. Those addresses are not intended to be routed across the public Internet. They can still communicate between sites when a private routing domain or tunnel carries them and the address plans do not overlap.

A public IPv4 address is globally unique address space assigned for use outside private or special-purpose ranges, but public does not mean universally reachable. Routing announcements, provider policy, firewalls, service listeners, and translation rules still determine whether traffic can arrive. Home networks commonly use network address and port translation so many private IPv4 clients share one public address for outbound flows. Some providers add carrier-grade NAT, placing another translation boundary outside the customer's control.

IPv6 does not use the phrase private address as a direct equivalent of RFC 1918. Interfaces normally have link-local addresses and may also have global unicast or unique local addresses, with scope and routing determining use. A global IPv6 address can exist directly on a client without IPv4-style NAT; a stateful firewall can still block unsolicited inbound traffic. Diagnose each address family separately by comparing the client address, default route, customer-edge WAN state, provider delegation, and externally observed address.

The Fast Comparison

Address type	Examples	Routed on internet?	Use
Private IPv4	10.x.x.x, 172.16-31.x.x, 192.168.x.x	No	Homes, offices, labs, VLANs
Public IPv4	ISP-assigned non-private address	Yes	Internet edge
CGNAT	Often 100.64.0.0/10 on WAN	Not directly to you	ISP sharing public IPv4 addresses

Advanced Notes and Design Boundaries

Address scope, global routing, translation, and reachability are separate questions. Diagnose IPv4 and IPv6 independently, and use the IANA registries rather than guessing from the first octet or treating every address shown by a website as the router's own interface.

• RFC 1918 private IPv4 blocks are exactly 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16; not every address beginning with 172 is private.
• 100.64.0.0/10 is IETF Shared Address Space for service-provider use and is distinct from RFC 1918, even though its appearance on a WAN often accompanies carrier-grade NAT.
• An IANA special-purpose address is not automatically public merely because it is outside RFC 1918; loopback, link-local, documentation, benchmarking, and other blocks have defined non-global properties.
• IPv6 unique local addresses use fc00::/7 under RFC 4193 and are not expected to be globally routed, while link-local fe80::/10 addresses are confined to a link and require interface context in many tools.
• A globally scoped address describes addressing and routing intent, not exposure: ingress filtering, stateful firewall policy, host firewall rules, and application binding still control reachability.

Troubleshooting Workflow

Build an address-path record before editing port forwards or VPN policy: client address, prefix, route, router LAN and WAN addresses, provider handoff, externally observed address, DNS result, and firewall decision. A test must use the same IP family and source location as the failing application or it may exercise a different path.

1. Record every relevant IPv4 and IPv6 client address with prefix length, interface, default route, and DNS resolver; do not classify by appearance alone.
2. Check each address against the IANA special-purpose registries and the exact RFC 1918, shared, link-local, unique-local, or global prefix definition.
3. Record the customer router's WAN addresses and delegated IPv6 prefix, then compare them with an externally observed address using the same IP family.
4. Trace the intended inbound and outbound path, identifying customer NAT, provider CGN, VPN, proxy, firewall, and route boundaries in both directions.
5. Test local gateway, provider-side reachability, and target service by address family, then inspect route and firewall logs rather than assuming NAT is the failure.
6. For remote access, verify a stable destination, correct translation or IPv6 firewall rule, application listener, DNS record, and non-overlapping private routes before retesting externally.

Evidence and Acceptance Tests

Evidence status: documentation-backed. TechGeeks reviewed IETF and IANA address definitions plus independent CGN measurement research; no ISP circuit, NAT implementation, IPv6 firewall, or port-forwarding lab was operated for this article.

• Save redacted client, router, VPN, and externally observed IPv4/IPv6 values with interfaces, prefixes, routes, test source, DNS answers, and UTC time.
• For outbound acceptance, verify the client reaches the intended destination over the expected family and record the egress address and route without assuming that a successful web request tests inbound reachability.
• For inbound acceptance, test from a genuinely external network and require the expected translation or IPv6 firewall hit, listener response, and source restriction while an unapproved port remains blocked.
• For a site VPN, verify both directions, non-overlapping prefixes, DNS behavior, and at least one denied network as well as the permitted destination.
• Remove the test forward, temporary firewall rule, or tunnel and confirm the previous exposure and routing state are restored.

Security, Privacy, and Recovery Boundaries

• A private address is not a trust label and NAT is not a substitute for firewall policy, authentication, patching, or encrypted remote access.
• Public addresses, timestamps, DNS names, provider details, and NAT logs can identify a subscriber or reveal service use. Redact them from screenshots and retain mapping logs only for authorized operational or legal needs.
• Do not scan third-party addresses, bypass provider controls, or publish another subscriber's connection data without authorization. Provider logging and disclosure obligations vary by jurisdiction.
• Keep a local management path, export the current edge configuration, and time-limit every diagnostic allow rule. Roll back by removing the new exposure and restoring the previous route, NAT, DNS, and firewall entries as one documented set.

What This Does Not Mean

• An IP-check website showing a public address does not prove that address is configured on your router or that unsolicited inbound traffic can reach it.
• A WAN address in 100.64.0.0/10 is evidence of shared address space, but it does not by itself reveal the provider's complete CGN topology, mapping policy, or inbound service options.
• A successful ping or trace does not prove the application listener, NAT rule, return path, DNS name, or stateful firewall policy is correct.
• A global IPv6 address does not prove exposure, and a private IPv4 address does not prove encryption, isolation, or trust.

Real-World Use Cases

• Use private IPs freely inside your LAN design.
• Use DNS names instead of memorizing private addresses.
• Use VPN or tunnel access instead of opening ports casually.
• Check for CGNAT before troubleshooting failed port forwarding.

Failure Patterns to Recognize

• Port forwarding does not work because the WAN address is private or CGNAT.
• Two networks use the same private range and VPN routing conflicts.
• A device gets a public IP when it should be behind a firewall.
• Remote users try to reach a private address from the internet.

Common Mistakes

• Assuming 192.168.x.x is unique worldwide.
• Opening a port without understanding which private host receives it.
• Using the same LAN subnet at home and at a remote site.
• Blaming DNS when the route to a private network does not exist.

Quick Checklist

• Compare client IP, router LAN IP, router WAN IP, and public IP from a test site.
• Check whether the WAN IP is private or CGNAT.
• Document private ranges per VLAN/site.
• Use VPN routes for private networks.
• Avoid overlapping subnets.

Common Questions

Why is my router WAN address different from an IP-check website?

Traffic may cross an upstream NAT, carrier-grade NAT, VPN, or application proxy before reaching the site. Compare using the same IPv4 or IPv6 family, because a dual-stack client may use a different path than the router page suggests. A WAN IPv4 address in RFC 1918 or 100.64.0.0/10 is a useful clue, but provider documentation or a trace is needed to identify the architecture.

Why does port forwarding fail behind carrier-grade NAT?

A customer router can translate only traffic that reaches its own WAN address. Under CGN, the provider controls another mapping from shared customer-side space to a public IPv4 address, so an unsolicited inbound connection normally has no subscriber-controlled mapping through that outer translator. Options depend on the provider and may include public IPv4 service, native IPv6 with firewall policy, or an outbound VPN or tunnel.

Is 172.40.1.5 a private IPv4 address?

No. Only 172.16.0.0 through 172.31.255.255, represented as 172.16.0.0/12, is RFC 1918 private space. Addresses elsewhere in 172.0.0.0/8 must be classified through current allocation and special-purpose registries. Avoid rules that treat every 172.x.x.x address as private.

Can two sites use the same private subnet?

They can operate independently, but connecting them with a routed VPN creates ambiguous destinations when prefixes overlap. Renumbering is the cleanest long-term fix. Policy NAT or selective translation can work in constrained designs but adds operational complexity, obscures endpoint identity, and must be applied consistently with DNS, routes, and security policy.

Useful Gear And Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

Buy edge hardware for the actual requirement: native IPv6, VPN throughput, stateful firewall policy, VLANs, update support, logging, and a recoverable configuration. A new router cannot give you subscriber-controlled inbound IPv4 through provider CGN unless the service or an outbound tunnel supplies that path.

• Amazon search: WiFi router with VPN support
• Amazon search: managed switch for home network

Related TechGeeks Reading

• Remote Access Without Opening Router Ports
• 15 Router Security Settings to Audit Before Something Breaks
• Networking Field Notes: Start Here

References

• RFC 1918: Address Allocation for Private Internets
• RFC 3022: Traditional IP Network Address Translator
• RFC Editor: RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space
• IANA: IPv4 Special-Purpose Address Space
• RFC Editor: RFC 4291, IP Version 6 Addressing Architecture
• RFC Editor: RFC 4193, Unique Local IPv6 Unicast Addresses
• Independent research: A Multi-perspective Analysis of Carrier-Grade NAT Deployment

Last technical review for this Quick Reference draft: July 15, 2026. Before publication, recheck IANA registry properties, the cited RFC status, provider CGN and IPv6 options, and every remote-access recommendation against current router firmware.