The usual advice for an unreachable home service is straightforward: create a port-forwarding rule on the router, point it at the server, and allow the same port in the server firewall. That sequence works when the router owns the public IPv4 address. It fails completely when the ISP has placed the connection behind carrier-grade NAT, even when every setting on the home network is correct.
Taipan Transit uses a different path. The public IPv4 stays on Taipan's network instead of being assigned to the home router or 4G modem. The server opens a tunnel outward to Taipan, and Taipan routes the public IPv4 through that already-established tunnel. Because the connection begins from the restricted network, CGNAT does not need to accept a new inbound connection or reserve a port.
The port-forwarding rule is on the wrong router
In an ordinary home connection, a provider assigns one public IPv4 to the WAN side of the router. When a client connects to that address on a chosen port, the router receives the packet. Its port-forwarding rule replaces the destination with the private address of the server, for example a NAS, game server, or web application. The return packet passes through the same router and appears to come from the public address.
Carrier-grade NAT adds another translation before the home router. The ISP gives the router an address from an internal pool, then shares one public IPv4 between multiple subscribers at a gateway in its network. A client on the Internet reaches that provider gateway first. The gateway has no rule identifying the home server, so it cannot send the packet any farther.
The gateway does create temporary mappings for connections that start from the home network. When the server opens an outbound connection, the gateway can remember the source address and port long enough for the reply to return. That is why browsing, video calls, game clients, and an outbound WireGuard tunnel can work behind CGNAT. A new connection started by a stranger on the Internet has no matching entry. It is dropped before the home router can inspect it.
Fixed public ports make the limitation especially clear. There is only one TCP port 443 on a shared IPv4 address, so the provider cannot send that port to every subscriber using the address. Some operators offer a public IPv4 or an allocated port range as an add-on. If the service needs a conventional address, ask specifically whether the offer is a dedicated public IPv4, whether it is reachable inbound, and whether it is static. A dynamic public IPv4 can still support forwarding if DNS is updated, while a shared address cannot.
This is why changing a router brand, enabling UPnP, or trying several external ports does not solve the underlying problem. Those changes affect only the second translation, inside the home. They cannot create a mapping on the first translation controlled by the ISP. The shared address range defined for this use is 100.64.0.0/10, although providers may also use private RFC 1918 ranges on the WAN side.
A connection that times out is the common symptom, but it is not proof by itself. A stopped service or a host firewall produces a similar result. Confirm the path before changing the design or paying for an alternative.
Check the path before changing anything
Start with the WAN IPv4 displayed in the router or modem status page. Then compare it with the IPv4 reported by an external address-check service from a device on that same connection. If the two values differ, the connection passes through an upstream translation. A WAN address in 100.64.0.0/10, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 also indicates that the router does not hold a public IPv4.
If the values match and the WAN address is publicly routable, do not assume CGNAT is involved. Verify that the server is listening on the intended port, that it has a stable private address, that the forwarding rule uses the correct protocol, and that the host firewall allows the connection. Test from mobile data or a different Internet connection. Testing through the same home Wi-Fi can be misleading because routers do not all handle connections back to their own public address in the same way.
Check TCP and UDP separately. A router rule for TCP does not open UDP, and a successful TCP test says nothing about a UDP game or VPN service. If the service has a documented external port, test that port from outside and confirm the server log records the attempt. This separates a routing failure from an application that is simply not listening.
Dynamic DNS does not change either result. It can update a hostname when a reachable public address changes. It cannot make a private or shared WAN address accept an inbound connection. IPv6 may be a valid solution when the service and all of its users can use IPv6, but it does not create IPv4 reachability for clients that have only IPv4.
Why a Taipan tunnel works through home, 4G, and 5G CGNAT
The important direction is from the server to Taipan. A WireGuard client on the server sends the first packet to Taipan's public endpoint. The mobile carrier, ISP, or apartment network treats it like any other outbound UDP flow and records a temporary return mapping. Taipan can then send encrypted tunnel packets back through that mapping. The connection does not depend on the 4G modem, home router, or carrier accepting a fresh connection from the Internet.
Taipan receives the actual client connection on the dedicated public IPv4. It encapsulates that traffic inside the tunnel and sends it to the server. The server's replies return through the tunnel, reach Taipan, and leave with the same public IPv4 source address. From the client's perspective, it is communicating with one stable public IP. The changing or shared address used by the 4G connection never appears in that public exchange.
This also explains why an IP change on a mobile connection does not change the public address given to users. If the mobile network reconnects, the WireGuard client establishes a new outbound session to Taipan. The assigned public IPv4 and its DNS record remain at Taipan. Existing connections will reconnect, but users do not need a new address or a new router rule.
WireGuard needs outbound UDP to Taipan's endpoint. Most consumer and mobile networks allow this, but some captive portals, corporate networks, and restricted mobile plans can block or filter it. Verify the tunnel handshake before exposing the service. Taipan also supports GRE and IPsec for environments where those transports better fit the network requirements.
Give the server a public entry point
A routed IPv4 design therefore keeps the home or mobile connection behind CGNAT while moving the public entry point to Taipan. It is appropriate when the service needs a normal public IP rather than an HTTP proxy or a private VPN. Game servers, self-hosted VPN endpoints, SSH, mail, and arbitrary TCP or UDP applications can use the routed address because Taipan delivers packets at the IP layer, not only as web requests.
The first operational step is to create the tunnel from the home server and confirm that it remains connected. The provider then routes the assigned IPv4 through it. The server must send traffic sourced from that address back through the tunnel, rather than through the household ISP. This return-path rule matters: without it, an incoming connection can reach the server while its replies leave through a different address and the client discards them.
| Item | Why it matters |
|---|---|
| Tunnel endpoint | The home side initiates this connection outward, so the ISP does not need an inbound rule. |
| Routed public IPv4 | Clients connect to this address rather than to the home router WAN address. |
| Return path | Replies sourced from the public IPv4 must leave through the tunnel. |
| Host firewall | It permits only the intended application ports after the address becomes public. |
Keep the private home LAN and the routed address logically separate. The public address belongs to the service being exposed; the household router still provides ordinary Internet access for the rest of the network. If several VMs or containers need distinct public identities, route the addresses to a gateway or hypervisor and assign each one deliberately. Do not use a broad NAT rule that rewrites their public source addresses, because it defeats the purpose of routing them.
After the route is in place, the final security decision is the same one a normal port forward would require. Allow only the application port on the routed address, keep management services private or separately protected, and test from an independent network. The full Linux setup, including firewall and return-path checks, is covered in How to get a public IP for a home server. The same routed model also works for Proxmox VMs and for a Minecraft server behind CGNAT.
Taipan Transit routes dedicated public IPv4 addresses through WireGuard, GRE, or IPsec to infrastructure that sits behind CGNAT.
Frequently asked questions
Can I port forward behind CGNAT?
No. A forwarding rule on the home router cannot create a matching rule on the ISP's carrier-grade NAT gateway. The shared public IPv4 address is controlled by the ISP.
How do I know whether CGNAT is blocking port forwarding?
Compare the router WAN IPv4 with an external IPv4-check service. If they differ, or the WAN address is in 100.64.0.0/10 or another private range, an upstream NAT is present.
What is the best alternative to port forwarding behind CGNAT?
For a public service that needs arbitrary ports and protocols, route a dedicated public IPv4 through an outbound WireGuard, GRE, or IPsec tunnel. For private access, a mesh VPN can be simpler.
Does Dynamic DNS fix CGNAT?
No. Dynamic DNS can update a hostname when an address changes, but it cannot make a shared or private WAN IPv4 accept unsolicited inbound connections.