Setting Up and Testing Sophos Firewall Application Control

Application Control detects application traffic that cannot be meaningfully distinguished via ports alone. For example, a Sophos firewall can specifically allow or block remote control tools, tunneling applications, streaming or cloud storage. The hit is logged via the corresponding firewall rule; an application filter does not have its own action Log.

The core process is straightforward: create the filter under Applications > Application filter, assign it under Rules and policies > Firewall rules to the rule that actually matches, and then use a real client to verify the Rule ID, application, and action. A saved filter policy alone does not affect traffic.

Define the prerequisites and objective

Application Control belongs to the Web Protection Subscription. Check the license status under Administration > Licensing. Before configuring Application Control, determine:

• the affected user or network area and its IPv4/IPv6 paths;
• the application or group that should be initially monitored or blocked;
• the firewall rule that is currently processing this traffic;
• a test client, a reproducible test request, and the expected result;
• the currently assigned Application Filter, rule position, and existing NAT assignment as the baseline for rollback.

Check signature updates under Backup & firmware > Pattern updates. They run automatically by default; Update pattern now updates all pattern definitions except the firmware patterns for AP and RED when needed. The status values Ready to install, Downloading, Success, and Failed help narrow down problems. Application signatures remain available without an active IPS license, whereas IPS signatures require both a suitable license and enabled IPS. Sophos documents an exception for air-gap installations: IPS and application signatures are updated even when IPS protection is turned off.

For the test rule, turn on Log firewall traffic. Logging applies to the firewall rule, not the Application Filter. If you only want to observe traffic, use a permissive filter and evaluate the detected applications before setting individual entries to Deny.

If the actual goal is prioritization or bandwidth limiting, supplement the filter with Configure Application Traffic Shaping on Sophos Firewall. Application-based SD-WAN routes use an Application Object instead; the process is covered in Set Up a Sophos Firewall SD-WAN Route with Gateway Failover.

Plan and create application filters

Under Applications > Application list you can see whether Sophos has its own signature and which category or risk it is currently assigned to. For the Name filter, contains, is, is not and does not contain are available. A catalog hit does not prove that the application is detected on your network; the client test later provides that evidence.

A fixed selection of individual applications is easily predictable. Criteria such as Risk, Category or the Classification available only for cloud applications, on the other hand, remain dynamic: new or reclassified signatures can also match in the future. Such rules need a documented owner and a review after pattern or classification changes.

The full path for a policy and its rule is:

Applications > Application filter > Add
Applications > Application filter > Edit policy > Add

1. Assign a unique name under Add, for example Block_File_Transfer_Pilot.
2. Choose a template. For targeted blocking, Allow All is a clear starting point; do not assume that every empty new policy automatically behaves this way.
3. Save the policy, open it again and create a filter rule with Add.
4. Either use Select Individual Application or use Select All to narrow down the hits via Application, Category, Risk, Characteristics, Technology, Classification or Smart Filter.
5. Set Action to Allow or Deny.
6. For example, under Schedule, select All the time or assign a suitable schedule.
7. First save the filter rule and then the policy.

SFOS supplies the templates Allow All, Deny All, Block filter avoidance apps, Block generally unwanted apps, Block high risk (Risk Level 4 and 5) apps, Block peer to peer (P2P) networking apps and Block very high risk (Risk Level 5) apps, among others. A template is a starting point, not a ready-made standard. In particular, compare risk- and category-based rules with the applications your network requires before assigning them broadly.

Time-dependent rules require a suitable schedule. How to create it and check it against firewall time and fallback rules is described in Setting up Sophos Firewall Schedules for Rules and Policies.

Example: Block browser-based file transfers

The official example leaves other file transfer applications untouched and limits only browser-based transfers:

1. Create the policy Block_File_Transfer_Pilot from Allow All and open it again.
2. Create a rule with Add > Select All.
3. Choose Category: File Transfer, Characteristics: Transfer files and Technology: Browser Based.
4. Set Action: Deny and Schedule: All the time.
5. Save the filter rule and then the policy.

