TestingOps.ai

Private networks · Private network

GlobalProtect and TestingOps: AI test runs behind a Palo Alto Networks VPN

Test runs reach environments behind your GlobalProtect portal through a gateway machine that signs in as a VPN user you provide, with SAML SSO in a sign-in window shown in TestingOps, a password and an SMS or OTP code, or a client certificate.

  • Private network
  • Available
Request a demo
Connection
Private network
Writes back
Test traffic only
Last checked
7 Nov 2026

In short

GlobalProtect and TestingOps in short

TestingOps reaches environments behind GlobalProtect through a gateway machine, a small Ubuntu or Debian server that runs open-source GlobalProtect-compatible clients, signs in to your portal as a VPN user you provide and gives the project's web runs a proxy into the network.

GlobalProtect sign-in can be SAML SSO completed by a person in a VPN sign-in window on the TestingOps card, a username and password with an optional SMS, authenticator or push step, or a client certificate.

Test browsers send the listed networks and host patterns, plus the run's own environment and case addresses, to the gateway machine; with a host pattern, names under it resolve through the VPN's DNS and the internal networks the portal announces are routed into the tunnel.

In the cloud, RunningOps can set the gateway machine up for the connection, or you install it on your own Ubuntu or Debian server that the test runners can reach.

What it does

What it does for your testing

  1. 1

    SSO without a stored password

    Input
    A portal that signs in through SAML, for example Azure AD or Okta
    TestingOps
    Shows the portal's sign-in page in a window on the TestingOps card, where a person signs in including the SMS or app step
    Output
    A connected tunnel; the VPN password is never stored in TestingOps
  2. 2

    Posture rules that expect a desktop

    Input
    A portal whose HIP or operating-system rules only serve Windows or Mac clients
    TestingOps
    Sends a HIP report and presents the client operating system you choose
    Output
    Pages that load through the tunnel, instead of a tunnel that connects but serves nothing
  3. 3

    Internal names resolved by the VPN

    Input
    A host pattern such as *.corp.example in the route list
    TestingOps
    Sends names under it to the VPN's DNS and routes the internal networks the portal announces
    Output
    The site and the internal APIs it calls open by name in test runs

Step by step

How it works

  1. Describe the portalUnder Integrations → Private networks (VPN), choose GlobalProtect and enter the Portal address, an optional Gateway, the Username and the sign-in method.
  2. Say what goes through the VPNAdd internal ranges or host patterns under Networks and hosts to route through the VPN, and pick the projects whose runs need it.
  3. Set up the gateway machineLet RunningOps set it up (recommended) starts a machine for this connection; Install on my own server gives a one-time command for an Ubuntu or Debian server the test runners can reach.
  4. Connect and sign inSelect Connect. With SSO, sign in in the VPN sign-in window on the card; with a password and a code, type the code when the card asks.
  5. Runs go through the tunnelWeb runs of the selected projects use the gateway machine. While the VPN is not connected, their runs do not start and the message says what to do.

SSO and password sign-in use the gpclient GlobalProtect client, which the installer adds on Ubuntu; on a Debian server only the certificate method is available.

Connect

Setup

  1. Get a GlobalProtect account for the gateway machine from your network team, preferably a test-only account, and the portal address.
  2. In TestingOps, open Integrations → Private networks (VPN) and choose GlobalProtect. Enter Portal address, Gateway (optional) and Username, choose SSO (SAML / Azure AD, Okta…), Username + password or Client certificate, and set Additional verification if the portal asks for a code.
  3. Fill in Networks and hosts to route through the VPN (for example 10.122.0.0/16 or *.corp.local) and select the projects; Use for all projects of this customer adds that customer's new projects automatically.
  4. Choose Set up gateway: Let RunningOps set it up (recommended), or Install on my own server and run the one-time command, valid for 24 hours, on an Ubuntu or Debian server the runners can reach.
  5. Select Connect and complete the sign-in on the card. If pages do not open although the tunnel is up, set Client operating system to Windows or macOS and sign in again.
Where you connect it in TestingOps: Integrations → Private networks (VPN) → GlobalProtect

Use cases

Use cases

Nightly regression on an SSO-protected staging site

