TestingOps.ai

Private networks · Private network

OpenVPN and TestingOps: test runs into a private environment with an .ovpn profile

Upload the OpenVPN profile and a gateway machine brings up the tunnel with it, routes the IP ranges you list and nothing the server pushes, and gives the project's web runs a way to the internal hosts.

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

In short

OpenVPN and TestingOps in short

TestingOps connects to OpenVPN with a profile (.ovpn) you upload: a gateway machine runs the openvpn client with it, either with the certificate inside the profile alone or with a username and password as well.

Only the IPv4 ranges you list are routed into the OpenVPN tunnel; routes and DNS settings the server pushes are ignored, so internal hosts need IP addresses or names that public DNS resolves to addresses in those ranges.

Host patterns cannot be used with OpenVPN, and one-time codes are not supported for OpenVPN even though the form shows Additional verification.

What it does

What it does for your testing

  1. 1

    A profile becomes a test tunnel

    Input
    An .ovpn profile with the certificate inside
    TestingOps
    Starts the tunnel on the gateway machine with the profile and adds one route per range you list
    Output
    Web runs that reach hosts in those ranges
  2. 2

    Routing you decide

    Input
    An OpenVPN server that pushes many routes, DNS settings or a full tunnel
    TestingOps
    Ignores what the server pushes and routes only your list
    Output
    Only your ranges go into the VPN; the gateway machine's own traffic stays outside
  3. 3

    Profile plus account

    Input
    A profile that also asks for a username and password
    TestingOps
    Hands the credentials to the client from a private file that is removed when the connection stops
    Output
    Sign-in without anyone typing, whenever the tunnel restarts

Step by step

How it works

  1. Upload the profileUnder Integrations → Private networks (VPN), choose OpenVPN, pick Profile only (certificate inside) or Profile + username/password and upload the Profile (.ovpn).
  2. List IP rangesUnder Networks and hosts to route through the VPN, enter IPv4 ranges or single addresses only; a host pattern or host name makes the OpenVPN session fail.
  3. Keep Additional verification at NoneThe gateway refuses OpenVPN connections that need a one-time code.
  4. Set up the gateway machine and connectWith Let RunningOps set it up the machine is started for you; on your own server, run the one-time install command instead. Then select Connect.

Because pushed DNS is ignored, point the project's environments at IP addresses or at names that public DNS resolves to addresses in your ranges.

Connect

Setup

  1. Get an .ovpn profile for the test service from your VPN team, and a username and password if the server requires them.
  2. In TestingOps, open Integrations → Private networks (VPN) → OpenVPN, choose Profile only (certificate inside) or Profile + username/password, and upload the Profile (.ovpn).
  3. Enter the internal IPv4 ranges under Networks and hosts to route through the VPN, select the projects and leave Additional verification at None.
  4. Use Set up gateway: with Let RunningOps set it up (recommended) nothing is installed on your side, and Install on my own server gives a command for an Ubuntu or Debian server the runners can reach.
  5. Select Connect, and use IP addresses, or names that public DNS resolves into your ranges, for the project's environments.
Where you connect it in TestingOps: Integrations → Private networks (VPN) → OpenVPN

Use cases

Use cases

A test lab behind an OpenVPN server

Trigger
A lab network is reachable only through the team's OpenVPN server
Uses
Profile only, with the lab's /24 range
Agent activity
Web runs open the lab's addresses through the tunnel
Result
Runs against the lab without exposing it to the internet
Condition
Lab hosts are addressed by IP or by names that public DNS resolves to them

A profile and a service account

Trigger
The VPN team issues a profile and a service account for the test service
Uses
Profile + username/password
Agent activity
The gateway machine signs in with both every time the tunnel starts
Result
Reconnects without a person
Condition
No one-time code on that account

A changed password does not lock the account

Trigger
The service account's password was changed on the VPN side
Uses
The gateway's handling of refused sign-ins
Agent activity
After the server answers AUTH_FAILED, the gateway machine stops and waits for Retry instead of trying again on a timer
Result
No lockout from repeated failed sign-ins; update the password and select Retry

Capabilities

Capabilities and limits

What is read

Hosts in the IPv4 ranges you list. Test browsers also send the run's own environment and case addresses to the gateway machine, but only your ranges enter the OpenVPN tunnel there.

What is produced

A tunnel and a proxy for web test runs, with the connection state on the card.

Where it can write

Test traffic only. The profile and password are stored encrypted in TestingOps; on the gateway machine they sit in private files removed when the connection stops.

How it connects

The openvpn client on the gateway machine with your profile, ignoring pushed routes and DNS options; test browsers reach the gateway machine through a proxy

Account and permissions

  • An OpenVPN profile (.ovpn, up to 64 KB) issued for the test service
  • Profile only (certificate inside) or Profile + username/password
  • No sign-in step on the TestingOps card: OpenVPN connections start without a person

Limits

  • IPv4 ranges only: host patterns and host names in the route list break the session
  • Routes and DNS pushed by the server are ignored; internal-only names do not resolve
  • One-time codes (SMS, OTP, push) are not supported, although the form offers Additional verification
  • At least one range is required, and up to 50 can be listed
  • 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 keeps a staging lab on 10.30.5.0/24 behind the company's OpenVPN server. The VPN team issues a profile and a service account for testing; the QA team uploads the profile, chooses Profile + username/password and lists 10.30.5.0/24.

The lab's test environment is entered in TestingOps by IP address, because the lab names exist only in the VPN's DNS, which OpenVPN connections ignore. Runs reach the lab, and when the service account's password changes, the connection waits for Retry instead of locking the account.

Frequently asked questions

Why do internal host names not resolve?

OpenVPN connections ignore the DNS settings the server pushes, so the gateway machine resolves names through public DNS. Use IP addresses, or names that public DNS resolves to addresses in your listed ranges.

Can we use host patterns like *.corp.local?

No. For OpenVPN the gateway turns each entry into an IP route, so a pattern or host name makes the session fail. List IPv4 ranges or single addresses.

Does OpenVPN support one-time codes here?

No. The form shows Additional verification, but the gateway refuses OpenVPN connections that ask for an SMS, OTP or push step. Use a profile, with a username and password if needed.

What happens when the password is refused?

The gateway machine stops and waits for Retry on the card instead of trying again on a timer, so repeated failures do not lock the account.

Will the server's own routes be used?

No. Routes the server pushes are ignored and only the ranges you list go into the tunnel, which also keeps a full-tunnel profile from taking over the gateway machine's own traffic.

Next step

Ask in a demo whether your OpenVPN profile and addressing fit test runs as they are.

Request a demoMore private networks integrations