This selection can also affect legitimate upload, collaboration, or backup processes. The pilot client should therefore test both a transfer to be blocked and an explicitly allowed business service from the same scope.

Assign filters to the correct firewall rule

Application Control only works in a firewall rule. For a new rule, the current path is:

Rules and policies > Firewall rules
> IPv4 or IPv6
> Add firewall rule
> New firewall rule
> Other security features
> Identify and control applications (App control)

For an existing rule, open Other security features directly and select the prepared application filter there. Log firewall traffic remains active for pilot and acceptance.

The rule must actually match the test client’s Source Zone, Source Network, Destination Zone, Destination Network, Services, and, where applicable, Match known users criteria. Firewall rules are evaluated from top to bottom; the first match ends the search. A more general rule above is therefore a more common cause than the Application Filter itself.

With a new Internet rule, the NAT path must also be correct. Sophos examples can generate a MASQ rule with Create linked NAT rule. In an existing environment, do not create a duplicate NAT rule preemptively; instead, check the effective SNAT/MASQ rule and note its NAT Rule ID.

IPv4 and IPv6 have their own rule paths. If the client uses both protocols, both are tested or the pilot is deliberately limited to one. The rule basics are explained in Understanding and securely configuring Sophos firewall rules.

Prove the effect with live connections and Log Viewer

A robust test answers three separate questions: Which rule processes the flow, which application does SFOS detect, and which action is executed?

1. Note the test client, source IP, user, time and destination.
2. Optionally, run Reset data transfer count in the pilot rule’s options so that new traffic can be attributed more easily.
3. Start the test connection and check the open session under Current activities > Live connections.
4. Compare the application, Source IP, username, interfaces, source/destination ports, Firewall Rule ID and NAT Rule ID with the planned path.
5. Open the Log viewer in the upper right corner of the web admin and filter it by source IP, user, destination, Rule ID and application.
6. Run an expected block test and an allowed control test from the same scope.

A denied Application Filter hit appears as Content Filtering > Application > Denied. Allowed, detected traffic appears in the firewall log under Firewall > Firewall Rule > Allowed. For acceptance testing, document at least the Firewall Rule ID, Application Filter, application, category, risk, action, user, source, and destination.

Firewall sessions often only appear on the Connection Destroy event when SFOS closes the connection. A still open browser or streaming session can therefore already be visible under Live connections, although its final firewall log entry is missing. SSL/TLS connections are logged after the handshake completes and again when the connection closes.

Under Reports > Dashboards > Traffic dashboard > Allowed policies, you can also review the data transferred through allowing rules. However, the report does not replace the specific Rule ID and application test. Local reports are unavailable on XGS 87/87w and XGS 88/88w; use the log and connection checks on these models.

For Syslog or SIEM, field names differ by output format. The Central Reporting Format uses fields such as fw_rule_id, app_filter_policy_id, app_name, app_category, app_risk, app_resolved_by, qualifier, and status. In the Device Standard Format (Legacy), the corresponding fields include application_filter_policy, application_name, application_category, application_risk, and appresolvedby. app_resolved_by or appresolvedby distinguishes between values such as Signature, Proxy, and Synchronized Application Control (EAC).

Technical Application Filter and DPI events are written to ips.log; sig_upgrade.log and sigmigration.log help diagnose signature updates. For details about which services write to which logs, see Sophos Firewall Troubleshooting: Services and Logs. Packet capture can confirm IPs, ports, interfaces, and the packet path, but does not prove application classification. The combined diagnostic path is covered in Testing Sophos Firewall Rules with Log Viewer, Policy Test and Packet Capture.

Classify HTTPS, QUIC and Web exceptions

