Cisco Secure Firewall (FTD / FMC)

This guide covers the Cisco Secure Firewall-specific steps (FTD managed by FMC) needed to allow the RTA's outbound OpenVPN connection to connect.remotetesting.secureworks.com on TCP/443.

Note

For the full background (what the RTA connects to, why an ordinary "allow outbound 443" rule is not enough, and the two failure modes: TLS/SSL decryption and application control), see the firewall troubleshooting overview.

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.

Choose how to apply the fix

The fix is the same either way: a network/FQDN object, then either a Prefilter Fastpath rule (which also bypasses decryption) or a Do-Not-Decrypt exemption plus an Access Control Policy allow rule, followed by a deploy. Pick the interface you prefer.

• GUI (FMC)

  Click-through walkthrough in the Firepower Management Center web interface: FQDN object, Do-Not-Decrypt rule, Fastpath or allow rule, then deploy and verify.

• CLI (FMC REST API)

  The same fix as curl calls against the FMC REST API (FTD has no supported CLI for policy changes), ending with an API-driven deploy.

• AI assistant (LLM)

  A copy-paste prompt that has your AI assistant drive the FMC changes, pausing for your confirmation before anything is deployed.