A remote PLC, camera, gateway or meter can have a healthy cellular connection and still be unreachable from the public internet. When that happens, the first question is not “Which port should I forward?” It is “Can unsolicited inbound traffic reach this SIM connection at all?”
Carrier-grade NAT, or CGNAT, is a common reason for this mismatch. The mobile operator can place many subscribers behind an upstream translation layer, allowing the remote site to start outbound sessions while preventing a new connection from the public internet from being routed directly back to one individual subscriber.
Before replacing an LTE router , compare the IP address shown on its cellular WAN interface with the public IP address visible from the internet. Then confirm the mobile operator’s inbound-access policy. Those checks often tell the project team more than another round of port-forwarding changes.
Internet access does not prove public inbound reachability. If the LTE WAN address is private, belongs to shared carrier address space, or differs from the public IP visible to the internet, another NAT layer exists upstream. The practical recovery path may be a public IP SIM, a private APN or a router-initiated VPN rather than another local forwarding rule.
Telemetry, web access, cloud sessions or software updates leave the site normally.
An engineer cannot initiate a session from an office, service centre or external network.
Record both addresses before changing hardware, NAT rules or application settings.
Why outbound internet works while direct inbound access fails
The important difference is who starts the session. When the field site starts a connection, the carrier can create translation state and return the response. A completely new inbound request may arrive at the carrier NAT with no mapping that identifies which subscriber should receive it.
1. Recognize private and carrier-grade NAT addresses
The router’s cellular WAN address is the fastest place to start. Private IPv4 space cannot be treated as a normal internet-routable destination, and carrier shared address space indicates that address translation may be occurring inside the service-provider network.
The 100.64.0.0/10 block is particularly relevant because it is reserved as shared
IPv4 address space for service-provider address sharing. If the LTE interface receives an
address from this range, do not assume that the site can be addressed directly from the public
internet.
The address assigned to the LTE interface.
The address an external service sees for the outbound connection.
A matching public address still does not prove that the carrier accepts every inbound service. Operators can apply filtering or service-specific restrictions. Treat the address comparison as evidence that tells the support team what to ask next, then confirm the actual SIM service with the carrier.
2. Test whether inbound traffic can actually reach the SIM
A failed remote connection should be broken into layers. This prevents a working PLC or camera from being blamed for a carrier-side problem, and it prevents the carrier from being blamed for a service that is not listening locally.
The camera uploads normally, but direct maintenance times out
An unattended site has been sending camera footage, telemetry or PLC data to a cloud service for months. The router shows an active LTE connection. Later, an engineer attempts to connect directly from an office network and receives no response.
That pattern does not prove the router has failed. The cloud connection was started from the field side; the maintenance session is being started from outside. Before changing hardware, determine whether that second traffic path can reach the LTE WAN at all.
Confirm that the PLC, camera, gateway or service responds from the local LAN on the expected address and port.
Local IP, application port and a successful LAN-side connection.
Capture the address shown on the LTE interface. “Connected” is a status, not proof of public reachability.
WAN address, APN and the time the address was observed.
From behind the cellular connection, determine the public IP seen by an external service and compare it with the WAN value.
Both addresses side by side rather than a note saying only “internet works.”
Use an office connection, another carrier or the intended management network. An internal test proves the application works; it does not prove cellular inbound reachability.
Source network, destination address, service port and observed result.
Confirm whether the SIM uses CGNAT, whether unsolicited inbound sessions are permitted and whether public-IP or private-network services are available.
The operator’s confirmed addressing and inbound-access policy.
3. Choose a remote-access path after confirming CGNAT
Once the failing layer is known, the project can choose a network design instead of trying to “fix CGNAT” inside the router. Public IP, private APN and outbound VPN solve different problems, and the right choice depends on traffic direction, security policy and the existing central infrastructure.
No. “Static” means the address remains consistent. It does not make a private address publicly routable. A static private SIM address can still sit behind carrier translation.
No. If the site only uploads telemetry, connects to a cloud platform or initiates its own VPN, direct public inbound access may add no practical value. Buy the carrier service that matches the actual traffic direction rather than assuming every remote site needs a public IP.
DDNS can keep a hostname associated with a changing public-facing address, but it does not create an inbound mapping through carrier NAT. If the SIM is not publicly reachable, a hostname alone does not make it reachable.
4. Avoid unsafe port forwarding
Port forwarding is useful only when the LTE router controls the NAT boundary that receives the inbound packet. Under CGNAT, there is an additional translation layer upstream. A rule created on the field router cannot instruct the carrier network to deliver a new unsolicited session to that SIM.
That explains a familiar troubleshooting pattern: the local device responds correctly, the forwarding rule looks correct and outbound internet access works, yet an external connection still times out. The configuration on the field router may be valid; the packet simply never arrives there.
5. Choose a recovery path for an existing deployment
Do not replace the router first. If the installed SIM remains behind the same carrier CGNAT after the replacement, the new hardware may produce exactly the same remote-access failure. Change hardware only when the final recovery architecture requires functions the current router does not provide.
Direct inbound access is genuinely required
Confirm whether the operator can provide a suitable public IP service and permit the required inbound traffic. If systems depend on a consistent destination, also confirm whether the public address must be static.
Recovery direction: public IP SIMThe organisation already operates private carrier connectivity
Evaluate a private APN path into the OT or management network. The important question is whether authorised central systems have a routed path to the field subnet, not whether the field address is public.
Recovery direction: private APNThe SIM cannot easily be changed
Consider a router-initiated VPN. This is often the practical direction when outbound LTE is stable but direct inbound access is blocked by carrier NAT. The field site establishes the tunnel and the central network controls who may use it.
Recovery direction: outbound VPNThe site is unattended and losing cellular access also removes maintenance access
In that case, redundancy becomes part of the remote-access design. A second cellular path can matter more than adding another forwarding rule because the VPN or private route is only useful while the WAN itself remains available.
Recovery direction: cellular redundancy plus VPN or private routing6. Match the LTE router to the recovery architecture
Router selection should happen after the network path is defined. The goal is not to find a router that “removes CGNAT.” The goal is to choose a router that supports the interfaces, VPN architecture, management method and redundancy required by the chosen recovery path.
Choose the hardware by what the remote site must do next
E-Lins offers multiple industrial LTE routers for remote sites . The three directions below fit different field conditions. They are not a good-better-best ranking, and changing models by itself does not change the carrier’s CGNAT policy.
H685t IoT 4G Router
H685t is a logical direction when the field site is compact and needs cellular routing, Ethernet and, depending on the ordered interface option, a serial connection for equipment such as a PLC, meter, controller or telemetry device. E-Lins lists VPN support including PPTP, L2TP, IPsec and GRE for the H685t family, so it can be considered when the remote-access design uses an established tunnel rather than unrestricted direct inbound exposure.
Small control cabinets, metering projects, compact M2M gateways and remote equipment sites where a single-router cellular gateway is sufficient.
Check before ordering: carrier bands, exact serial requirement, VPN protocol, power method, APN type and whether the project needs a public address or site-initiated tunnel.
View H685t
H820t IoT 4G Router
H820t becomes especially relevant when the recovery path depends on a router-initiated VPN and the site needs more network flexibility than a very compact gateway. E-Lins lists IPsec, GRE, L2TP, OpenVPN, ZeroTier, WireGuard and DMVPN options on the current H820t product family, together with Ethernet, optional serial/PoE configurations and remote-management functions.
Remote PLC, telemetry, CCTV and industrial equipment sites where the project needs a controlled VPN path back to a central network and may also require Ethernet or serial integration.
Check before ordering: the exact VPN protocol, encryption/authentication requirements and firmware required, central VPN endpoint, serial interface, PoE requirement, carrier service and the address expected on the cellular WAN.
View H820t
H720tt-G Dual SIM 4G Router
H720tt-G fits a different problem. If the VPN or private route is the maintenance path, losing the cellular WAN also removes remote support. The H720 series supports dual-SIM cellular failover, while applicable configurations can add a second cellular module; it also provides multiple Ethernet ports and VPN capability, making it relevant where the availability of the cellular path itself is part of the project requirement.
Unattended substations, telemetry sites, remote CCTV, utilities and branch installations where one carrier failure should not automatically remove the remote management path.
Check before ordering: whether the project requires one or two cellular modules, carrier diversity, the required SIM and modem failover behaviour, VPN type, serial interface and how the central network handles tunnel reconnection after a WAN change.
View H720tt-GUse the full router range when the site requirement is different
The three examples above cover compact field gateways, VPN-led industrial access and dual-SIM redundancy. A project that needs more Ethernet ports, a different serial layout, outdoor installation, another LTE category or a different power arrangement should continue through the wider industrial router range rather than selecting a model only because it appears in this guide.
Before comparing models, define the country and carrier, APN, CGNAT or public-IP status, remote device type, required VPN, Ethernet and serial interfaces, power arrangement and redundancy requirement.
7. Prove the remote-access path before the site is handed over
An LTE status page showing “connected” is not enough for project acceptance. Commissioning should prove the exact path that operators will depend on after the site becomes unattended.
Remote-access commissioning check
- Record the cellular WAN address. Keep the actual address assigned to the LTE interface.
- Record the internet-visible public address. Compare it with the WAN address and note whether upstream translation exists.
- Confirm the carrier service. Document CGNAT, public IP or private APN conditions rather than assuming them from the APN name.
- Document who starts the session. Record whether the central system connects inbound or the field router establishes an outbound tunnel.
- Test the real application. Prove PLC software, camera viewing, SCADA polling, gateway management or the actual production workflow.
- Test from the real remote side. Use the intended office, service network or central VPN environment rather than only the field LAN.
- Record firewall and NAT ownership. Future support teams should know which layer is expected to route, translate and filter traffic.
- Test recovery after WAN interruption. For VPN and dual-SIM designs, prove that the tunnel and application recover after the relevant cellular event.
The practical rule is straightforward: verify the addressing and traffic direction before troubleshooting port forwarding. If the LTE router has outbound connectivity but cannot be reached from the public internet, first establish whether CGNAT or carrier filtering is the real boundary. Then choose the access architecture and only after that select the router.
Frequently asked questions
How can I tell if my LTE connection is behind CGNAT?
100.64.0.0/10 shared address block is a strong indicator. A different WAN and
public address also shows upstream translation. Confirm the service arrangement with the
mobile operator before making the final diagnosis.
Can port forwarding work through cellular CGNAT?
When is an outbound VPN the safer recovery path?
Send the network requirement before asking for a router recommendation
“We need remote access over 4G” is not enough information to select a model. Provide the details that determine whether the project needs direct public reachability, a private APN, an outbound VPN or cellular redundancy.
With those requirements defined, E-Lins can confirm whether a compact H685t-class gateway, an H820t VPN-oriented deployment, a dual-SIM H720 direction or another industrial 4G router is the better fit for the actual network architecture.