SFOS recognizes many signature-based applications even without full decryption. However, URL-based micro apps such as file transfers to Dropbox or Gmail require the decrypted URL in encrypted traffic. In the DPI path, a suitable rule is required for this under Rules and policies > SSL/TLS inspection rules. Scan HTTP and decrypted HTTPS enables malware scanning for already decrypted HTTPS, but does not turn on the decryption itself.

In the web proxy path, Decrypt HTTPS during web proxy filtering handles the decryption. An existing web policy does not prove that HTTPS is decrypted, nor that the same DPI rule applies. The controlled rollout is available in Introducing Sophos Firewall TLS Inspection correctly.

Block QUIC protocol discards outgoing UDP packets to ports 80 and 443 within the scope of the firewall rule so that clients fall back to a testable TCP path. SFOS selects the option by default when a Web policy is selected or Scan HTTP and decrypted HTTPS is activated. The web filter cannot scan QUIC, but this does not mean that QUIC bypasses every other firewall control. Block QUIC and HTTP/3 Correctly on Sophos Firewall describes the positive and negative tests.

If detection is unexpected, also check Web > Exceptions. A Web exception can skip decryption, malware/content scanning and policy checks and is valid in the DPI as well as in the proxy path depending on the selection. A wide exception can therefore remove the expected application context.

A firewall log entry with Allowed does not automatically prove that the user was permitted access through the web proxy: the firewall may pass the connection to the proxy before the Web filter logs it as Blocked. In such cases, review the firewall and web logs together.

Classify cloud applications

Under Applications > Cloud applications SFOS shows only allowed traffic and only applications for which traffic is available. The view can be filtered by date, Classification, Category and transferred bytes; Expand opens details. A missing entry therefore does not rule out a blocked attempt.

New cloud applications initially carry the classification new. After review, use Classify to assign sanctioned, unsanctioned, or tolerated. The new classification applies to new traffic and does not allow or block anything on its own. Only an Application Filter that uses this criterion and is assigned to a matching firewall rule implements the desired action.

Basic usage and byte data require firewall logging. Upload/download counters and file type details require HTTPS decryption; according to Sophos, a web policy not equal to None additionally improves accuracy and depth of detail. Some applications use their own transmission mechanisms, so that individual detail fields can still remain empty.

A prepared bandwidth policy can be assigned to a detected cloud application via Traffic shaping. This assignment does not replace the Application Filter or the firewall rule.

Special cases: online storage and Facebook videos

The official Google Drive example combines the Application Filter Block_GoogleDrive with the Web Policy BlockPersonalStorage. The filter is created from Allow All, searches for google drive with Smart Filter, and sets the selected applications to Deny and All the time. In Web > Policies, clear All web traffic for the narrow storage rule, search for personal via Add new item > Web category, and set the appropriate categories to Block HTTP and Block HTTPS. Both policies must be assigned to the same firewall rule that actually matches. Configure Web Protection on Sophos Firewall explains the policy mechanics.

For Facebook videos, use Select Individual Application in the Application Filter and select the matches for Facebook videos. For a custom web category, Sophos currently lists facebook.com/watch, facebook.com/reel, gateway.facebook.com, facebook.com/ajax, and facebook.com/stories, along with the keywords watch, reel, gateway, ajax, and videos. Treat these values as a version-specific starting point and review them before use because broad keywords may match other paths. Add this custom category to a blocking rule in the Web policy; the current Facebook procedure does not specify the action as explicitly as the storage example.

The Sophos example uses the web proxy, decrypts HTTPS, and blocks QUIC. Clients must therefore trust the Sophos Firewall CA. Do not switch an existing DPI environment solely for this special case. The proxy procedure does not prove equivalent Facebook-video blocking through DPI; validate a separate DPI design with Sophos Support and client tests before relying on it. See Create Web Categories on Sophos Firewall for custom categories and Distribute the Sophos Firewall CA Certificate for HTTPS Scanning for CA distribution.

Use Synchronized Application Control in a targeted manner

