Network configuration for TestCloud

If your application under test is hosted in a highly secure network, you might want to whitelist TestCloud infrastructure public IPs & endpoints.

TestCloud Internet facing components


Component	Domains / IPs	Usage
TestCloud Main Web Service	https://testcloud.katalon.com	TestOps web application that interacts with this Restful service to handle all test runs.
Tunnel Manager	https://tunnel-manager.katalon.com \| 44.214.101.94	Tunnel metadata management that provides authentication and manages tunnel traffic routing.
Tunnel Server (Network Load Balancing)	QUIC over UDP: tunnel-proxy-1.katalon.com:2345 \| 34.236.12.143 tunnel-proxy-2.katalon.com:2345 \| 52.20.65.100	Tunnel server that controls traffic between test execution engine and target website behind a firewall.
NAT Gateway (TestCloud Cluster)	34.197.223.43/32 54.82.166.185 3.230.98.218	The gateway to the Internet for outgoing network operations from TestCloud Agent components. The gateway has specific public IPs (or IP range) for easy white-listing, if needed.


Issue	Solution	Whitelist
The AUT is in their private network	Use Tunnel	Tunnel Manager and Tunnel Server endpoints Allow QUIC / UDP on port 2345
AUT is behind a firewall (but publicly accessible)	There are 2 solutions, pick one of them: Whitelist our NAT Gateway public IPs Use Tunnel and whitelist the Tunnel Server hostnames.	NAT Gateway IP addresses Tunnel endpoints

Note:

In case your network still receives connection refused due to insufficient IP whitelist, you can reach out to the Katalon support team.

This guide shows an example of configuring network rules for TestCloud Tunnel in the context of AWS.

AWS environment context

Assuming you have a VPC that includes:

A Public Subnet that has access to an Internet Gateway for internet access (both ingress and egress).
A Private Subnet that only has access to internet through a NAT Gateway, that stay in the Public Subnet in #1.
The EC2 instance that will be used to deploy TestCloud Tunnel Client stay in the Private Subnet.
A strict network configuration with the least open Security Group(s) and NACL(s) openness, i.e. everything (port, ip addresses…) is blocked/denied unless specifically allowed. No Security Group and NACL is shared.

Solution

You need to whitelist these domains to use TestCloud Tunnel.

Security group configuration

Outbound Rules:

Type: UDP
Protocol: UDP
Port Range: 2345
Source: 34.236.12.143/32

Type: UDP
Protocol: UDP
Port Range: 2345
Source: 52.20.65.100/32

Type: HTTPS (TCP)
Protocol: TCP
Port Range: 443
Source: 44.214.101.94/32

NACL configuration

Inbound Rules:

Rule #: 101 (or next sequential)
Type: Custom TCP Rule
Protocol: TCP (6)
Port Range: 1024-65535
Source: 44.214.101.94/32
Allow/Deny: Allow

Rule #: 102 (or next sequential)
Type: Custom UDP Rule
Protocol: UDP (17)
Port Range: 1024-65535
Source: 34.236.12.143/32
Allow/Deny: Allow

Rule #: 103 (or next sequential)
Type: Custom UDP Rule
Protocol: UDP (17)
Port Range: 1024-65535
Source: 52.20.65.100/32
Allow/Deny: Allow

Outbound Rules:

Rule #: 101 (or next sequential)
Type: Custom TCP Rule
Protocol: TCP (6)
Port Range: 443
Destination: 44.214.101.94/32
Allow/Deny: Allow

Rule #: 102 (or next sequential)
Type: Custom UDP Rule
Protocol: UDP (17)
Port Range: 2345
Destination: 34.236.12.143/32
Allow/Deny: Allow

Rule #: 103 (or next sequential)
Type: Custom UDP Rule
Protocol: UDP (17)
Port Range: 2345
Destination: 52.20.65.100/32
Allow/Deny: Allow

Note:

Place these rules in your NACL in the correct order, typically after any rules that explicitly deny traffic, and before any default deny rules if applicable. This ensures that UDP traffic on port 2345 is permitted as intended.
When considering inbound rules, it is necessary to enable traffic from your services to return to the node. Since traffic entering the node arrives on a random port within the range of 1024 - 65535, these ports must be opened accordingly.