Short answer: If your home connection is behind an ISP carrier-grade NAT (CGNAT), an ordinary IPv4 port-forward on your home router may not be enough for an unsolicited connection from the public internet. The ISP gateway doing the outer translation is not under your control. For access to your own home devices, compare asking the ISP for a reachable address, using an outbound-initiated private mesh with relay fallback, or operating a public relay/server yourself. Which option works depends on your ISP, devices, network policies, and tolerance for administration.
First check whether CGNAT is actually the obstacle
- Find the IPv4 address shown on your router's internet/WAN status page.
- From a device on that home connection, use a public IP check and compare its observed IPv4 with the router's WAN IPv4. Do not post either full address publicly.
- If they differ, or the router reports a private or shared address, there may be an upstream router, ISP NAT, or another network translation. The range 100.64.0.0/10 is reserved for shared address space used in carrier-grade NAT designs, but an address comparison alone does not identify the exact network topology.
- Check whether you control a second modem/router that could be in bridge or access-point mode, and ask the ISP whether the line uses CGNAT and whether an inbound-reachable IPv4 or IPv6 service is available.
RFC 6888 describes a CGN as an ISP-side function sharing IPv4 addresses among subscribers; unlike a router in your home, subscribers do not manage that CGN. A port-forward rule on your own router changes only that router's mapping. See the public, private, and CGNAT IPv4 guide for address ranges and comparison limits, and the IP check explainer for what this browser can observe.
Choose a route for the job
| Choice | How it can work | Tradeoffs and checks |
|---|---|---|
| Ask the ISP for reachable service | An ISP may offer a public IPv4 address, a static-address option, or a supported mapping service. Then a router-based remote-access VPN can accept an inbound connection if the address, forwarding, and firewall are configured correctly. | Availability, price, address stability, and mapping support vary. Confirm that the address is actually reachable from outside and whether the ISP blocks inbound traffic. A static address is not inherently required if a dynamic hostname is supported, but it does not itself provide security. |
| Use a private mesh or overlay network | Install its clients on devices that support them, or use a supported subnet-router device at home for devices that cannot run a client. Devices make outbound connections to coordinate and attempt NAT traversal; some systems can relay encrypted traffic if a direct path cannot be established. | Check supported devices, account and access controls, subnet routing behavior, relay behavior, service limits, and what happens when the coordination or relay service is unavailable. A relayed route can have different performance. This is a service-specific example, not a guarantee that every mesh product works through every network. |
| Use IPv6, if both ends support it | If the ISP provides globally reachable IPv6 and the remote client has working IPv6, a home VPN endpoint may be reachable over IPv6 without an IPv4 port mapping. | Verify IPv6 on both networks, the router's IPv6 firewall, endpoint naming, and the exact VPN configuration. IPv6 availability does not imply that a port is open; allow only the intended VPN traffic. Some networks or clients have no usable IPv6 path. |
| Operate an external server or relay | An administrator can place a VPN endpoint on a publicly reachable server and have the home network initiate an outbound tunnel to it, then route approved remote-device traffic through that hub. | This requires server hardening, key and access management, routing and firewall work, updates, monitoring, and a provider for the public server. It can add an intermediary and a failure point. Follow the server and VPN project's official instructions; it is an advanced option, not a plug-and-play CGNAT fix. |
What a normal home port-forward can and cannot do
A port forward on a home router can direct inbound traffic that reaches the router to a device on the LAN. If a separate ISP-managed CGN sits upstream, that incoming traffic must also reach the subscriber's router through a supported mapping or another reachable address. Configuring a rule only on the home router cannot create control over the ISP's translation. The OpenWrt WireGuard server instructions describe the separate upstream-router case; Ubiquiti likewise says a public IP is necessary for port forwarding and most of its remote-access VPN options, with product-specific exceptions.
Do not expose a NAS, camera, router administration page, or other service directly just to test connectivity. If you choose any inbound route, follow the exact device maker's security guidance, restrict access where supported, keep software updated, and expose only the VPN endpoint or service you intend to make reachable. For the distinction between router forwarding and authenticated remote VPN access, see the port-forwarding decision guide.
A cautious verification sequence
- Identify the goal. List the specific home service and remote devices that need access. If you only want to reach a few devices, check whether an approved client-based mesh or the ISP's supported remote-access option meets that need.
- Check the network path. Compare the router WAN address with an outside-observed address, check for another router you control, and confirm CGNAT or IPv6 service with the ISP. The comparison is a clue, not a topology diagnosis.
- Pick one approach. Confirm support for the exact router, firmware, client device, network protocol, and account policy. Do not stack port-forward changes, disable firewalls, or alter ISP equipment without understanding the effect.
- Limit access. Use individual device identities or VPN peers where available, enable strong account authentication, and permit only the needed home subnet or service. Avoid sharing private keys or configuration QR codes.
- Test from a separate network. Use a device you control on cellular or another trusted network. Check the VPN's own connection status, then try only the intended home resource. A successful test confirms that path at that moment; it does not audit other devices, future connectivity, or the security of the home service.
- Review and remove unused access. Recheck after ISP/router changes, and revoke a peer, account, tunnel, or forwarding rule when it is no longer needed.
Remote access to your own home network is different from a commercial VPN client that routes browsing traffic through a provider. A home VPN may let an authenticated remote client reach selected LAN resources; it does not automatically make the rest of your internet use anonymous or improve the security of the service you connect to. See the router VPN decision guide and local printer and NAS troubleshooting guide.
Common questions
Will a VPN automatically bypass CGNAT?
No. A conventional VPN server waiting for inbound IPv4 connections still needs a reachable endpoint or a supported mapping. Some mesh systems initiate outbound connections and can use a relay when direct peer-to-peer connectivity fails; verify the specific service's documented behavior.
Does having an IPv6 address solve it?
Only if the home endpoint and remote client both have usable IPv6 connectivity, DNS points to the correct endpoint, and the router firewall permits the intended VPN traffic. Check the end-to-end path instead of assuming IPv6 is available everywhere.
Is a 100.64.x.x address enough to prove my ISP uses CGNAT?
It is within the shared address block reserved for carrier-grade NAT use, so it is a strong clue. Still check the router, any upstream equipment you control, and the ISP's service details to understand where translation occurs.
Should I open ports on the router anyway?
Only if the intended inbound service requires it and you have confirmed that traffic can reach your router. A local port-forward alone does not open an ISP-managed CGN mapping, and exposing a service adds security and maintenance responsibilities.
Sources
- IETF RFC 6888: Common Requirements for Carrier-Grade NATs (2013-04) — defines CGN and describes the shared-address and subscriber-control context.
- IETF RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space (2012-04) — reserves 100.64.0.0/10 for shared address space.
- OpenWrt: WireGuard peers (accessed 2026-11-03) — explains why a peer commonly needs a public IP, fixed listening port, and firewall rule for a conventional server-client setup.
- OpenWrt: WireGuard server (accessed 2026-11-03) — documents OpenWrt-specific server, firewall and upstream-router requirements, including IPv4/IPv6 considerations.
- Tailscale Docs: Connection types (validated 2026-06-01; accessed 2026-11-03) — provider-specific direct, peer-relayed and DERP-relayed connection behavior and ways to inspect connection type.
- Tailscale Docs: Remotely access devices that can't run Tailscale (validated 2026-05-18; accessed 2026-11-03) — describes the product's subnet-router approach for home LAN devices without clients.
- Ubiquiti Help Center: UniFi Remote Access — VPN and Port Forwarding (accessed 2026-11-03) — product-specific public-IP requirement for port forwarding and most listed VPN modes.
Impact — TODO: apply/approval and configure referral URL — referral link not configured.
PartnerStack — TODO: apply/approval and configure referral URL — referral link not configured.
CJ Affiliate — TODO: apply/approval and configure referral URL — referral link not configured.