Synchronized Application Control complements network detection with data from managed Sophos endpoints. In addition to the Web Protection Subscription, it requires Security Heartbeat, a Network Protection Subscription, a Sophos Fusion (formerly Sophos Central) account and a managed endpoint with a trial or full license.

The registration takes place at:

System > Sophos Central > Sophos Central registration > Register

After successful registration, SFOS automatically activates Security Heartbeat and Synchronized Application Control. If Security Heartbeat is turned off, Synchronized Application Control is also disabled; this is therefore not a narrowly scoped rollback for a single application.

For first-time use, after registration, check in Sophos Fusion (formerly Sophos Central) that Synchronized Application Control is turned on and enable it if necessary. The domain created on the firewall must match the domain selected on the endpoint.

Under Applications > Synchronized Application Control, search by name, path, category, or endpoint and expand an entry to view its occurrences. Sophos supports up to 15,000 applications. Since SFOS 20.0 MR1, SFOS stores only the five most recent occurrences of each application per endpoint.

When migrating to SFOS 21.0 or later, SFOS enables automated cleanup only if Synchronized Application Control (SAC) is turned on. The default retention period is twelve months. If a custom period was previously configured, it is retained. If SAC is turned off, both SAC and automated cleanup remain turned off. Cleanup also removes individually added applications from Application Filters. When migrating to SFOS 20.0 MR1 or later, SFOS deletes older occurrences; if automated cleanup fails because of insufficient storage space, Sophos directs you to Support.

New identifies new entries, Mapped identifies automatically assigned applications, and Customized identifies manually edited entries. The following actions are available under Manage > More options:

• Customize: assign a clear name and an appropriate category, then select Apply;
• Acknowledge: change the label from New to Customized without changing the name or category;
• Hide and Show: hide an entry or show it again;
• Delete: delete the application and remove it from any Application Filters that use it.

After Customize or Acknowledge, add the reviewed application to a new or existing Application Filter. Assign this filter to the firewall rule that actually matches. Then run a reproducible test flow and verify the expected Rule ID, application name, and action in the Log Viewer. Only after this pilot should you add the reviewed application to a production Allow or Deny filter rule.

A deleted entry reappears when an endpoint reports it again. Before Delete, therefore, check which filters use the entry; then run a new test flow and verify the expected Rule ID. For generative AI, Detect and control Generative AI with Sophos Firewall provides a dedicated pilot sequence.

Check selection and example configuration in full

Catalog, templates and specific blocks

In the catalog, open Filter next to the relevant field; except for Name, choose a value from the list. Smart Filter searches names and descriptions. Any existing Application Filter Policy, including a custom one, can serve as a template. Check its rules and schedules before copying it.

Categories describe different purposes, not automatically a security rating:

• File transfer: transfers and uploads; Download applications: downloads, file sharing, storage and accelerators; Storage and backup: file storage, collaboration and password storage.
• Gaming: games and contests; Streaming media: audio, video and live broadcasts; Social networking: social networks; E-commerce: commerce applications.
• Instant messenger: chat; VoIP: IP telephony; Conferencing: virtual meetings; Web mail: browser email; Desktop mail: email clients.
• General internet: including news, search, browsers, shopping and workspaces; General business: including hosting, collaboration, accounting and backup; Mobile applications: mobile OS apps; Software update: system and application updates.
• Infrastructure: for example DNS, DHCP, SMTP, MySQL, QUIC and TLS on other ports; Network services: for example routing, boot, QoS and FTPS; P2P: peer-to-peer file sharing; Proxy and tunnel: proxies and VPNs; Remote access: remote access and remote desktop; Industrial control system: building, telecontrol and process communications.
• SyncAppCtl discovered: unknown applications discovered through SAC; Sophos applications: Sophos applications mapped by SAC; System applications: system services mapped by SAC, such as Windows or Linux services; Generative AI: AI applications and services.

