Why Is It Difficult to Achieve VPN/SD-WAN Visibility and Real-Time Outage Detection in Distributed Networks?
When VPN/SD-WAN connections between the factory, office, and field facilities drop, production stops within minutes, and business processes are paralyzed. The problem is not knowing whether there is an outage, but detecting it before it even happens.
Modern industrial enterprises no longer live under a single roof. The factory floor at the production location, the headquarters office in the city center, the warehouse at the logistics hub, and the new facility as part of the growth strategy — the digital backbone between these structures is built over VPN tunnels or SD-WAN overlays. It doesn't matter if the physical buildings are hundreds of kilometers apart; the sustainability of the operation depends on the uninterrupted nature of these virtual connections.
When a VPN tunnel or SD-WAN underlay connection is interrupted, the impact is instantaneous and multi-layered: access to ERP systems is cut off, SCADA/OT data flow stops, IP cameras and access control systems go blind, cloud-based production management platforms cannot receive location data. Much worse, this interruption can be silent — the business loss has already occurred before users call the support line complaining of "slowness".
What is SD-WAN? Why SD-WAN Monitoring MattersThe Observability Gap in Multi-Location WAN Structures
Network topologies connecting multiple physical locations carry exponentially higher operational complexity compared to single-centralized-site scenarios.
Connection status ≠ service status. The Phase 2 SA of an IPsec tunnel might appear active; it might even respond to a ping — but real application traffic might not be passing through. MTU mismatches, asymmetric routing issues, or high jitter values can render the tunnel effectively unusable while showing it as "up".
Unobservable connection degradations (silent degradation) are the most serious problem in industrial VPN/SD-WAN operations. Before the line drops completely, there are periods of gradual degradation lasting for hours — the packet loss rate climbs from 0.1% to 8%, RTT values start spiking, and jitter reduces bandwidth usability. Traditional SNMP polling mechanisms work both too slowly and too coarsely to catch this degradation.
The second major problem is the scalable observability burden of multi-location topologies. Each location means separate CPE (Customer Premises Equipment) devices, multiple ISP uplinks, IPsec or GRE tunnels, and an SD-WAN underlay/overlay layer. Monitoring this structure 24/7 requires both having the right tools and the operational capacity to interpret the data produced by these tools.
The most dangerous scenario: The primary line drops, VPN/SD-WAN policies route traffic to the backup line — but the backup line is also silently degraded. While the team thinks "failover worked," in reality, the entire location is operating almost without access. To detect this situation, it is imperative to actively test the backup lines as well.
Three-Pillar Active Monitoring
The architectural response to these operational realities dictates a transition from reactive alarm systems to proactive, active signal-based monitoring. The ODYA Automated NOC approach builds this transition on three mutually integrated monitoring layers:
-
01
Continuous Signaling (Active Probing) The NOC infrastructure periodically sends synthetic packets to the VPN/SD-WAN edge device and critical segment boundaries in every monitored location. Not just simple ICMP echo — TCP handshake completion, HTTP/HTTPS application layer response validation, and bidirectional round-trip time measurements via probe point pairs are performed. In this way, going beyond the question of "is the tunnel up?", the question "is application traffic really passing?" is answered. When probe intervals are kept at the scale of seconds, the correlation engine is triggered the moment the packet loss rate of any path exceeds the threshold or a deviation from the RTT baseline begins.
ICMP Echo TCP SYN Probe HTTP Synthetic Check Bidirectional RTT -
02
Traffic and Performance Analysis Connection status information alone is insufficient. The fact that an IPsec tunnel is active does not mean it can actually handle the workload. In this layer, NetFlow/sFlow/IPFIX telemetry is collected to analyze the actual traffic flow over the line: bandwidth utilization rate, number of active flows, QoS queue depth, and jitter values are monitored. Dynamic baselines are created for each location pair. BGP route advertisement changes, VPN/SD-WAN path selection decisions, and overlay tunnel renegotiation events are also among the inputs of this layer.
NetFlow / IPFIX Jitter Baseline QoS Queue Depth BGP Monitoring -
03
Backup Line Control A multi-ISP uplink structure or the built-in failover mechanism of VPN/SD-WAN is designed as the primary defense layer against outages. However, to verify whether this defense actually works, backup lines must also be continuously and independently monitored. This layer measures the actual availability and capacity of inactive secondary uplinks by sending them periodic signals. The failover decision can thus be made reliably, without delay, and based on observation.
Secondary Uplink Probing Failover Readiness Pre-failure Alerting
Why is Continuous Monitoring Inevitable?
Network outages do not respect working hours. There is a more critical reality in the industrial context: the vast majority of the most devastating connectivity issues to the OT infrastructure are noticed during the night shift or over the weekend — exactly the time frames when human intervention kicks in the latest.
"An undetected backup line failure can take the entire location offline when the primary line also fails within weeks. Just because the system appears to be 'working' doesn't mean it's running healthy."
The human-dependent NOC approach comes with structural limitations such as alert fatigue and information refresh delays. Automation steps in not to eliminate these limitations — but to focus the human operator's attention on the events that truly matter. The raw data produced by the three-layer monitoring engine is processed with correlation rules and machine learning-backed anomaly detection to generate highly reliable, actionable alerts; noise is systematically suppressed.
What Happens in an Outage Scenario?
Let's consider a concrete operational scenario: The VPN/SD-WAN edge device at the factory site of a three-location manufacturing enterprise is experiencing a gradual bandwidth drop on its primary MPLS uplink.
-
T+0
Time: T+0 Active probe data reports that the RTT value has exceeded the 6-hour baseline average by 40%. The traffic analysis layer simultaneously detects a rise in the TCP retransmission rate in IPFIX telemetry.
-
T+3
Time: T+3 Minutes The correlation engine merges data from two independent signal sources. Even if a single indicator hasn't crossed the alarm threshold, the correlation score reaches a critical level. The backup line control layer confirms that the secondary uplink's probe results are within normal limits — failover is ready.
-
T+5
Time: T+5 Minutes Automated actions trigger: The VPN/SD-WAN policy prioritizes the backup line, a ticket is opened in the relevant ITSM system, and the on-call network engineer is notified. Users experience no downtime.
The critical difference in this scenario is this: no one raised an alarm — the system detected it and intervened on its own.
Conclusion
Multi-location VPN/SD-WAN monitoring is an operational area where the "we'll see if something happens" approach is no longer sufficient. The reality that VPN/SD-WAN connections can degrade in unpredictable ways makes proactive and active monitoring mandatory.
The integrated operation of continuous signaling, traffic performance analysis, and backup line verification — bringing these three layers together around a correlation engine that provides 24/7 uninterrupted operation — fundamentally raises the bar for reliability in multi-location network operations.
Evaluate Your Multi-Location Network with ODYA Automated NOC
You can request a discovery call to see how the three-pillar monitoring approach can integrate into your existing WAN infrastructure.
Contact Us →