Sophos Firewall: CLI (XML API)¶

SFOS does not expose policy configuration through the appliance's SSH console (the device console is for diagnostics and system settings). The supported non-GUI path is the XML API: you POST an XML payload to the web admin service with curl, and each request that returns 200 takes effect immediately, exactly as if you had clicked Save in the web admin console.

This page applies the same changes as the GUI (web admin) guide: an FQDN host for the RTA endpoint, an SSL/TLS inspection exclusion, and a dedicated firewall rule that carries no application filter policy.

Before you start

Review the Sophos Firewall overview. You need an SFOS administrator account and a workstation that can reach the firewall's web admin port (default 4444).

1. Enable API access¶

API access is disabled by default and is enabled in the web admin console (a one-time step):

Go to Backup and firmware > API.
Select API configuration.
For Allowed IP address, enter the IP address of the workstation you will send requests from.
Click Apply.

2. How requests are sent¶

Every request is an XML document POSTed to https://<FIREWALL_HOST>:4444/webconsole/APIController in a reqxml form field. The document wraps a <Login> block and one or more operations:

<Request>
  <Login>
    <Username><ADMIN_USER></Username>
    <Password><ADMIN_PASSWORD></Password>
  </Login>
  <Set operation="add">
    <!-- entity payload goes here -->
  </Set>
</Request>

Save each payload below to a file and send it with:

curl -k "https://<FIREWALL_HOST>:4444/webconsole/APIController" -F "reqxml=<payload.xml"

(-k accepts the firewall's self-signed web admin certificate; drop it if you have installed a trusted certificate.)

Warning

The payload files contain the administrator password in clear text. Keep them out of version control and shared directories, and delete them once the configuration is applied.

3. Create the FQDN host¶

All subsequent rules reference a single named object for the RTA endpoint:

<Request>
  <Login>
    <Username><ADMIN_USER></Username>
    <Password><ADMIN_PASSWORD></Password>
  </Login>
  <Set operation="add">
    <FQDNHost>
      <Name>rta-connect-endpoint</Name>
      <FQDN>connect.remotetesting.secureworks.com</FQDN>
    </FQDNHost>
  </Set>
</Request>

The endpoint also has two static IPs, 3.33.194.251 and 15.197.255.2, if you prefer IP-based objects (IPHost entities with HostType IP).

4. Add the SSL/TLS inspection exclusion¶

Create a "Don't decrypt" SSL/TLS inspection rule at the top of the list so it matches before any existing decrypt rules that cover outbound traffic:

<Request>
  <Login>
    <Username><ADMIN_USER></Username>
    <Password><ADMIN_PASSWORD></Password>
  </Login>
  <Set operation="add">
    <SSLTLSInspectionRule>
      <Name>RTA do not decrypt</Name>
      <Enable>Yes</Enable>
      <Position>Top</Position>
      <DecryptAction>Do not decrypt</DecryptAction>
      <DestinationNetworks>
        <Network>rta-connect-endpoint</Network>
      </DestinationNetworks>
      <Services>
        <Service>HTTPS</Service>
      </Services>
    </SSLTLSInspectionRule>
  </Set>
</Request>

Leaving source zones, networks, and users unset applies the rule to any source, matching the GUI guide's recommendation.

Note

The API spells the action Do not decrypt; the web admin console shows the same action as Don't decrypt.

5. Create the firewall rule¶

If the RTA's subnet has no host object yet, create one first (skip this payload if a suitable object already exists):

<Request>
  <Login>
    <Username><ADMIN_USER></Username>
    <Password><ADMIN_PASSWORD></Password>
  </Login>
  <Set operation="add">
    <IPHost>
      <Name>rta-subnet</Name>
      <IPFamily>IPv4</IPFamily>
      <HostType>Network</HostType>
      <IPAddress><RTA_SUBNET_ADDRESS></IPAddress>
      <Subnet><RTA_SUBNET_MASK></Subnet>
    </IPHost>
  </Set>
</Request>

Then create a dedicated rule for the RTA traffic at the top of the rule list:

<Request>
  <Login>
    <Username><ADMIN_USER></Username>
    <Password><ADMIN_PASSWORD></Password>
  </Login>
  <Set operation="add">
    <FirewallRule>
      <Name>RTA outbound VPN</Name>
      <Status>Enable</Status>
      <IPFamily>IPv4</IPFamily>
      <Position>top</Position>
      <PolicyType>Network</PolicyType>
      <NetworkPolicy>
        <Action>Accept</Action>
        <SourceZones>
          <Zone><RTA_ZONE></Zone>
        </SourceZones>
        <SourceNetworks>
          <Network>rta-subnet</Network>
        </SourceNetworks>
        <DestinationZones>
          <Zone>WAN</Zone>
        </DestinationZones>
        <DestinationNetworks>
          <Network>rta-connect-endpoint</Network>
        </DestinationNetworks>
        <Services>
          <Service>HTTPS</Service>
        </Services>
      </NetworkPolicy>
    </FirewallRule>
  </Set>
</Request>

Set <RTA_ZONE> to the zone containing the RTA (e.g., LAN). The ApplicationControl field defaults to no policy when omitted, so this rule carries Application filter: None; that is the GUI guide's section 3 alternative, and no separate app-control payload is needed.

Note

Per-destination application filter exceptions (GUI guide, section 3) are managed in the web admin console; the API configures application filter policies by category and application, not by destination host. The dedicated rule above achieves the same outcome for the RTA traffic.

6. Apply and verify¶

Each request that returns status 200 is already live; there is no separate deploy or policy-install step. To read back an object, replace the <Set> block with a <Get>:

<Request>
  <Login>
    <Username><ADMIN_USER></Username>
    <Password><ADMIN_PASSWORD></Password>
  </Login>
  <Get>
    <FQDNHost></FQDNHost>
  </Get>
</Request>

Then, from a host on the same network segment as the RTA, confirm that TCP/443 is reachable:

nc -vz connect.remotetesting.secureworks.com 443

A successful connection prints something like:

Connection to connect.remotetesting.secureworks.com port 443 [tcp/https] succeeded!

Then check the RTA's own status (via the deployment portal or local console) to confirm the OpenVPN tunnel comes up and remains stable.

Warning

A successful TCP connection (nc) only confirms the port is reachable. The OpenVPN session layer also requires that inspection is not intercepting the traffic; watch the RTA console for tunnel-establishment output.

If connectivity still fails, open the web admin Log viewer, filter for the RTA's source IP and destination connect.remotetesting.secureworks.com, and look for SSL/TLS inspection or Application control drop entries: these point to whichever exclusion was not applied correctly.