Back to BlogStop False Alarms: Site to Site VPN Monitoring for Operators with SNMP

Stop False Alarms: Site to Site VPN Monitoring for Operators with SNMP

NTNetverge TeamNetverge editorial teamPublished
site VPN health checksite-to-site vpn monitoringsite-to-site VPN analyticsVPN performance monitoringmonitoring VPN connectivity

Good site-to-site VPN monitoring gives you real-time tunnel state plus IPsec metrics such as SA and proxy ID counts, latency, and security anomalies, not just heartbeat pings. Reliable programs pull this data from device-native checks, SNMP OIDs, and failure-history correlation, then feed it into alerting that separates real outages from scheduled rekeys. We built our platform around this exact model, and this guide walks through how to implement it.

TL;DR:

  • Validate SNMP OIDs with snmpwalk after each firmware upgrade, and use device GUI or CLI counters for root cause when centralized dashboards disagree.
  • Poll tunnel status every one to five minutes, reserve traps for detection under a minute, and track SA and proxy ID counts for partial negotiation failures.
  • Use five minute charts for active troubleshooting, one hour views for shift handoffs, and 24 hour rollups for trends; failure history distinguishes rekeys from faults.
  • Page immediately for tunnel outages and repeated IKE authentication failures; trigger lower severity alerts for rising latency, packet loss, or clustered rekeys.
  • Automate known tunnel down recovery and routine rekey suppression only after failure history is reliable; keep human review for unexplained SA spikes or authentication failures.

Table of Contents

1. Where to find trustworthy tunnel state

Device GUI status pages are the first and most reliable check for tunnel health. They report whether a tunnel is active, inactive, or showing no recent traffic, and they reflect the device's own internal state tables rather than a third-party interpretation of it.

CLI access gives you the same data with more granularity:

  • Phase 1 (IKE) status commands show peer negotiation state and security association details.
  • Phase 2 (IPsec SA) commands list active security associations, proxy IDs, and traffic counters.
  • These CLI fields map directly to what the GUI displays, so discrepancies usually point to a caching or refresh issue, not a real fault.

Centralized vendor dashboards, such as FortiManager's VPN monitor pages, aggregate tunnel state across many devices and let you bring tunnels up or down from one pane. Trust device-level counters for root-cause work and aggregated platform metrics for fleet-wide trend spotting. When the two disagree, the device is almost always right.

2. SNMP, MIBs and OIDs to poll for IPsec health

SNMP polling turns tunnel state into something you can graph, alert on, and store for trend analysis. On FortiGate devices, a handful of OIDs cover most operational needs, and the same pattern (status, counts, proxy entries) repeats across vendors with different naming.

OID What it reports CLI equivalent
fgVpnTunEntStatus Per-tunnel up/down state as an integer code Phase 1/2 status output
fgVpnTunnelUpCount Total number of tunnels currently up Tunnel list summary
fgVpnTunnelSaCount Active IPsec security association count Phase 2 SA listing
fgVpnTunnelProxyidCount Number of proxy ID entries negotiated Phase 2 proxy ID detail

These OIDs are documented in FortiGate's SNMP monitoring example and in community technical notes on IPsec tunnel status OIDs, both of which show how to validate results against snmpwalk output. Poll tunnel status every one to five minutes for alerting purposes, and reserve traps for events where sub-minute detection genuinely matters, since trap-heavy designs tend to flood receivers during larger outages.

Pro Tip: Run snmpwalk against a lab device after every firmware upgrade. OID names and availability shift between versions, and a silently broken poll looks identical to a healthy, quiet tunnel.

3. Key metrics and dashboards for tunnel health and security

A dashboard that only shows up or down status misses most of what matters operationally. Build views around both availability and the metrics that reveal degradation before it becomes an outage.

  • Tunnel counts: total configured tunnels versus active tunnels, so a quiet drop in active count surfaces immediately.
  • IPsec detail: SA count and proxy ID count per tunnel, which expose partial negotiation failures that a simple up/down flag hides.
  • Performance: latency, packet loss, and throughput per tunnel, ideally tested the way a bandwidth test methodology measures jitter and bufferbloat alongside raw speed.
  • Lifecycle events: rekey frequency and failure events, tracked against a failure-history table rather than treated as isolated alerts.
  • Security anomalies: sudden SA spikes, repeated rekey failures in short windows, authentication errors, and unplanned configuration changes.

Layer the views by time window: a five-minute chart for active troubleshooting, a one-hour view for shift handoff, and a 24-hour rollup for trend review. Failure history is what lets you tell a scheduled rekey from a real negotiation problem; without it, every rekey looks like an incident.

4. Alerting strategy that cuts false positives

Alerts earn their place only when they change what someone does next. Start with a small set of high-confidence triggers and expand carefully.

  1. Tunnel down: fire immediately, high severity, since this usually means a site has lost its link entirely.
  2. SA count drop: fire at medium to high severity when SA count falls below the expected baseline for a tunnel.
  3. Authentication failures: fire immediately on repeated IKE auth failures, since this can indicate a credential or certificate problem, or an attempted intrusion.
  4. Anomaly trends: fire at lower severity for SA spikes, rekey clustering within a short window, or rising latency and packet loss trends over an hour.