Allow All permits and Deny All drops all applications. Block filter avoidance apps blocks tunnels, proxies and applications that bypass policies; Block generally unwanted apps includes file transfer, proxy/tunnel, risk-prone and P2P applications. P2P can distribute malware; blocking it makes sense unless there is an approved business requirement. The high-risk templates target Risk Levels 4/5 or only 5.

For an individual block, filter Facebook Games under Select Individual Application > Name, select it and save with Action: Deny, Schedule: All the time. The same procedure works for WhatsApp, Skype, LinkedIn or Internet Download Manager. For groups, use Category: Generative AI or Category: P2P. The UltraVPN example uses Category: Proxy and Tunnel and PPTP Protocol; this does not promise detection of every VPN tunnel.

For Block_High_Risk_Apps, after saving and reopening, choose Add > Select All > Risk, select High and Very High, confirm with OK and set Deny and All the time. Save the rule and policy and assign it to firewall rule Block_High_Risk_Apps_Rule. New matching signatures are included after pattern updates. Older examples describe a permissive empty policy and the Advanced section; for SFOS 22/23 explicitly use Allow All and check the assignment under Other security features rather than transferring those old details unchecked.

Shared firewall and web settings

The file-transfer and storage examples use an Accept firewall rule from LAN to WAN, Log firewall traffic, Rule group: None, During scheduled time: All the time and Rule position: Top. Source networks, destination networks and services are Any; the high-risk example even uses Any for both zones. These broad values are not a pilot recommendation: limit the source to the test client, adapt zones and services to the real path, and deliberately place the rule above the otherwise matching rule. Without Match known users, the rule applies to matching network traffic regardless of user; with it, select for example Marketing for storage or Open Group for file transfer under User or groups > Add new item. Replace those group names with your approved group; the test log must show the correct user mapping.

If needed, Create linked NAT rule creates a rule with Translated source (SNAT): MASQ; the example also places it at Top. Save the NAT rule first, then the firewall rule. In existing networks, the previously verified NAT assignment remains decisive.

For storage, enable the web rule under Status after setting Block HTTP/Block HTTPS, then save. In the proxy path, also block QUIC, enable Scan HTTP and decrypted HTTPS and Decrypt HTTPS during web proxy filtering, and distribute the CA before testing.

For Facebook, save the custom category under Web > Categories > Add with Classification: Unproductive and the Domain and Keyword values listed above. Under Web > Policies > Add policy > Add rule, remove All web traffic from Activities, select the category through Add new item > Web category, choose Apply selected items, check the blocking HTTP/HTTPS actions and enabled status, then Save and, where applicable, Skip this step. Save all Facebook videos matches in the Application Filter with Deny and All the time. The complete proxy example additionally enables Use web proxy instead of DPI engine, Scan HTTP and decrypted HTTPS, Scan FTP for malware, Decrypt HTTPS during web proxy filtering and Block QUIC protocol. FTP scanning is an additional protection option, not proof of the video block. A similarly named option alone does not establish the DPI path as tested and equivalent; if blocking fails, use the diagnostic and support path described above.

Complete cloud and SAC operations

After Classify, confirm with Apply; after Traffic shaping, select an existing policy and Save. For example, review unsanctioned social-networking applications for a specified period or limit video streaming.

Unknown SAC applications initially enter SyncAppCtl discovered; known ones are categorized automatically. Narrow the search scope, for example to System applications. After Hide, entries appear only under Hidden applications; restore them with Show. Customize remains available later and sets the label to Customized.

Clean up application database requires registration with Sophos Fusion/Sophos Central. Following a daily check, SFOS deletes old applications in batches of 100 every five minutes, including individually added entries in policies. Check their use before changing the period; shortening it is not a risk-free storage fix. Without a valid Web Protection Subscription, SAC can be configured but cannot be used.

Automating Application Control via the XML API

