>
    Strata Copilot
    Network Security Agent: Troubleshoot Remote Network and Service Connection IPSec and VPN Issues
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma Access
    3. Prisma Access Administration
    4. Prisma Access Advanced Deployments
    5. Network Security Agent: Troubleshoot Remote Network and Service Connection IPSec and VPN Issues
    Download PDF
    Prisma Access

    Network Security Agent: Troubleshoot Remote Network and Service Connection IPSec and VPN Issues

    Table of Contents

    Network Security Agent: Troubleshoot Remote Network and Service Connection IPSec and VPN Issues

    Use troubleshooting tools in Strata Cloud Manager to automatically diagnose and resolve remote network site, BGP, ECMP tunnel, and service connection failures.
    Where Can I Use This?What Do I Need?
    • Prisma Access (Managed by Strata Cloud Manager)
    • Strata Cloud Manager
    • Strata Cloud Manager Pro
    • This feature is currently in Beta and available on request. Contact your account team to enable the feature.
    • Superuser role (for agent administration, onboarding, and managing permissions)
    • Network Administrator or Security Administrator role (for agent interaction)
    The IPSec troubleshooting agent in Strata Cloud Manager™ is one of the Network Security Agents included with Strata Copilot™ and automates diagnostics for Prisma® Access remote network and service connection issues. The agent supports manual troubleshooting through Strata CoPilot and automated investigations through supported AIOps incident codes for issues such as a remote site outage, ECMP tunnel degradation, BGP neighbor drops, and private app unreachability. After the agent finds the outage, it performs end-to-end root cause analysis across the IPSec tunnel stack, covering IKE negotiation, BGP routing, bandwidth and QoS, security policy enforcement, and service connection health. You can also invoke the agent manually using natural language queries in Strata Copilot for specific troubleshooting scenarios. In both cases, the agent delivers a findings report with a root cause determination and specific remediation recommendations for your review.
    This feature leverages a large language model or generative AI, and may contain errors. Double-check for accuracy before applying changes.
    The agent executes through a four-phase analysis loop:
    • Context gathering — The agent identifies the resources involved: site names, tunnel identifiers, tunnel IP addresses, BGP configuration, peer details, cloud instance IDs, and the exact time the issue occurred based on the local time zone. When resource information is missing from the triggering input, the agent checks recent incidents within a three-hour window to fill gaps.
    • Evidence gathering and correlation — The agent queries operational logs, executes read-only CLI commands against the dataplane, and queries telemetry tables — including BGP summary data and traceroute results — to build a statistical evidence bundle. Data sources include IKE event logs, IPSec tunnel status, BGP neighbor state, route tables, bandwidth utilization metrics, security policy traffic logs, and service connection telemetry.
    • Root cause determination — Using the complete evidence bundle, the agent runs deep-dive correlations, analyzes recent configuration changes and node health, and executes targeted diagnostic tools to pinpoint the root cause. It distinguishes between control plane failures (IKE negotiation, BGP peering) and dataplane failures (traffic drops after tunnel establishment) to prevent misdiagnosis.
    • Remediation generation — The agent generates localized configuration recommendations or operational recovery steps based on the isolated root cause and its knowledge base. Remediation output is presented for your review in Action Center — the agent does not automatically execute any changes.
    The agent activates automatically for the following AIOps incident codes and routes to the appropriate sub-agents based on the symptom:
    AIOps Incident CodeWhat the Agent Checks
    INC_RN_SITE_DOWN
    Remote network site completely unreachable
    		IKE Phase 1 and Phase 2 negotiation state, proposal mismatches, pre-shared key (PSK) and certificate authentication failures, proxy-ID mismatches, Network Address Translation Traversal (NAT-T) detection, dead peer detection (DPD) and tunnel-monitor probe status, and CPE vendor interoperability. Infrastructure health (Security Processing Node (SPN) and compute node capacity, regional incidents) is also checked.
    INC_RN_PRIMARY_WAN_TUNNEL_DOWN
    Primary WAN tunnel down
    		Tunnel establishment state, IKE negotiation traces, crypto profile comparison between CPE and Prisma Access, security association (SA) rekey failures, and failover between primary and secondary tunnels.
    INC_RN_ECMP_TUNNEL_DOWN
    One of the ECMP tunnels went down
    		ECMP tunnel state for all redundant paths, traffic distribution across remaining tunnels, DPD probe results for the affected tunnel, and impact on overall bandwidth and session distribution.
    INC_RN_PRIMARY_WAN_BGP_DOWN
    Primary WAN BGP neighbor down
    		BGP neighbor state machine (Idle through Established), hold and keepalive timer mismatches, MD5 authentication failures, route advertisement and receipt validation, prefix filtering and AS-path policy mismatches, and route conflicts across remote network sites.
    Manual NLQ — Private app unreachable via Prisma Access
    User-initiated query for specific app reachability scenarios
    		Correlates network troubleshooting (routing, tunnel state) and security policy evaluation to isolate whether the issue is in the network path or policy enforcement.
    There are two troubleshooting methods: Reactive and Proactive troubleshooting.
    1. Reactive troubleshooting: Investigate a tunnel outage you observe in Remote Networks.
    2. Select ConfigurationNGFW and Prisma AccessConfiguration ScopePrisma AccessRemote Networks and identify the remote network site that is showing a tunnel error.
      The STATUS column shows the tunnel state for each site. Sites with an Error indicator in the Tunnel column have a tunnel failure that the agent can diagnose.
    3. Open Strata Copilot from the left navigation and enter a query that identifies the affected remote network and describes the error.
      Prefix your query with @Troubleshooting to direct the query to the Troubleshooting agent. For example: "@Troubleshooting The remote network RN_East is showing an Error for the Tunnel. Investigate the cause of the issue and provide any remediation."
    4. When the Activity Plan appears, click Provide Input.
      The agent fetches data and presents an Activity Plan. You must supply additional details before the agent can proceed.
    5. In the Execution details form, enter the exact error message and the time the error was first observed, then submit the form.
      The Exact error message field accepts the error code or status text you saw in the Remote Networks list (for example, Error). The Error start time defaults to a 24-hour window; adjust the range if the error started at a known time.
    6. Review the activity plan that the agent generates, then click Execute to run the investigation.
      After you submit the form, the agent generates a named investigation plan (for example, Investigate RN_East Tunnel Error) and begins executing the diagnostic steps. The status changes to Agent flow in progress.
    7. Review the detailed activity plan and click Execute to confirm, or Modify to adjust the scope before running.
      The agent presents a numbered investigation plan with specific diagnostic tasks — for example, verifying underlay reachability and peer IP responsiveness, gathering telemetry and site status history across the specified time window, collecting tunnel state transitions with timestamps, and compiling BGP session status and underlay performance metrics such as latency, packet loss, and jitter. When analysis is complete, the findings and remediation recommendations appear in Action Center for your review.
    8. Proactive troubleshooting: Review and activate pre-built investigation plans
    9. Open Strata Copilot from the left navigation and select Proactive Plans.
      The Proactive Plans list shows all available investigation plans. Each plan displays its trigger type (incident, event, or scheduled), priority, owner, and current activation status. Plans provided by Palo Alto Networks carry a PANW badge and are set to Inactive by default — you activate the plans that apply to your environment.
    10. Locate the plan you want to enable, toggle it to Active, then click View.
      For example, the Tunnel down analysis plan triggers automatically when Prisma Access raises an INC_RN_PRIMARY_WAN_TUNNEL_DOWN incident. Activating a plan means the agent runs its defined investigation steps automatically the next time that incident code fires — you don't need to start the investigation manually.
    11. Review the plan details — including the trigger, visibility roles, and investigation instructions — and confirm the scope is correct for your environment.
      The plan detail page shows the Plan Name, Description, and the Trigger(s) that activate it — for example, INC_RN_PRIMARY_WAN_TUNNEL_DOWN. The Plan Instructions panel on the right lists the investigation steps the agent follows when triggered, such as detecting and scoping the outage, establishing a timeline, auditing configuration changes, verifying IKE/IPSec configuration against the as-designed state, and probing firewall logs for error signatures such as NO_PROPOSAL_CHOSEN. If the investigation identifies a misconfiguration, the agent presents recommended remediation steps in Action Center for review. Configuration changes must be applied separately by the administrator.
    12. NLQ troubleshooting — Query the agent directly for any remote network issue
    13. Open Strata Copilot in Strata Cloud Manager.
    14. Start a New Conversation, then select Troubleshooting from the @Agent drop-down.
    15. Enter a natural language query describing the remote network issue.
      Use one of the following strategies:
      • Private application unreachable — Diagnose why a specific private application is unreachable for users at a named site. The agent correlates network path and security policy data. (Example: "Users at Site-Tokyo can't reach the internal HR application via Prisma Access. What's wrong?")
      • Site-specific tunnel failure — Investigate why a tunnel is down or bouncing at a named site. (Example: "Why is the Dallas branch tunnel down? The CPE is a Cisco ISR.")
      • BGP routing failure — Diagnose a BGP neighbor failure or route advertisement issue at a specific site. (Example: "The BGP session to Site-Frankfurt is down. What's causing it?")
      • Service connection failure — Validate the path between Prisma Access and HQ or data center when private resources are unreachable from branch sites. (Example: "Branch users can't reach the on-prem SAP server. Is the service connection healthy?")
    16. Review the target plan and click Execute.
    17. Review the findings and remediation recommendations in Action Center.
      The agent presents the identified root cause with supporting evidence — IKE logs, BGP state, configuration comparison, traffic logs — and specific remediation steps for each finding. Review the recommendations and apply approved fixes manually, or work with your team to implement the suggested configuration changes.

    Sample Scenarios for the IPSec Troubleshooting Agent

    The following scenarios illustrate how the agent diagnoses and reports on remote network issues, both through automatic AIOps-triggered analysis and manual natural language queries in Strata Copilot.
    Scenario — IKE proposal mismatch after CPE configuration change: Prisma Access generates an INC_RN_PRIMARY_WAN_TUNNEL_DOWN incident for the Dallas branch. The site uses a Cisco ISR as CPE, and a Prisma Access content update was deployed the previous evening. The agent retrieves IKE event logs and finds Phase 1 negotiation failing with NO_PROPOSAL_CHOSEN. It compares the CPE's IKE proposal (AES-128-CBC, SHA-1, DH Group 2) against the Prisma Access IKE crypto profile updated by the previous night's content release (AES-256-GCM, SHA-256, DH Group 20), confirming a proposal mismatch. The agent generates two remediation options: update the Cisco ISR IKE proposal to match Prisma Access requirements, or create a custom IKE crypto profile that accepts the legacy cipher set with a security advisory. You review the findings in Action Center and work with the branch network team to update the CPE configuration. The tunnel re-establishes after the update.
    Scenario — Security policy blocking private application: A user reports that the internal project management application is unreachable via Prisma Access, but the site tunnel shows as up. You enter a query: "Users at Site-London can't access the internal project management app via Prisma Access. The tunnel appears to be up." The agent runs a coordinated analysis across the network troubleshooting and security policy sub-agents. Network analysis confirms the tunnel is established and BGP routing is healthy. The security policy sub-agent discovers that a recent content update recategorized an API endpoint under a new App-ID™ not included in the existing allow rule, resulting in deny actions in the traffic logs. The agent generates a recommendation to add the new App-ID to the security policy rule governing private application access. You review the recommendation and apply the security policy update, restoring application access for Site-London users.
    Scenario — MD5 authentication mismatch causes BGP session drop: Prisma Access generates an INC_RN_PRIMARY_WAN_BGP_DOWN incident for Site-Frankfurt after the HQ routing configuration was updated. The agent checks the BGP neighbor state machine and finds the session has dropped to Idle. Timer analysis shows no mismatch. The agent queries recent configuration changes and finds the HQ BGP configuration was updated 40 minutes before the incident, removing the MD5 authentication key on the HQ side while Prisma Access still requires MD5, causing the session to fail during re-establishment. You forward the recommendation to the HQ network team. Once MD5 configuration is aligned, the BGP session re-establishes and route exchange resumes.
    Scenario — Firewall ACL change breaks service connection: Prisma Access generates an INC_SC_PRIMARY_WAN_PROXY_TUNNEL_DOWN incident. Multiple branch sites report they can no longer reach on-premises applications at HQ. The agent validates the service connection IPSec tunnel state. The tunnel is down and IKE rekey failed 18 minutes before the incident. Log analysis shows the HQ-side firewall began dropping UDP 4500 traffic, consistent with a firewall ACL change on the HQ perimeter. The agent generates a recommendation to restore UDP 4500 and UDP 500 access on the HQ-side firewall and to re-initiate the service connection tunnel after the rule is corrected. You share the findings with the HQ security team. The firewall ACL is corrected, the service connection re-establishes, and private application access is restored for all branch sites.

    © 2026 Palo Alto Networks, Inc. All rights reserved.