Why a 5G Industrial Router Looks Broken When Only the VPN Is Down
A 5G industrial router that has dropped its VPN tunnel still shows healthy signal bars, an active cellular session and a working local LAN. Operators therefore often report it as "router failed", while the hardware is doing exactly what it was configured to do. Before anyone swaps a unit, it pays to separate four very different failure classes, because each one leaves a different fingerprint in the logs:
- The tunnel never comes up — IKE negotiation refuses to complete.
- The tunnel is up but traffic does not flow — routing, selectors or firewall policy.
- Small packets pass, large packets die — MTU and MSS behaviour on an encapsulated path.
- The tunnel works, then drops on a schedule or after a WAN change — DPD, rekey timers or a new carrier-assigned address.
Classify the symptom first, and most of the remaining checklist eliminates itself. This guide follows the safe-check pattern used across the site: read-only evidence gathering first, configuration changes second, hardware replacement never before logs agree with the diagnosis.
Symptom 1: The Tunnel Never Establishes
If the router reports "connecting" indefinitely or cycles through phase 1 attempts, the fault is in negotiation, not in the radio link. Vendor documentation from Check Point and Google Cloud both point at the same short list of mismatches, and every item can be read out of the configuration rather than guessed at.
Checks, in the order that usually finds the answer fastest:
- IKE version and mode. Both peers must run the same IKE version; if legacy IKEv1 is in use, main mode versus aggressive mode must also match.
- Pre-shared key. A single wrong character is enough. Compare against a stored reference, not against what somebody remembers typing.
- Peer identity. Remote gateway address, Remote ID and Local ID must match what the other side expects; a stale public address after a carrier change is a classic cause.
- Phase 1 parameters. Encryption, integrity, DH group, authentication method and lifetime.
- Phase 2 parameters. Encryption, integrity, PFS/DH group, lifetime and the traffic selectors (local and remote subnets).
Log strings are your best evidence at this stage. A no-proposal-chosen entry means no common cipher suite was found; with IKEv1 that requires an exact match, with IKEv2 each side must offer at least one suite the other also offers. A repeated SA_DELETE immediately followed by a new negotiation points at a peer that is not refreshing keys as expected rather than at a cipher problem.
Selector traps. Where the platform requires explicit traffic selectors, do not substitute 0.0.0.0/0 for the real subnets. Also confirm the two ends do not use overlapping address ranges, and that any NAT rule in front of the tunnel does not rewrite the addresses that the selectors describe.
Symptom 2: Tunnel Established but No Traffic Passes
An "up" IPsec state only proves the control plane agreed. Data-plane faults are usually one of these:
- Missing return route. Traffic arrives through the tunnel and leaves through the cellular default route, so replies never come back. Check the routing table for both directions, including any policy-based routing that sends specific subnets out of a WAN interface.
- Local firewall on the router. Many industrial routers ship with a default deny on the tunnel zone. The rule must permit the specific subnets and services, in both directions, on the tunnel interface — not just on the LAN side.
- Overlapping subnets. Two sites both using a common consumer range such as 192.168.1.0/24 will "connect" and then fail to reach anything meaningful.
- Asymmetric inspection. If one side sends traffic through a stateful firewall and the other does not, sessions may establish and then stall.
Test from the router itself (ping and a TCP probe sourced from the tunnel interface), then from a host behind the router, then from the far side. Whichever step first fails localises the fault without touching a single policy entry.
Symptom 3: Ping Works but File Transfers, RDP or Web Apps Stall
This is the signature of a maximum transmission unit problem on an encapsulated path. Small packets fit; large ones need fragmentation, and if the ICMP "fragmentation needed" message never arrives — because a firewall on the path drops ICMP — the sender keeps retrying full-size segments until the session times out.
Safe checks:
- Run a ping with the "do not fragment" flag from both ends and step the payload size down until replies return consistently; note the largest stable value in each direction.
- Apply TCP MSS clamping on the VPN egress so TCP peers advertise a segment size the tunnel can actually carry. A widely quoted approximation is MTU minus 40 bytes for IPv4 without options and MTU minus 60 for IPv6, but IPsec, GRE, VLAN, PPPoE and other encapsulation overhead must still be subtracted on top.
- Verify the ICMP type 3 code 4 messages are not filtered anywhere on the path, because blocking them hides the problem.
Be careful with published numbers. Platform-specific guidance exists — IBM Cloud, for example, recommends an MSS of 1360 bytes for internal devices in its own VPN environment — but that figure is calculated for that platform's encapsulation and must not be pasted into an unrelated industrial deployment. Measure, then set.
Also remember that MSS only affects TCP. If UDP-based services or the IKE exchange itself misbehave, MSS clamping will not fix them.
Symptom 4: The Tunnel Drops Periodically or After a WAN Event
Intermittent drops that recur at a similar interval are almost always timer-related, while drops that follow a re-registration of the cellular link are address-related.
- Dead peer detection. If DPD is too aggressive for the latency of a cellular path, a briefly delayed probe tears down a healthy tunnel. Azure's VPN Gateway documentation, for reference, lists a default DPD timeout of 45 seconds and discusses 30–45 second ranges; that is Azure's guidance for its own gateway and is not a universal IPsec default, so compare against your own device and peer documentation.
- Rekey and lifetime. Compare IKE SA and child SA lifetimes on both ends. If drops land on a predictable multiple of the lifetime, suspect an IKEv1 renegotiation that briefly interrupts traffic; Microsoft notes such reconnects can take up to about 5 seconds and suggests evaluating IKEv2 where that interruption is unacceptable.
- Carrier-grade NAT and dynamic addresses. A cellular WAN may sit behind CGNAT or receive a new public address after a reconnect. Confirm the router can use NAT-T and that the peer accepts the identity it presents; if the peer is pinned to a fixed address that no longer belongs to you, the tunnel will fail every time the link re-registers.
- UDP 500 and 4500. Both must be permitted bidirectionally for IKE and NAT-T. Where one-to-one NAT sits in front of the gateway, the NAT device must forward those ports to it. If the deployment runs native ESP instead of NAT-T, protocol 50 must not be blocked.
Cross-reference the drop timestamps against carrier registration events in the router log. A tunnel that dies within a few seconds of every re-registration is an identity or NAT-traversal problem, not a firewall bug.
What to Record While You Investigate
Every one of the classes above is decided by evidence, so capture it before changing configuration — otherwise the next shift starts from zero.
- Timestamp, symptom as the operator experienced it, and which class it falls into.
- Firmware version, VPN profile name and a screenshot or export of the phase 1 and phase 2 settings (redact secrets).
- Cellular WAN address at the time of failure, plus whether it changed since the last working session.
- IKE/IPsec log extract covering the failure window, from both peers, not just the router.
- Any configuration change made, with a rollback note.
- Measured path MTU in each direction and the MSS value in force.
A single change per test, recorded with a timestamp, is the difference between a two-hour diagnosis and a two-week guessing exercise.
When to Stop and Escalate
Stop local troubleshooting and escalate to the carrier, the VPN platform owner or the hardware vendor when any of the following is true:
- The IKE negotiation fails with an authentication or identity error that persists after both ends have verified their configuration independently.
- UDP 500/4500 traffic is confirmed dropped by an upstream operator network or a third-party firewall you do not control.
- The cellular link itself loses registration repeatedly, or the router cannot obtain a usable WAN address at all.
- Measured path MTU is too small to carry the required application traffic and no clamping point exists in the path.
- The device reboots, loses its configuration or reports hardware or radio faults alongside the VPN failure.
Escalate with the log bundle and the measured values, not with "the VPN is down". Those two artefacts are what turn a support ticket into a fix.
Preventing the Same Failure Next Time
Most repeat incidents on cellular-connected industrial routers come from untracked change: a firmware update that resets a cipher suite, a carrier reassigning an address, an MSS value that was tuned once for a different link. Keep an exported configuration baseline per site, document the peer expectations (identity, selectors, lifetimes), monitor tunnel state and WAN address changes as separate alarms, and re-measure path MTU after any firmware or carrier change. Hardware replacement should be the last step, not the first response to a red tunnel indicator.