Why Does Ignition Stop Updating After VPN Recovery?

After the client-side Matrikon Tunneller is restarted, Ignition can rebuild its OPC subscription and resume tag updates without rebooting the host. Treat this as a session-recovery fault: first prove that the VPN and OPC server have recovered, then reset the stale tunnel session, control the 2,000-tag subscription load, and verify that values continue changing at the application layer.

Fault-boundary confirmation

Before anything else, confirm which layer remains failed after the VPN reconnects. An OPC explorer displaying live values proves that the repaired network path can reach the OPC data source, but it does not prove that Ignition's existing subscription or the client tunneller session has recovered. Each client can hold its own connection and subscription state.

1. Record several tags whose process values are actively changing. Static values cannot prove that updates are flowing.
2. Interrupt the VPN and confirm that both the explorer and Ignition stop receiving changes.
3. Restore the VPN without restarting the OPC server, Ignition, or the computer.
4. Read the selected tags through the OPC explorer. Confirm that their values and timestamps advance.
5. Check the same tags in Ignition. Record whether values remain stale, become uncertain, or report a communication error.

Do not move on until the explorer shows changing values while Ignition still fails on the same tag set. That comparison isolates the problem from the restored VPN path.

Client tunnel-session restoration

The demonstrated recovery is to restart the client-side Matrikon Tunneller component. This action removes the stale client session and forces the communication chain to create a new tunnel connection. Ignition can then establish fresh OPC subscriptions through that connection.

1. Stop new commissioning changes so that subscription edits do not obscure the recovery test.
2. Record Ignition's displayed quality, value, and timestamp for the selected tags.
3. Restart only the Matrikon Tunneller component on the client side. Do not reboot unrelated equipment.
4. Wait for the tunnel connection to return, then check the same tags in Ignition.
5. Confirm that values and timestamps advance, not merely that a connection indicator reports healthy.

A VPN restoration repairs network reachability, but a long-lived application session may still reference a failed transport connection. If the tunneller does not discard that session or notify its downstream client correctly, Ignition can retain a subscription that no longer receives callbacks. A component restart clears that state. Do not move on until a targeted client-tunneller restart restores live values.

VPN-path and latency checks

Latency of 200 ms or more can lengthen connection establishment, request completion, and subscription creation. Latency alone does not prove the root cause; packet loss, route changes, stateful firewall expiration, and asymmetric connectivity can produce the same symptom after a VPN outage.

1. Measure round-trip latency before the outage, during recovery, and after the VPN stabilizes. Record variation as well as the typical value.
2. Check whether the tunnel endpoint is continuously reachable after reconnection. A successful isolated test does not prove that a persistent session survives.
3. Review Matrikon Tunneller and Ignition diagnostics for disconnect, reconnect, timeout, session, and subscription messages at the outage and recovery times.
4. Compare the timestamps: VPN restored, explorer resumed, tunneller restarted, and Ignition resumed. The ordering distinguishes automatic network recovery from application-session recovery.
5. Read configured connection and request timeouts from the installed product configuration or documentation. Compare them with the measured delay; do not substitute an assumed timeout.

If Ignition remains stale after the network has stabilized, while restarting the client tunneller immediately restores updates, the remaining fault is above basic IP reachability. Do not move on until the time-correlated logs show whether the client attempted a new session or retained the old one.

Controlled subscription commissioning

Creating subscriptions for 2000 tags across a high-latency path can expose timeout and recovery weaknesses. The relevant load is not only the tag count: update rate, value changes, deadband, grouping, server capacity, and tunnel behavior determine how much work occurs during reconnection. Changing every tag's Scan Class simultaneously can also create a concentrated resubscription burst.

1. Create or enable a small test group containing actively changing tags.
2. Restore the VPN and confirm that this group resumes without restarting the client tunneller.
3. Add tags in controlled batches while keeping the same requested update behavior. Record the point at which recovery becomes slow or fails.
4. If the small group recovers but the full 2000-tag set does not, examine subscription creation duration and timeout messages.
5. Group tags by required update rate. Keep fast acquisition only where the process requirement demands it; assign slower behavior to data that changes less often.
6. Repeat the VPN interruption after each material Scan Class change.

Do not change tag count, scan behavior, and timeout settings in the same test. A single-variable sequence reveals whether failure follows session recovery or subscription load. Do not move on until one repeatable tag grouping either recovers automatically or reproduces the failure.

Automatic-recovery configuration

Avoiding manual intervention requires one layer to own reconnection and stale-session disposal. Inspect the installed Matrikon Tunneller and Ignition configuration for connection retry, failed-session cleanup, subscription recreation, and communication watchdog behavior. Use only settings exposed by the installed versions; parameter names and ranges vary.

1. Determine whether the client tunneller detects a broken transport session after VPN loss.
2. Determine whether it opens a new session after reachability returns or continues holding the failed one.
3. Check whether Ignition reports its OPC connection as connected while tag timestamps remain frozen. That mismatch is a useful watchdog condition.
4. Set documented retry and timeout values using measured VPN recovery time and observed latency. Keep the relationship explicit: the timeout must accommodate normal response time but still declare a genuinely failed session.
5. If the products expose no reliable automatic reset for this failure mode, use a supervised service-recovery procedure through the site's approved control mechanism. Trigger it from sustained loss of live tag updates, not from one delayed sample.

Do not treat an OPC explorer's successful read as a reset command for Ignition's separate session. Do not move on until the client path can detect a failed session and either recreate it automatically or raise an actionable alarm for controlled recovery.

End-to-end recovery verification

Test the complete sequence under the operating tag load. A one-time display update is insufficient; the acceptance check must prove continuing subscription delivery.

1. Select changing tags from each commissioned subscription or Scan Class.
2. Record their values, quality indications, and timestamps in Ignition.
3. Break the VPN long enough for the communication path to register the loss.
4. Restore the VPN and wait for the configured recovery sequence to finish.
5. Confirm basic access with the OPC explorer, then verify independently that Ignition values and timestamps advance.
6. Repeat the interruption with the complete 2000-tag load and the measured network latency.
7. Review diagnostics for repeated reconnect loops, timeouts, or incomplete subscription creation.
8. Perform the final verification without restarting the client tunneller: confirm that all selected Ignition tags continue changing through at least one complete outage-and-recovery cycle.

Frequently asked questions