Sophos Firewall: AI assistant (LLM)

Paste this into your AI assistant to have it help configure Sophos Firewall (SFOS) to allow the RTA's outbound connection. It still pauses for your confirmation and for anything your version does differently.

Configuration prompt

You are helping me configure my Sophos Firewall so the Sophos Remote Testing
Appliance (RTA) can reach its endpoint. Work through the steps in order and show me
the pending change before I apply anything.

CONTEXT:
- The RTA makes one outbound OpenVPN connection over TCP/443 to
  connect.remotetesting.secureworks.com, which resolves to the static IPs
  3.33.194.251 and 15.197.255.2.
- A plain "allow 443" is not enough on SFOS: SSL/TLS inspection intercepts the
  OpenVPN session on TCP/443 and resets it, and Synchronized App Control may
  classify the flow (OpenVPN / Proxy and tunnel / an unknown non-HTTPS
  application) and drop it under a blocking application-filter policy.
- Some appliances also register over HTTPS to get.remotetesting.secureworks.com.
  Allow that destination by FQDN (its IPs are not static), and exempt it from
  inspection too.

STEPS:
1. Create an FQDN host. Go to Hosts and services > FQDN host > Add. Set Name to
   rta-connect-endpoint and FQDN to connect.remotetesting.secureworks.com, then
   Save. Every later rule references this object.
2. Add a TLS/SSL inspection exclusion so inspection does not intercept this
   destination (recommended path). Go to Rules and policies > SSL/TLS inspection
   rules > Add rule, and position it above any existing decrypt rules that cover
   outbound traffic. Set Action to Don't decrypt, Destination host/network to the
   rta-connect-endpoint FQDN host, and Destination port to HTTPS (443); leave the
   other conditions at their defaults, then Save. (If my SFOS version does not
   present a Don't decrypt action in the rule editor, instead open Exclusions on
   the SSL/TLS inspection rules page and add connect.remotetesting.secureworks.com
   to the Local TLS exclusion list.)
3. Handle application control. Go to Rules and policies > Firewall rules, open the
   rule that handles outbound traffic from the RTA's network segment, and under
   Security features check the Application filter policy. If it is None, no
   app-control blocking is active and I can skip to step 4. If a policy is applied,
   open it under Protect > Application filter (some versions: Web > Application
   filter), add an exception with the destination set to the rta-connect-endpoint
   FQDN host and the action set to Allow, then Save. Alternatively, create a
   dedicated firewall rule (step 4) that covers only the RTA traffic and sets
   Application filter to None, placed above the general outbound rule.
4. Make sure a firewall rule permits the traffic. If no outbound rule covers the
   RTA yet, go to Rules and policies > Firewall rules > Add firewall rule > New
   firewall rule. Set Rule name to RTA outbound VPN, Source zone to <RTA_ZONE>
   (e.g. LAN), Source networks to <RTA_SUBNET> (the RTA's subnet or host object),
   Destination zone to WAN, Destination networks to rta-connect-endpoint, Services
   to HTTPS (TCP/443), and Action to Accept. Set SSL/TLS inspection to None (or
   rely on the Don't decrypt rule from step 2) and Application filter to None (or
   the exception from step 3), then Save.
5. If my appliance is an activation-mode platform, also allow
   get.remotetesting.secureworks.com by FQDN (never by a hardcoded IP) and add it
   to the same Don't decrypt exclusion.
6. SFOS applies changes on save; there is no separate deploy or policy-install
   step. Show me the pending configuration first, and apply it only after I
   confirm.

VERIFY:
- From a host on the RTA's network segment, run:
  nc -vz connect.remotetesting.secureworks.com 443
  A success looks like: Connection to connect.remotetesting.secureworks.com port
  443 [tcp/https] succeeded!
- A successful nc only confirms the port is reachable, so then check the RTA's own
  status (deployment portal or local console) to confirm the OpenVPN tunnel comes
  up and stays stable.
- If it still fails, open Log viewer, filter on the RTA's source IP and
  destination connect.remotetesting.secureworks.com, and look for SSL/TLS
  inspection or Application control drop entries; those point to whichever
  exclusion was not applied correctly.

RULES YOU MUST FOLLOW:
- These steps are authoritative. If a menu, command, or option does not match what
  is written here (versions differ), STOP and show me what you actually see. Do not
  guess at equivalent settings or invent CLI syntax.
- Make the narrowest change that allows this one destination. Do not broaden an
  existing rule to "any", and do not disable, bypass, or pause the firewall, TLS/SSL
  decryption, or threat inspection globally to make it work.
- Allowlist connect.remotetesting.secureworks.com. Its two IPs (3.33.194.251 and
  15.197.255.2) are static, but get.remotetesting.secureworks.com (used on some
  platforms) is not, so allow that one BY FQDN, never by a hardcoded IP.
- Do not apply, commit, or deploy the change until I confirm. Show me the pending
  configuration first.
- Change only what these steps describe. Do not alter unrelated rules, objects, or
  policy, and do not touch anything outside allowing this destination.