Connectivity Troubleshooting

Almost every RTA deployment problem that isn't a boot/firmware issue comes down to one outbound connection not completing. This page explains that connection, why modern firewalls and NAC break it even when "443 is allowed", and how to fix it.

The one connection the appliance must make

Destination	connect.remotetesting.secureworks.com
IP addresses	3.33.194.251 and 15.197.255.2 (static — these do not change)
Port / protocol	TCP 443, carrying OpenVPN (not HTTPS)
Direction	Outbound only — the appliance initiates; nothing inbound is ever required
Why 443	It's the one outbound port nearly every network already permits

All RTA traffic to targets and back to Sophos rides inside this OpenVPN tunnel. If the tunnel is up, the appliance works. If it can't establish, nothing else matters — so this is always the first thing to check.

Why "we already allow outbound 443" is no longer enough

OpenVPN-over-443 was chosen years ago because a simple Layer-3 ACL allowing outbound TCP/443 was almost universal. That's still necessary — but on a modern next-generation firewall (NGFW) or NAC-controlled network it is no longer sufficient. Two distinct things now break the connection:

1. Layer-7 application inspection drops it

NGFWs don't just look at the port — they fingerprint the application in the flow (Palo Alto App-ID, Fortinet Application Control, Cisco AppID/Snort, Check Point Application Control, Sophos App Control). They recognize the flow as the openvpn application — or, because it isn't HTTP/TLS, bucket it as "unknown-tcp" / "non-SSL traffic on an SSL port" — and drop or reset it, even though the port-443 rule "allows" it.

2. TLS/SSL inspection can't decrypt it and resets it

Many of those same firewalls do TLS/SSL inspection ("deep inspection", "decryption", "HTTPS inspection") on port 443. They expect a real HTTPS handshake they can man-in-the-middle. OpenVPN on 443 is not HTTPS, so the decryption engine either fails the handshake or flags the session as evasive and tears it down. This is the failure that has been biting deployments most often.

The fix, in one sentence

Ask the firewall team to (a) exempt connect.remotetesting.secureworks.com from TLS/SSL decryption and (b) explicitly allow the OpenVPN application (or app-override the flow) to that destination on TCP/443. Both are needed — a decryption bypass alone still leaves App-ID free to drop it.

3. NAC blocks the appliance before it can egress at all

On networks with Network Access Control (Cisco ISE, Aruba ClearPass, FortiNAC, Forescout, etc.), the RTA is a headless Linux device with no 802.1X supplicant and no domain membership. NAC may quarantine it, drop it into a remediation/guest VLAN with no egress, or deny the port entirely — so the appliance never even reaches the firewall. The fix is to allowlist the appliance's MAC (MAB) into an authorized VLAN and skip posture/agent checks.

Symptom → likely cause

What you see	Likely cause	Where to look
Tunnel never comes up; appliance reachable on its segment	L7 app-control or TLS inspection on the firewall	Firewall guides
Connection starts then drops after a second or two	TLS/SSL decryption attempting to MITM the flow	Firewall guides
Appliance gets no IP / lands in a guest/quarantine VLAN	NAC denied or quarantined the device	NAC guides
Works from one switch port but not another	NAC policy differs per port / 802.1X vs MAB	NAC guides
Outbound 443 to other sites works, only the headend fails	App-ID/decryption is destination-specific to the headend FQDN	Firewall guides

First-line diagnostics

Run these from a host on the same network segment as the appliance (the appliance itself is headless and has no public IP):

# 1. DNS resolves?
nslookup connect.remotetesting.secureworks.com

# 2. Is TCP/443 reachable at all (L3 ACL open)?
nc -vz connect.remotetesting.secureworks.com 443

# 3. What does the firewall actually do to a 443 session to that host?
#    A successful TCP handshake that then resets within ~1-2s strongly implies
#    L7/TLS inspection is classifying and dropping it (not an L3 block).

If step 2 fails outright, it's a Layer-3 ACL / routing / egress problem (no NAT gateway, no default route, port blocked). If step 2 succeeds but the tunnel still won't establish, it's almost always L7 application inspection or TLS decryption — go to the firewall guides.

What to give your firewall / NAC administrator

Hand this to the network team — it's everything they need to allow the appliance:

Allow a security appliance to reach its management cloud.

• Destination: connect.remotetesting.secureworks.com on TCP 443. It resolves to two static IP addresses that do not change — 3.33.194.251 and 15.197.255.2 — so you can allowlist by FQDN or by those two IPs, whichever your policy model prefers.
• Do NOT TLS/SSL-decrypt this destination. The session is OpenVPN, not HTTPS; decryption will break it. Add a decryption/SSL-inspection exception.
• Allow the application. App-ID/Application-Control will see this as the openvpn application (or unknown TCP on 443). Explicitly allow it to the destination above, or apply an application override so the flow on TCP/443 to that FQDN is passed without L7 enforcement.
• Outbound only. No inbound rules are needed.
• (NAC only) The device is a headless Linux appliance — allowlist its MAC via MAC Authentication Bypass, place it in a VLAN with outbound internet, and exempt it from posture/agent requirements.

Per-vendor guides

• Firewalls (NGFW)

  TLS-inspection exceptions + L7 app-control allow/override for Palo Alto, FortiGate, Cisco Secure Firewall, Check Point, and Sophos Firewall.

• Network Access Control (NAC)

  MAB allowlisting, VLAN authorization, and posture bypass for Cisco ISE and Aruba ClearPass.

Per-deployment issues live with each platform

Problems specific to one hypervisor/cloud (boot mode, instance type, disk sizing, console quirks) are covered in that platform's own guide. This section is for the network-path problems that are the same regardless of where the appliance runs.