Microsoft Entra Global Secure Access
Troubleshooting

How to investigate the Global Secure Access remote network connectivity

In brief

The article now distinguishes tunnel and BGP connectivity scenarios and adds investigation steps, licensing requirements, least-privilege roles, and Microsoft Graph permissions for viewing and managing signals and alerts.

What Entra admins need to know

Administrators have clearer guidance for troubleshooting remote network health issues and determining the access required to view or manage related alerts.

This editorial summary was generated by AI from the documentation changes. Verify important details in the full Microsoft Learn article.

Documentation change

The comparison below shows only the changed extract. Use the full-page view for complete context.

This article describes the health metrics related to remote network connectivity and provides steps to troubleshoot potential problems. Tunnel connectivity and BGP connectivity are separate health scenarios, but this article covers them together because BGP depends on an established IPsec tunnel.

This article covers two scenarios:

  • Global Secure Access requiring remote network tunnel connectivity

Prerequisites

There are different roles, permissions, and license requirements to view health monitoring signals and to configure and receive alerts. We recommend using a role with least privilege access to align with the Zero Trust guidance.

Investigate the signals and alerts

To investigate a signal, gatherStart your investigation by identifying whether the following data:alert is for tunnel connectivity or BGP connectivity. Then compare the alert timeframe and affected remote networks with the remote network health and audit logs.

  1. View the details of the alert.

  1. Sign intoin to the Microsoft Entra admin center as at least a Reports ReaderReports Reader.

    • Browse to Entra ID > Monitoring & health > Health. The page opens to the Service Level Agreement (SLA) Attainment page.

    • Select the Health Monitoring tab.

    • Select the Global Secure Access requiring remote network tunnel connectivity scenario.or Global Secure Access requiring remote network BGP connectivity scenario, and then select an active alert.

      :::image type="content" source="media/howto-investigate-remote-networks-scenario-signals/remote-network-border-gateway-protocol-alert.png" alt-text="Screenshot of the Global Secure Access remote network BGP connectivity scenario with one active alert." lightbox="media/howto-investigate-remote-networks-scenario-signals/remote-network-border-gateway-protocol-alert.png":::

    • Review the remote network health logs.

      • For a tunnel alert, look for Tunnel disconnected events for the affected remote network, source IP address, and destination IP address.
      • For a BGP alert, look for BGP disconnected events. Review the BGP Routes Advertised Count in the corresponding Remote network alive events.
      • Use Remote network alive events to compare sent and received bytes before and during the alert.
    • Review your Remotethe Global Secure Access audit logs for recent changes to the affected remote network, device link, IPsec configuration, or traffic profile assignment.

      :::image type="content" source="media/howto-investigate-remote-networks-scenario-signals/global-secure-access-audit-logs.png" alt-text="Screenshot of audit logs filtered to the Global Secure Access service." lightbox="media/howto-investigate-remote-networks-scenario-signals/global-secure-access-audit-logs.png":::

    • If you need longer retention or correlation, export the remote network health logs to Log Analytics and analyze them with a workbook.

Understand the signals

Tunnel and BGP alerts represent different layers of remote network health logs.connectivity:

  • How to use the remote network health logs - Global Secure Access | Microsoft LearnThe tunnel connectivity signal tracks whether IPsec tunnels are connected or disconnected. If the tunnel is disconnected, BGP can't exchange routes over that tunnel.
  • The BGP connectivity signal tracks whether the BGP session is connected and exchanging route information over an established tunnel. An IPsec tunnel can remain connected while BGP is disconnected.

A spike in disconnected tunnels or BGP sessions can indicate a CPE, internet service provider, configuration, or Global Secure Access edge connectivity problem. Compare the alert start time with remote network health events, audit logs, and planned network maintenance.

Mitigate common issues

The following common issues can cause a tunnel or BGP connectivity alert. This list isn't exhaustive, but it provides a starting point for your investigation.

One or more IPsec tunnels are disconnected

A tunnel can disconnect because of a CPE outage, internet connectivity problem, or mismatch between the CPE and Global Secure Access IPsec configuration.

To investigate and mitigate the issue:

  1. In the alert, identify the affected remote network and alert start time.
  2. Configure diagnostic settings to export logs.

    In the remote network health logs, filter by the remote network ID. Identify Tunnel disconnected events and note the source and destination IP address pair.
  3. AnalyzeCheck the CPE status and logs with a workbook.

    for the matching tunnel. Confirm that the public IP addresses, IPsec parameters, shared secret or certificate, and tunnel endpoints match the Global Secure Access device link configuration.
  4. Review the audit logs.logs for changes to the remote network or device link near the alert start time.

  5. Restore CPE or internet connectivity, or correct the mismatched configuration.
  6. Confirm that a Tunnel connected event appears and that sent and received bytes resume in subsequent Remote network alive events.

The IPsec tunnel is connected, but BGP is disconnected

The underlying tunnel can remain connected while the BGP neighbor relationship is down. In this state, the remote network might not exchange the routes that are required to forward traffic.

  • Look for BGP disconnected events. Check the BGP Routes Advertised Count in Remote network alive events for the affected remote network.
  • On the CPE, verify the BGP neighbor IP addresses, autonomous system numbers, and route advertisement configuration.
  • Review recent CPE and Global Secure Access configuration changes.
  • Correct the BGP configuration or restart the affected BGP session according to your CPE vendor's guidance.
  • Confirm that a BGP connected event appears. Then confirm that the advertised route count returns to its expected value in subsequent Remote network alive events.
  • Connectivity is intermittent or depends on a single tunnel

    A remote network with one tunnel has no alternate path during CPE, ISP, or Global Secure Access edge maintenance or failure.

    To investigate and mitigate the issue:

    1. Review the health logs for repeated tunnel or BGP disconnect and reconnect events.
    2. Confirm whether the remote network has redundant tunnels.
    3. Configure at least two IPsec tunnels per location. Use zone redundancy or a secondary geographic remote network based on your availability requirements.
    4. Configure tunnel weighting for active-active or active-standby routing.
    5. Use BGP for dynamic route learning. If your CPE doesn't support BGP, configure static routes with appropriate metrics.
    6. Export remote network health logs to Log Analytics and create alert rules for tunnel and BGP failures.

    For redundancy and failover guidance, see Enhance remote network resilience.

    Related content

    Daily Entra.News

    Get daily email updates

    Get a concise summary of the latest Microsoft Entra updates delivered straight to your inbox.

    Loading the secure signup form…