Forescout: AI assistant (LLM)

Paste this into your AI assistant to have it help configure Forescout so the RTA is admitted onto the network. It still pauses for your confirmation and for anything your version does differently.

Configuration prompt

You are helping me configure Forescout (the eyeSight platform, formerly
CounterACT) so the Sophos Remote Testing Appliance (RTA) is admitted onto the
network and can reach its endpoint. Work through the steps in order and show me
the pending change before I apply anything.

CONTEXT:
- This is a Network Access Control (NAC) problem, not a TLS-decryption problem.
  Forescout is denying the appliance network admission; the job is to exempt it
  from blocking and quarantine enforcement, not to inspect its traffic.
- The RTA is a headless Linux appliance: no 802.1X supplicant, no domain
  membership, and no NAC agent (it does not run SecureConnector). Forescout sees
  an unknown, unclassified, or non-compliant device and a policy applies a
  restrict action against it (Switch Block, Assign to VLAN into a quarantine
  segment, or Virtual Firewall), so it never gets usable network access.
- Once admitted, the appliance's segment must allow outbound TCP/443 to
  connect.remotetesting.secureworks.com, which resolves to the static IPs
  3.33.194.251 and 15.197.255.2. Some appliances also register over HTTPS to
  get.remotetesting.secureworks.com; allow that one by FQDN (its IPs are not
  static), never by a hardcoded IP.

STEPS:
1. I have the appliance MAC address as <RTA_MAC>, from the hypervisor / cloud
   console NIC settings, the DHCP lease table, or the switch MAC table. (On
   Hyper-V, MAC-address spoofing is enabled on the appliance NIC, so confirm
   <RTA_MAC> is the address the switch actually learns via the switch MAC table
   or DHCP lease.)
2. Add the appliance to a dedicated group. In the Forescout Console's Home view,
   find the endpoint in the Detections pane by <RTA_MAC> or <RTA_IP>, select it,
   and manually apply the Add to Group action. In the group selector choose New
   Group and name it RTA-Appliances. If the appliance has not been detected yet,
   add its endpoint record to the Console manually first (Manually Add an
   Endpoint in the Administration Guide). Do not use the built-in Ignored IPs
   group unless I explicitly ask for it; prefer the dedicated group.
3. Exempt the group from blocking and quarantine policies. In the Policy view,
   identify every active policy whose rules apply a restrict action (Switch
   Block, Assign to VLAN, Virtual Firewall, or similar) to unknown,
   unclassified, or non-compliant devices. For each one, either add the
   RTA-Appliances group (or the appliance IP) as an exception to the policy
   scope, or add a rule that matches RTA-Appliances members with no restrict
   action, ordered above the blocking rule. List the policies you propose to
   change before touching any of them.
4. Bypass compliance and classification checks. The RTA runs no SecureConnector
   agent, is not domain-joined, and is a hardened Linux appliance, so it can
   never pass agent, antivirus, or patch-level compliance checks. Add the same
   RTA-Appliances exemption to compliance policies that restrict non-compliant
   endpoints, and to classification policies that quarantine unclassified or
   unmanaged devices (the appliance classifies as a generic Linux host). If this
   deployment enforces pre-connect 802.1X through the Forescout RADIUS plugin,
   an endpoint with no supplicant is evaluated by MAC Authentication Bypass
   (MAB), so also make sure the MAB handling authorizes <RTA_MAC> onto a segment
   with the outbound access described in CONTEXT.
5. Clear applied actions and refresh the connection. Policy exemptions stop new
   enforcement, but an action already applied to the endpoint stays in force
   until cancelled. In the Home view, check which actions are applied to the
   endpoint and cancel any active restrict action (Cancel Actions). After I
   confirm, apply the policy changes, then have me bounce the appliance's switch
   port (or power-cycle the VM's network interface) so it requests a fresh DHCP
   lease.

VERIFY:
6. In the Console, confirm the endpoint is a member of RTA-Appliances and has no
   restrict actions applied.
7. Confirm the appliance receives a DHCP lease in the expected subnet, not the
   quarantine segment.
8. From a host on that segment (or the appliance once it has a lease), run:
   nc -vz connect.remotetesting.secureworks.com 443
   A success confirms the appliance can reach its endpoint; the tunnel should
   come up within a minute or two of the network admitting it.

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.