TestingOps.ai

Private networks · Private network

Cisco Secure Client (AnyConnect) and TestingOps: test runs behind your ASA or FTD

A gateway machine connects to your Cisco ASA or Firepower Threat Defense headend over the AnyConnect protocol, signs in with a password, a client certificate or both, and carries the project's test traffic to the internal addresses you route.

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

In short

Cisco Secure Client (AnyConnect) and TestingOps in short

TestingOps reaches environments behind Cisco Secure Client (AnyConnect) through a gateway machine that runs openconnect's AnyConnect protocol against your ASA or FTD headend, as a VPN user you provide.

The AnyConnect sign-in uses a username and password, a client certificate, or a certificate plus password, in the group or connection profile you name, and second-factor prompts appear on the TestingOps card for a person to answer.

SSO (SAML) is listed in the AnyConnect form but the gateway refuses it, so a headend that only allows SSO cannot be connected yet.

Listed hosts and networks go into the AnyConnect tunnel, and with a host pattern, names under it resolve through the VPN's DNS and the internal networks the headend announces are routed too.

What it does

What it does for your testing

  1. 1

    A connection profile signed in with a password

    Input
    Server address, Group / connection profile and a test account
    TestingOps
    Signs in through openconnect with the password passed on standard input, never on the command line
    Output
    A tunnel the project's web runs use
  2. 2

    Second-factor prompts answered on the card

    Input
    A headend that asks for a code after the password
    TestingOps
    Detects the prompt, shows it on the TestingOps card and hands the typed code to the client once
    Output
    A signed-in tunnel without anyone at the gateway machine's console
  3. 3

    Certificate sign-in that needs no person

    Input
    A client certificate (PEM) and its key passphrase, with no second factor
    TestingOps
    Presents the certificate, with a password too when the profile asks for both
    Output
    A tunnel that comes back on its own after a drop

Step by step

How it works

  1. Add the connectionUnder Integrations → Private networks (VPN), choose Cisco Secure Client (AnyConnect) and enter the Server address, the Group / connection profile and the Username.
  2. Pick a supported sign-inUsername + password, Client certificate or Certificate + password. Do not pick SSO: the gateway refuses it for this VPN type.
  3. Route and assignList internal ranges or host patterns under Networks and hosts to route through the VPN and pick the projects.
  4. Set up the gateway machineLet RunningOps start a machine for the connection, or install the gateway with the one-time command on a server of yours that the test runners can reach.
  5. ConnectSelect Connect. If the headend asks for a code, the card shows the prompt; runs of the project wait until the sign-in completes.

Connect

Setup

  1. Ask the network team for a VPN account for testing, the headend's address and the connection profile to use; check that the profile accepts a password or a certificate.
  2. In TestingOps, open Integrations → Private networks (VPN) → Cisco Secure Client (AnyConnect); enter Server address, Group / connection profile and Username, and choose Username + password, Client certificate or Certificate + password.
  3. Set Additional verification if the headend asks for a code, add Networks and hosts to route through the VPN and select the projects.
  4. Under Set up gateway, let RunningOps start the gateway machine, or take the one-time install command for an Ubuntu or Debian server of yours that the runners can reach.
  5. Select Connect; if the headend asks for a second factor, type it into the prompt on the card.
Where you connect it in TestingOps: Integrations → Private networks (VPN) → Cisco Secure Client (AnyConnect)

Use cases

Use cases

A dedicated test profile on the ASA

Trigger
The network team creates a connection profile for test traffic
Uses
Group / connection profile, username and password
Agent activity
The gateway machine signs in to that profile; the project's web runs go through it
Result
Runs reach the internal site through a profile the network team controls
Condition
The profile must accept password or certificate sign-in, not SSO only

Unattended reconnects at night

Trigger
Runs are scheduled when nobody is around
Uses
Client certificate without a second factor
Agent activity
The gateway machine reconnects with the certificate when the tunnel drops
Result
No sign-in prompt waiting for a person
Condition
Only when the headend does not ask for a code

Accounts with an authenticator code

Trigger
The headend asks for an authenticator code after the password
Uses
Additional verification: Authenticator code (OTP)
Agent activity
The card shows the prompt and a team member types the code
Result
The tunnel comes up; a refused code waits for Retry instead of being repeated
Condition
Someone must be available whenever the headend asks for a new code

Capabilities

Capabilities and limits

What is read

Hosts behind the ASA or FTD that the tunnel reaches: the entries you list and, with a host pattern, the split networks the headend announces.

What is produced

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

Where it can write

Test traffic only. Credentials are stored encrypted in TestingOps; on the gateway machine the password goes to the client on standard input and the certificate sits in a private file removed when the connection stops.

How it connects

openconnect with the AnyConnect protocol on the gateway machine, using your group or connection profile; test browsers reach the gateway machine through a proxy

Account and permissions

  • A VPN account on the headend for the gateway machine, ideally test-only
  • Sign-in by Username + password, by Client certificate or by Certificate + password; certificates are PEM files with an optional key passphrase
  • Second factor: codes typed on the TestingOps card, or push approved on the phone

Limits

  • SSO (SAML) sign-in is not supported by the gateway yet, although the form lists it
  • A person must answer every new code prompt; runs wait meanwhile
  • Up to 50 route entries: IPv4 ranges or host patterns; no IPv6
  • Only web runs use the tunnel; real phones and iOS devices use their own network
  • In the cloud, the gateway machine must run inside the RunningOps network to be usable by runs

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team's internal HR application runs behind an ASA. The network team issues a test account in a connection profile named Testing that asks for a password and then an authenticator code. The QA team enters the server, the profile and the 10.60.0.0/16 range, lets RunningOps set up the gateway machine and selects Connect.

The card shows the code prompt, a tester types the code from their authenticator app, and the project's web regression runs through the tunnel that afternoon.

Frequently asked questions

Can the gateway sign in with SSO through AnyConnect?

Not yet. The form lists SSO (SAML / Azure AD, Okta…), but the gateway refuses it for this VPN type. Use a password, a client certificate or both, or ask the network team for a profile that allows them.

Where do we type the second-factor code?

On the connection's card in TestingOps. The gateway machine detects the code prompt and shows it there; the code you type goes to the client once and is then deleted.

Is the password visible on the gateway machine?

It is passed to the client on standard input, not on its command line, and TestingOps keeps it encrypted. Certificate files are written with private permissions and removed when the connection stops.

Which part of Cisco's VPN does this use?

The AnyConnect protocol against an ASA or Firepower Threat Defense headend, through openconnect. The Group / connection profile field selects the profile, as the group list in Cisco's own client would.

Who runs the VPN client?

The gateway machine, signed in as the VPN user you provide. With Let RunningOps set it up, RunningOps starts a dedicated machine for the connection; nothing is installed on your computers.

Next step

Ask in a demo whether your AnyConnect profile can be used for test runs as it is.

Request a demoMore private networks integrations