Tune these rules with maintenance-window suppression, rate limiting on flapping tunnels, and grouped notifications for correlated failures at one site. Cross-reference rekey alerts against your failure-history table before paging anyone.

Pro Tip: Route tunnel-down and SA-drop alerts straight into an automated runbook trigger; reserve human paging for anomalies that lack enough history to auto-triage.

VPN alerts routed to runbooks or human paging

5. Troubleshooting checklist for common tunnel failures

Work through triage in a fixed order so nothing gets skipped under pressure.

  1. Confirm basics: verify peer IP reachability, check tunnel and SA state on both ends, and confirm clock sync, since IKE negotiation is sensitive to time drift.
  2. Check recent rekey activity: compare the failure-history table against the current outage window to rule out a scheduled renegotiation.
  3. Validate routing and ACLs: confirm static or dynamic routes point to the tunnel interface and that firewall rules permit the negotiated traffic.
  4. Collect IKE logs: pull negotiation logs from both peers, since a one-sided log rarely shows the full mismatch.
  5. Run packet captures: capture on UDP 500/4500 and ESP traffic at both ends to isolate where negotiation breaks down.
  6. Inspect proposals: compare phase 1 and phase 2 proposals for mismatched encryption, hashing, or Diffie-Hellman group settings.
  7. Escalate when needed: open a vendor case for suspected bugs or unpatched CVEs, repeated rekey failures with no config change, or asymmetric routing that needs deeper path analysis.

For the ticket itself, attach CLI output from both peers, exact timestamps for the failure window, and the relevant SNMP graph covering the hour before and after the event.

6. Security and lifecycle practices that keep tunnels visible

Monitoring only works if the underlying gateway stays both visible and current. CISA and NSA guidance on enhanced visibility and hardening identifies visibility, not encryption strength, as the most common gap in VPN security, and recommends continuous logging and analytics to catch indicators of compromise early.

  • Enable local and centralized logging for authentication attempts, negotiation metadata, and configuration changes, and run ongoing analytics against that log stream.
  • Subscribe to vendor security advisories and treat VPN gateway patches as high priority rather than batching them into routine maintenance cycles.
  • Review cryptographic suites against NIST SP 800-77's IPsec guidance periodically, and remove legacy ciphers left over from vendor defaults.
  • Limit accepted peer IPs, place IPS in front of gateways, and filter IKE and ESP ports strictly rather than leaving them open to any source.

Continuous log analytics, not stronger encryption alone, is what closes the visibility gap CISA and NSA flag as the biggest VPN security risk.

7. How unified monitoring and AI automation apply this model

Netverge pulls SNMP polling, CLI outputs, and gateway logs into one telemetry stream, so tunnel state, SA counts, and log anomalies sit in the same view instead of three separate tools. Vergepoint hardware adds on-site visibility at sites where a remote poll alone cannot confirm physical connectivity, and AI agents triage alerts against failure history before they ever reach a technician.

  • Fewer site visits, since Vergepoints confirm local link and power conditions remotely.
  • Faster mean time to resolution, because triage starts with correlated data instead of a single alert.
  • Less alert noise, since failure-history correlation filters routine rekeys from genuine faults automatically.

Our remote site monitoring pilots and SD-WAN monitoring practices follow the same consolidation approach applied here to site-to-site VPN tunnels.

8. Weighing automation against human oversight

Automate detection and basic remediation first: tunnel-down recovery, known flapping conditions, and routine rekey suppression are safe to hand off once failure history is reliable. Hold off automating responses to anomalies that lack enough history, since those often signal a broader security event that a script will mask rather than fix. My recommendation: let automation handle the predictable, and keep a person in the loop for anything SA spikes or auth failures flag as unusual.

— Jim

9. Getting started with Netverge

If you want this monitoring model running without building every SNMP poll and alert rule by hand, a starter package is available that gives tunnel state, IPsec metrics, and failure-history alerting out of the box.

Netverge

  • The Starter Package runs 299 USD per month and covers the core monitoring checklist described above, detailed on our pricing page.
  • Hardware devices add on-site visibility for sites where remote polling alone leaves gaps; pricing details are on the pricing page.
  • A free trial walks through setup against your own tunnels before you commit to a plan.

FAQ

Is site-to-site VPN secure?

Site-to-site VPNs built on IPsec are secure when configured according to current cryptographic guidance and kept patched, as outlined in NIST's IPsec guide. Security depends heavily on configuration choices like cipher suites and peer restrictions, not on the protocol alone.

What are the downsides of using a site-to-site VPN?

Site-to-site VPNs add operational overhead: someone has to monitor tunnel state, manage rekeys, and troubleshoot negotiation failures across multiple sites. Performance can also degrade under load, which is why tracking latency and packet loss alongside tunnel status matters.

Can the FBI see through VPNs?

This depends on legal authority, the specific VPN configuration, and jurisdiction, and it falls outside what this guide covers technically. For the operational question of whether your tunnels are configured securely, CISA and NSA visibility guidance is the relevant reference.

Can I use IPSec for a site-to-site VPN?

Yes, IPsec is the standard protocol suite for site-to-site VPNs and is the subject of NIST SP 800-77's dedicated guidance. It handles key management through IKE and supports tunnel mode for site-to-site connections specifically.

Sources

Recommended