The XML references for SFOS 22/23 describe various objects with similar-sounding names. A cloud classification is neither a filter rule nor the global Device Console switch. Before a write call, back up the existing state and the policies that use it. Securing Sophos Firewall XML API access explains access, response evaluation, and safe retries. Confirm the complete operation wrapper and required fields before using the following object structures in a write request.

Single and multiple cloud classifications

ApplicationClassificationAssignment updates exactly one assignment: The two required fields Application and Classification are strings. The reference example specifies Facebook Website and New. This is not a complete catalog of permitted classifications; UI values and capitalization are not automatically treated as API enum values.

ApplicationClassificationBatchAssignment, by contrast, uses ClassAssignmentList with repeated ClassAssignment objects. Each object contains the lowercase fields app and class, not Application and Classification. The documented structure looks like this, for example:

<ApplicationClassificationBatchAssignment>
  <ClassAssignmentList>
    <ClassAssignment>
      <app>iCloud</app>
      <class>New</class>
    </ClassAssignment>
    <ClassAssignment>
      <app>iPlay Website</app>
      <class>New</class>
    </ClassAssignment>
  </ClassAssignmentList>
</ApplicationClassificationBatchAssignment>

The names are reference examples and are replaced with applications that actually exist. The parameter table describes ClassAssignmentList as an optional array of objects with multiple values. This implies neither a meaningful empty batch operation nor a guarantee of atomic processing, rollback, or a status per entry. After a change, read back each requested assignment separately and use new traffic to check the effect of a Classification filter. For the batch operation, the reference lists 200 with Operation Successful. and 500 with Operation Fail.; for the single operation, it lists 200 and 500 with the unresolved symbols Message.AppClassificationUpdateSuccess and Message.AppClassificationUpdateFail, respectively.

Filter policy: Template or custom rules

For ApplicationFilterPolicy, Template takes precedence: If it is supplied, the documented contract ignores DefaultAction and RuleList. A request containing a Template and a custom Deny rule is therefore not a reliable combination of the two variants. Without a Template, the reference describes DefaultAction with Allow or Deny and RuleList/Rule for custom rules. The maximum length of one character stated alongside these values contradicts these words; no abbreviated single-character value is inferred from this. The XML example uses AllowAll, while the UI displays Allow All. Do not use the UI text as an API token without verifying it.

Within Rule are SelectAllRule, selection containers, and Action and Schedule. The containers are CategoryList/Category, RiskList/Risk, CharacteristicsList/Characteristics, TechnologyList/Technology, ClassificationList/Classification, and ApplicationList/Application. In the example, SelectAllRule uses Enable/Disable; this is a switch, not the list value for a category. The first five lists show SelectALL, whereas the application list shows SelectAll. The example comments state that selecting all ignores further entries in the same list. Do not normalize the spellings or infer an undocumented precedence between different criteria from them. The parameter table additionally lists Search as a search string; do not confuse it with the SmartFilter of an Application Object.

The policy name is required, permits UTF-8 but no commas, and has a maximum length of 60 characters; Description permits up to 1000 characters. MicroAppSupport lists True and False, but does not prove that HTTPS decryption is enabled. The table lists Action and Schedule as arrays whose duplicates are not ignored, whereas the XML example shows them per rule. Therefore, do not deduplicate or reorder the lists on your own initiative. After saving, read back the default action, order, selection, and Schedule; only assignment to the appropriate firewall rule and a client test confirm the intended block.

Distinguishing category QoS from SD-WAN objects

ApplicationFilterCategory identifies the existing category through the required Name; this category name cannot be changed. The required QoSPolicy at category level must be distinguished from ApplicationSettings/Application/QoSPolicy: The latter belongs to the application whose Name appears in the respective child object. The example additionally shows BandwidthUsageType with Individual/Shared. This makes the bandwidth-sharing context visible, but does not establish a complete precedence rule between category and application assignments. Check existing QoS assignments and the intended shared or individual usage before making the change; Application Traffic Shaping explains the operational procedure.

