Skip to content

Firewalls (NGFW)

Use this section when the appliance is on a segment with outbound 443 allowed but the OpenVPN tunnel to connect.remotetesting.secureworks.com still won't establish (or comes up and immediately drops). That pattern means a next-generation firewall is inspecting the flow at Layer 7 and/or trying to decrypt it. See Connectivity troubleshooting for the full background.

The two changes every NGFW needs

Whatever the vendor, the fix is the same shape, and you almost always need both halves:

  1. TLS/SSL decryption exception: tell the firewall not to decrypt connect.remotetesting.secureworks.com:443. The session is OpenVPN, not HTTPS; a decryption proxy can't MITM it and will reset it.
  2. Application-control allow / override: the firewall's app engine will identify the flow as the openvpn application (or as unknown/non-SSL TCP on 443) and block it. Explicitly allow that application to the destination, or apply an application override so the flow is passed without L7 enforcement.

A decryption bypass alone is not enough

The most common half-fix is exempting the FQDN from SSL inspection and stopping there. App-ID / Application Control still runs on undecrypted traffic and will happily drop the openvpn app on its own. Do both.

Activation-mode platforms also need get.remotetesting.secureworks.com

Appliances deployed from a generic image (AWS, GCP, Azure, Hyper-V on Windows 11) register and activate over a second outbound connection: standard HTTPS on TCP/443 to get.remotetesting.secureworks.com. When you add the decryption exception and application rule for connect.remotetesting.secureworks.com, also allow this destination and exempt it from TLS/SSL decryption (the appliance does not trust an intercepting proxy's re-signed certificate). Its IP addresses are not guaranteed to stay constant, so allowlist it by FQDN, not by IP. Pre-registered appliances (vSphere, VMware Workstation, VirtualBox, Nutanix, Hyper-V Server) do not use this endpoint.

Order of operations

  1. Confirm it's an L7/inspection drop, not an L3 block. From a host on the same segment, a TCP/443 handshake to the headend that succeeds then resets within a second or two points at inspection, not an ACL. (See the first-line diagnostics.)
  2. Add the decryption exception for the headend FQDN.
  3. Add/adjust the application rule to allow OpenVPN (or override the app) to the headend FQDN on TCP/443.
  4. Re-test and confirm the tunnel comes up and stays up.

Vendor guides

Don't see your firewall?

The two changes above are vendor-neutral. Any NGFW exposes some form of decryption/SSL-inspection exception and application allow/override, apply both to connect.remotetesting.secureworks.com:443. Ask your Sophos engagement lead if you need help mapping them to a product not listed here.