TestingOps.ai

Private networks · Private network

FortiClient SSL VPN and TestingOps: test runs behind a FortiGate

A gateway machine connects to your FortiGate's SSL VPN on the port and realm you set, signs in with a password or a certificate plus password, and gives the project's web runs a way into the network.

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

In short

FortiClient (SSL VPN) and TestingOps in short

TestingOps reaches environments behind a FortiGate SSL VPN through a gateway machine that runs openconnect's Fortinet protocol, signed in as a VPN user you provide.

The FortiGate connection takes a Server address, an optional Port and Realm, and signs in with Username + password or Certificate + password, while codes the FortiGate asks for are shown on the TestingOps card.

SSO (SAML) appears in the FortiClient form but the gateway refuses it, a client certificate on its own is not offered, and FortiClient's IPsec mode is not supported.

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

What it does

What it does for your testing

  1. 1

    The entry point your users already use

    Input
    An SSL VPN on a port other than 443, with a realm for outside parties
    TestingOps
    Passes the port with the server address and the realm as the user group to the client
    Output
    Sign-in on the FortiGate entry point and realm your FortiClient users already have
  2. 2

    One-time codes from the card

    Input
    A user that must enter a code after the password
    TestingOps
    Shows the FortiGate's code prompt on the TestingOps card and hands the typed code to the client
    Output
    A tunnel that comes up after a person types the code
  3. 3

    Certificate and password together

    Input
    A FortiGate that requires a client certificate together with the password
    TestingOps
    Presents both at sign-in
    Output
    Sign-in for SSL VPN portals that demand two credentials

Step by step

How it works

  1. Add the connectionChoose FortiClient (SSL VPN) under Integrations → Private networks (VPN); enter the Server address, the Port if it is not 443, the Realm (optional) and the Username.
  2. Choose the sign-inUsername + password or Certificate + password; set Additional verification when the FortiGate asks for a code.
  3. Route and assignList internal ranges or host patterns and pick the projects whose runs need the VPN.
  4. Set up the gateway machine and connectChoose who hosts the gateway machine, RunningOps or your own Ubuntu or Debian server reachable by the runners, then select Connect and type the code when the card asks.

Connect

Setup

  1. Get an SSL VPN user for testing from the FortiGate administrators, with the server address, port and realm your FortiClient users connect with.
  2. In TestingOps, open Integrations → Private networks (VPN) → FortiClient (SSL VPN); enter Server address, Port, Realm (optional) and Username, then choose Username + password or Certificate + password and Additional verification.
  3. Under Networks and hosts to route through the VPN, list the ranges or host patterns behind the FortiGate, and select the projects that need the tunnel.
  4. Set up the gateway machine from Set up gateway: RunningOps can start one for the connection, or you run the one-time command, valid for 24 hours, on an Ubuntu or Debian server reachable by the runners.
  5. Select Connect and type the code if the card asks for one.
Where you connect it in TestingOps: Integrations → Private networks (VPN) → FortiClient (SSL VPN)

Use cases

Use cases

A separate realm for the test service

Trigger
The FortiGate gives outside parties their own realm
Uses
Realm (optional) and a test account in that realm
Agent activity
The gateway machine signs in to that realm; the project's web runs go through it
Result
Test traffic arrives under the realm's own access rules on the FortiGate

Unattended reconnects

Trigger
The tunnel drops overnight
Uses
Certificate + password with no second factor
Agent activity
The gateway machine signs in again on its own after the drop
Result
Night runs find the tunnel back without anyone typing a code
Condition
Only when the FortiGate does not ask for a code

Internal API names

Trigger
The test site calls several internal APIs by name
Uses
A host pattern for the internal domain
Agent activity
Names under the pattern resolve through the VPN's DNS and the announced internal networks are routed
Result
The site and its APIs open in runs
Condition
If the FortiGate announces no networks, add the internal range too

Capabilities

Capabilities and limits

What is read

Internal addresses the gateway machine routes into the FortiGate tunnel: the hosts and ranges you list and, with a host pattern, the networks the FortiGate announces.

What is produced

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

Where it can write

Test traffic only. Password and certificate are stored encrypted in TestingOps and reach the gateway machine only for the connection.

How it connects

openconnect with the Fortinet protocol on the gateway machine, using your server, port and realm; test browsers reach the gateway machine through a proxy

Account and permissions

  • An SSL VPN user on the FortiGate for the gateway machine, ideally test-only
  • Username + password, or Certificate + password (PEM certificate with an optional key passphrase)
  • Codes typed on the TestingOps card; push approved on the phone

Limits

  • SSL VPN only: FortiClient's IPsec mode is not supported
  • SSO (SAML) is listed in the form but refused by the gateway
  • No certificate-only sign-in: a certificate needs a password with it
  • 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

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team's warehouse application is published through a FortiGate SSL VPN on port 10443, with a realm for contractors. The team enters the server, the port and the realm, chooses Username + password with an authenticator code, and lists *.wms-test.example together with the 10.70.0.0/16 range.

A tester types the code when the card asks for it. The project's web runs then reach the application and the internal APIs it calls by name.

Frequently asked questions

Does it work with FortiClient's IPsec VPN?

No. The connection uses the FortiGate's SSL VPN only.

Can the gateway use SAML SSO?

Not yet. SSO is listed in the form but refused by the gateway for FortiGate connections. Use a password, or a certificate together with a password.

Our SSL VPN listens on another port. Where does that go?

In the Port field. The gateway machine connects to the server address on that port.

What is the realm field for?

It selects the realm on the FortiGate, the same value your FortiClient users connect with. Leave it empty when your users connect without a realm.

Where can the gateway machine run?

In the cloud it has to be reachable by the test runners, and the usual way is Let RunningOps set it up, which starts it inside the RunningOps network. A gateway installed on a machine in your office network is refused for runs, because the runners cannot reach it.

Next step

Ask in a demo how runs would reach an application behind your FortiGate.

Request a demoMore private networks integrations