ApplicationObject provides an application selection for application-based SD-WAN routes, not an ApplicationFilterPolicy with Allow/Deny rules. Its required fields are Name and SelectAllRule (Enable or Disable); the name permits UTF-8, no commas, and a maximum of 80 characters. The XML example uses the same six selection containers as above, plus SmartFilter as a search string. Here too, it shows SelectALL for criteria and SelectAll for applications. The visible application selection is not the identity of the named object: For an update, read back the intended object; for Delete, this Add/Edit page does not establish the identity contract.

For Application object add and Application object edit, the reference assigns the same codes to each:

These symbols are not fully worded error messages, and the codes are not automatically equivalent HTTP status codes. Record the operation, code, and actual response together. Before a retry, read back the object name and selection that were actually saved; an unclear error must not result in a second object or one with a broader selection. For Policy-Edit, the reference also lists 502 with Message.AFPRecordExists, alongside 200/Message.AFPUpdateSuccess and 500/Message.AFPUpdateFail. Here too, the meaning of the unresolved message text remains open; a success code replaces neither the state check nor the traffic test.

Narrow down errors by symptom

• The expected Rule ID is missing: Check rule order, source/destination, service, user match, and the IPv4/IPv6 path. Do not troubleshoot the Application Filter until the flow matches the expected rule.
• No final firewall log entry: First search for the open session under Current activities > Live connections and end it in a controlled manner. Check logging and filter period in the Log Viewer.
• The application remains unknown or generic: Check pattern status, Application list, HTTPS decryption, QUIC and Web Exceptions. Packet capture is used only to confirm the network path.
• The block applies to too many services: Narrow the Risk, Category, Classification, or Smart Filter rule to individual applications or a smaller group. Then repeat the block test and the allowed control test.
• After a pattern update, more is blocked: Check which new signature matches a dynamic criterion. Narrowly exclude a required application instead of switching off the entire filter.
• The Log Viewer shows firewall Allowed, but the browser shows a block page: For proxy-processed traffic, also review the web log.
• Cloud app details are missing: Check firewall logging, HTTPS decryption and Web Policy separately. Not every transmission method provides all the detail fields.
• Facebook videos remain accessible despite the complete path: Check Rule ID, Application Filter, Web Policy, current category entries, QUIC, Decryption, Client CA and Web Exceptions. If the test remains reproducible, Sophos names support as the next escalation point.

Rollback and operation

Before the pilot, record the Application Filter, web policy, rule status, rule position, NAT assignment, TLS path, and exceptions. Rollback proceeds in this order:

1. Deactivate a separate pilot rule or select the previous Application Filter or None again in the existing rule.
2. Restore the documented rule position and only the NAT assignment that clearly belongs to the pilot configuration.
3. Check new connections with the control client for the previous Rule ID and the expected behavior.
4. Only then remove pilot filters or objects that are no longer needed. Do not delete shared filters, NAT rules, or Synchronized Application Control entries without first checking whether they are still in use.

In operation, the purpose, assigned firewall rules, dynamic criteria, allowed exceptions, owner, last change and review date are documented. For central evaluation, Enable Central Firewall Reporting and Set up Sophos Firewall Syslog and SIEM are suitable.

Change global classification only with Sophos support

The Application Filter of a firewall rule is not the global application classification in the Device Console. Sophos warns against changing these switches without instructions from Support. First, retrieve the current state without changing it:

system application_classification show
system application_classification microapp-discovery show

Global classification is on by default, while microapp-discovery is off by default. If Sophos Support specifies a change, record the previous state and the ticket. The documented switches are:

system application_classification on
system application_classification off
system application_classification microapp-discovery on
system application_classification microapp-discovery off

Turning on microapp-discovery restarts services and interrupts traffic. After an authorized change, you check both show outputs, a real application flow and the logs. The rollback restores the exact previous state: an earlier on is set with on, an earlier off with off and then checked again with show. For domain IOCs, the global classification also affects the context of third-party threat feeds.

Frequently asked questions