Trigger
Staging sits behind a GlobalProtect portal with Azure AD sign-in
Uses
SAML sign-in in the VPN sign-in window
Agent activity
A team member signs in on the card; the project's web runs then go through the gateway machine
Result
Runs that reach staging without a VPN client on anyone's laptop
Condition
Someone must sign in again whenever the portal asks for a new sign-in

Tunnel up, pages blank

Trigger
The tunnel connects but no page of the test site opens
Uses
Client operating system set to Windows or macOS, with the HIP report
Agent activity
The gateway machine signs in again presenting the chosen system
Result
The portal applies its desktop client rules and the pages load
Condition
Changing Client operating system needs a new sign-in

Preprod names that public DNS does not know

Trigger
The app calls internal hosts that only the VPN's DNS can resolve
Uses
A host pattern for the domain
Agent activity
The gateway machine resolves names under the pattern through the VPN's DNS and routes the internal networks the portal announces
Result
The site and its internal APIs open in runs
Condition
If the portal announces no networks, add the internal range as well

Capabilities

Capabilities and limits

What is read

Internal addresses covered by the gateway machine's routes: the hosts and networks you list and, with a host pattern, the networks the portal announces. Only test traffic uses the tunnel.

What is produced

A tunnel and a proxy for web test runs; the card shows the connection state, the name resolution in use and which VPN networks are routed.

Where it can write

Nothing in your network beyond test traffic. Passwords, certificates and passphrases are stored encrypted in TestingOps and never returned by its API; with SSO no password is stored.

How it connects

gpclient for SSO and password sign-in, or openconnect's GlobalProtect protocol for certificates, on the gateway machine, with a HIP report; test browsers reach the gateway machine through a proxy

Account and permissions

  • A GlobalProtect account for the gateway machine, ideally one used only for testing
  • SSO (SAML / Azure AD, Okta…), Username + password, or Client certificate (PEM, with an optional key passphrase)
  • Additional verification: SMS code, Authenticator code (OTP) or Push approval, entered or approved by a person when the portal asks

Limits

  • A person has to complete SSO or a code each time the portal asks for a new sign-in; runs wait meanwhile
  • Up to 50 route entries: IPv4 ranges from /8 to /32 or host patterns; no IPv6
  • Only web runs use the tunnel; real phones and iOS devices use their own network
  • In the cloud, a gateway machine outside the RunningOps network cannot be used by runs
  • A refused sign-in is not retried on a timer; it waits for Retry, so repeated attempts do not lock the account

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A retail team's preprod shop is only published behind GlobalProtect with Okta sign-in. The team adds the portal, lists *.shop-preprod.example and the 10.40.0.0/16 range, and lets RunningOps set up the gateway machine. A tester signs in in the VPN sign-in window and approves the Okta push on their phone.

The first run connects, but every page times out: the portal's rules only serve Windows clients. The team sets Client operating system to Windows, signs in again, and the regression runs through the tunnel.

Frequently asked questions

Is our VPN password stored when we use SSO?

No. With SSO a person signs in when the connection starts, in the VPN sign-in window on the TestingOps card. Keystrokes go straight to the sign-in page and are not stored.

What if the sign-in window cannot be shown?

The card offers Open the sign-in page instead. Complete the sign-in in your browser, including the SMS or app step, and paste the text that starts with globalprotectcallback: back into the card.

Why does the tunnel connect but no page opens?

Some portals choose access rules by the client's operating system or HIP report. The gateway machine sends a HIP report; if the official app works on a Windows or Mac computer but runs see nothing, set Client operating system to that system and sign in again.

We switched to another VPN account. Could the old session still be used?

No. When the username changes, the gateway machine forgets the saved SSO session and asks for a new sign-in, so the tunnel never opens as the previous user.

Does all test traffic go through the VPN?

No. Test browsers send the listed networks and patterns, the run's own environment and case addresses and names they cannot resolve to the gateway machine; everything else goes directly. At the gateway machine, listed entries enter the tunnel, and with a host pattern so do the internal networks the portal announces.

What happens to a run while the VPN is down?

It does not start. The run says why, for example that the connection is waiting for a sign-in, and what to do next, so an unreachable environment is not reported as failed tests.

Next step

Bring your GlobalProtect portal details to a demo to see how runs would reach your test environment.

Request a demoMore private networks integrations