TestingOps.ai

Private networks · Private network

Ivanti Connect Secure and TestingOps: test runs behind a Pulse gateway

A gateway machine connects to your Ivanti Connect Secure appliance, formerly Pulse Connect Secure, with the Pulse protocol, signs in with a password or a client certificate through the realm or sign-in URL you set, and carries the project's test traffic inside.

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

In short

Ivanti Connect Secure (Pulse) and TestingOps in short

TestingOps reaches environments behind Ivanti Connect Secure through a gateway machine that runs openconnect's Pulse protocol, signed in as a VPN user you provide.

The Ivanti connection takes a Server address and an optional Realm / sign-in URL path such as /employees, and signs in with Username + password or Client certificate; codes the appliance asks for appear on the TestingOps card.

SSO (SAML) appears in the Ivanti form but the gateway refuses it, and a certificate plus password combination is not offered for this type.

With a host pattern in the route list, names under it resolve through the VPN's DNS and the internal networks the Ivanti appliance announces are routed too.

What it does

What it does for your testing

  1. 1

    Sign-in through your realm

    Input
    A sign-in URL path such as /employees, or a realm for test users
    TestingOps
    Passes it to the client together with the server address
    Output
    Sign-in on the same realm your users' Ivanti client uses
  2. 2

    Token codes answered on the card

    Input
    An appliance that asks for a token code or OTP after the password
    TestingOps
    Shows the prompt on the TestingOps card and hands the typed code to the client
    Output
    A connected tunnel without access to the gateway machine
  3. 3

    Certificate sign-in

    Input
    A client certificate (PEM) and an optional key passphrase
    TestingOps
    Presents the certificate at sign-in
    Output
    A tunnel that can come back on its own when no code is asked

Step by step

How it works

  1. Add the connectionUnder Integrations → Private networks (VPN), choose Ivanti Connect Secure (Pulse) and enter the Server address, the Realm / sign-in URL path (optional) and the Username.
  2. Choose password or certificateUsername + password or Client certificate, with Additional verification if the appliance asks for a code. SSO is not supported by the gateway yet.
  3. Route, assign and set upList internal ranges or host patterns, pick the projects, then let RunningOps set up the gateway machine or install it on your own Ubuntu or Debian server that the runners can reach.
  4. ConnectSelect Connect and answer a code prompt on the card if one appears. Runs of the projects use the tunnel once the card shows Connected.

Connect

Setup

  1. Ask the appliance administrators for a VPN account for testing and the sign-in URL or realm it uses.
  2. In TestingOps, open Integrations → Private networks (VPN) → Ivanti Connect Secure (Pulse); enter Server address, Realm / sign-in URL path (optional) and Username, and choose Username + password or Client certificate.
  3. Enter the internal ranges or host patterns under Networks and hosts to route through the VPN, and choose the Projects that use this VPN.
  4. Choose Set up gateway, then select Connect and answer a code prompt if the card shows one.
Where you connect it in TestingOps: Integrations → Private networks (VPN) → Ivanti Connect Secure (Pulse)

Use cases

Use cases

A partner realm for testing

Trigger
The appliance has a separate sign-in URL for partners
Uses
Realm / sign-in URL path and a partner test account
Agent activity
The gateway machine signs in through that sign-in URL; web runs of the project use the tunnel
Result
Test traffic arrives under the partner realm's access rules

Token codes during working hours

Trigger
The test account must enter a token code at sign-in
Uses
Additional verification and the code prompt on the card
Agent activity
A team member types the code when the card asks
Result
Runs reach the environment after the sign-in completes
Condition
Someone must be available when the appliance asks for a new code

A private address in a project without a VPN

Trigger
A case opens a private IP address, but its project has no VPN linked
Uses
TestingOps' private address check before a run
Agent activity
The run is refused before it starts, with a message that this is not a test failure
Result
No run that fails every step on an unreachable address
Condition
Link the project to the connection, or use Use for all projects of this customer

Capabilities

Capabilities and limits

What is read

Internal addresses that the gateway machine routes into the Ivanti tunnel: listed hosts and ranges and, with a host pattern, the networks the appliance announces.

What is produced

A tunnel and a proxy for web test runs, with status and routed networks on the card.

Where it can write

Test traffic only. Credentials are stored encrypted in TestingOps; the certificate is written to a private file on the gateway machine only while connected.

How it connects

openconnect with the Pulse protocol on the gateway machine, using your realm or sign-in URL path; test browsers reach the gateway machine through a proxy

Account and permissions

  • A test account on the Ivanti appliance, used only by the gateway machine
  • Username + password, or Client certificate (PEM, with an optional key passphrase)
  • Codes typed on the TestingOps card when the appliance asks

Limits

  • SSO (SAML) is listed in the form but not supported by the gateway yet
  • No certificate plus password combination for this type
  • Up to 50 route entries: IPv4 ranges or host patterns; no IPv6
  • Only web runs use the tunnel; real phones and iOS devices do not
  • In the cloud, the gateway machine must sit inside the RunningOps network

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team's supplier portal is reached through an Ivanti Connect Secure appliance whose test users sign in at the /suppliers URL with a password and a token code. The team enters the server, the path and the 10.90.0.0/16 range, and lets RunningOps set up the gateway machine.

After a tester types the token code on the card, the card shows Connected and the project's web runs that afternoon reach the portal.

Frequently asked questions

Can the gateway use SAML SSO with Ivanti?

Not yet. The form lists SSO, but the gateway refuses it for Ivanti connections. Use a password or a client certificate.

What goes into Realm / sign-in URL path?

The realm or the path of the sign-in URL your users open, for example /employees. Leave it empty when users sign in at the server's default address.

Is this the same as Pulse Connect Secure?

Yes. Ivanti Connect Secure is the current name of Pulse Connect Secure, and the gateway machine speaks the Pulse protocol through openconnect.

What if a case points at an internal address but no VPN is linked to its project?

The run does not start. TestingOps sees the private address, says the project has no private network connected and that this is not a test failure, so you can link the project to the connection first.

Next step

Ask in a demo how your Ivanti sign-in would work for test runs.

Request a demoMore private networks integrations