Configure ACLs and ACEs securely on Sophos Switch

An Access Control List (ACL) on Sophos Switch is initially a named rule container. Its Access Control Entries (ACEs) use MAC, IPv4 or IPv6 criteria to forward matching traffic with Permit or discard it with Deny. The list only takes effect when assigned under Port range & binding > Port binding.

This assignment is critical: on a port with a bound ACL, the switch discards all traffic that matches no rule in that ACL. An incomplete list can therefore interrupt user traffic and the management path. Prepare and check ACLs, ACEs and bindings separately before activating them in stages.

⚠️ Lockout protection: Do not start on the only uplink, administrator port or management path. Provide independent management access and a non-critical test port, and permit the required management flows. For combined MAC and IP binding, also follow “Bind MAC and IP ACLs together only after a combination test”.

Quick procedure:

Plan data and management paths and record them as flows.
Create the required port ranges, ACLs and ACEs.
Check the unbound policy against the flow template.
Bind and test one ACL family on the test port first; then test any planned MAC-plus-IP combination on that port.
Roll out only the proven state, one port at a time.
If results differ, restore the binding snapshot from before that stage.

Distinguish ACL, ACE, port range and binding

ACL: Named rule container for MAC, IPv4 or IPv6. An ACL alone filters no port. Its name must contain 4–30 letters and numbers.
ACE: One classification rule with Sequence, Action and match fields. Sequence controls processing order; 1 is first. A MAC or IPv4 ACL supports up to 128 ACEs, an IPv6 ACL up to 64.
Port range: Named range from Minimum port to Maximum port for IPv4/IPv6 ACEs. The ACE selector shows only its name, so use an unambiguous purpose-based name.
Port binding: Assignment of prepared ACLs to a physical port.

A binding drops unmatched traffic. IPv4 and IPv6 ACLs cannot be bound to the same port simultaneously. A MAC ACL can be combined with an IP ACL, but Sophos does not document how both are jointly evaluated.

The families inspect different properties:

MAC ACL: Source/destination MAC and masks, VLAN ID, 802.1p and EtherType for Ethernet II packets.
IPv4 ACL: Source/destination IP and netmasks, protocol, source/destination port range, DSCP via Service type, ICMP type/code and TCP flags.
IPv6 ACL: Source/destination IP and prefix lengths, protocol, source/destination port range, DSCP, ICMPv6 type/code and TCP flags.

A MAC ACL does not replace an IP policy: it can classify a MAC or VLAN, but not HTTPS by TCP destination port. Conversely, an IP ACL does not classify MAC addresses. Neither proves device identity. Choose the family for the required match, not the endpoint name.

Prerequisites and flow template

Open the switch in Sophos Fusion and select:

My Products > Switches > Switches > [Switch] > Security

Access, role and licence

Central configuration requires a switch managed in Sophos Fusion and a Sophos Switch Support and Services subscription per centrally managed switch. Sophos specifies no additional ACL-only licence. Local management needs no such subscription, but this procedure and its UI labels refer to Sophos Fusion.

The account needs write access to switch configuration. The ACL documentation names no specific role or single permission, so do not assume Super Admin. Before maintenance, verify that the intended account has Add, Edit, Delete, Save and Update wherever needed; read-only table access is insufficient.

Record the current tables and Configuration source for ACLs, ACEs, port ranges and bindings. Also establish:

exact switch and target ports;
traffic direction and every source/destination traversing each port;
VLANs, source/destination MACs and IPv4/IPv6 networks;
required protocols, TCP/UDP ranges, ICMP/ICMPv6 functions and, where relevant, DSCP or TCP flags;
current management path, including administrator source, management address, VLAN, uplinks and IP family;
operational dependencies such as DNS, time, address assignment, authentication, monitoring and Sophos Fusion connectivity;
a non-critical test port, suitable systems, maintenance window and independent local or separate management access;
previous MAC ACL, IPv4 ACL and IPv6 ACL values for every port to be changed.

Sophos does not document the processing direction for bound ACLs. Do not infer ingress or egress from source/destination labels alone; test request and response for a representative flow on the test port. Create a flow template with all planning values together. Keep separate MAC and IP evidence even if only one family will be bound.

Flow 1: Management

Priority and purpose: 1, preserve management access
Source and destination: approved administrator source → switch management address
Family/protocol and service: actual IP family/protocol; management service
Expected result: forwarded (Permit)
MAC ACL evidence: matching Permit ACE or not bound
IPv4 or IPv6 ACL evidence: matching Permit ACE or not bound

Flow 2: Operational services

Priority and purpose: 2, preserve required switch operation
Source and destination: operational systems → required infrastructure targets
Family/protocol and service: as discovered; DNS, NTP, DHCP, AAA, monitoring, etc., only when traversing the port
Expected result: forwarded (Permit)
MAC ACL evidence: matching Permit ACE or not bound
IPv4 or IPv6 ACL evidence: matching Permit ACE or not bound

Flow 3: Permitted business traffic

Priority and purpose: 3, allow the approved flow
Source and destination: approved source → approved destination
Family/protocol and service: MAC, IPv4 or IPv6; approved service
Expected result: forwarded (Permit)
MAC ACL evidence: ACE/Sequence or not bound
IPv4 or IPv6 ACL evidence: ACE/Sequence or not bound

Flow 4: Unwanted test traffic

Priority and purpose: 4, verify blocking
Source and destination: defined unwanted test flow → test target
Family/protocol and service: selected family; blocked service
Expected result: discarded
Reason: matching Deny ACE or no match
MAC ACL evidence: ACE/no match or not bound
IPv4 or IPv6 ACL evidence: ACE/no match or not bound

This is deliberately not a generic port list. Your topology determines which management and operational flows traverse the target port. Allowing one web port does not automatically cover all Sophos Fusion or operational connections.

Bind MAC and IP ACLs together only after a combination test

Sophos does not document whether simultaneously bound MAC and IPv4/IPv6 ACLs use AND, OR, ordering or pipeline semantics. Assume none of these.

Test one family first on a non-critical port. Before adding the second, every allowed flow must have a matching Permit ACE in both ACLs. Test the exact final combination on that port; do not extrapolate from separate tests. Without full coverage and a successful combination test, bind only one family.

Decide dual stack in advance

IPv4 and IPv6 ACLs cannot be bound to one port simultaneously. Before rollout, decide and prove on the test port which IP family to use and what the binding does to the other family’s traffic; documentation gives no further detail. Do not work around this by rapidly switching policies during production tests.

For IPv6, explicitly include required ICMPv6 functions. The UI offers Destination Unreachable, Packet Too Big, Time Exceeded, Parameter Problem, Echo Request, Echo Reply, Router Solicitation, Router Advertisement, Nd Ns and Nd Na. Permit only needed types, but do not accidentally break Neighbor Discovery or path MTU functions.

Safe policy-design examples

The following documentation addresses must be replaced with approved plan values. They illustrate the principle, not a universally complete management ACL.

Read MAC masks unambiguously

In MAC masks, f means the specified bits must match exactly; 0 means arbitrary bits.

MAC a1:b2:c3:d4:e5:66 with ff:ff:ff:ff:ff:ff matches only that address.
MAC a1:b2:c3:d4:e5:66 with ff:ff:ff:00:00:00 matches every address beginning a1:b2:c3.

An OUI-wide rule is much broader than a host rule and is suitable only when every device in that vendor range should receive the same permission.

IPv4 test policy without immediate lockout

Assume 192.0.2.10 is a test source, 198.51.100.20 a test destination and only TCP destination port 443 should be classified in the first functional test:

Create an unmistakably named range with Minimum port 443 and Maximum port 443.
Create an IPv4 ACL such as IPV4TEST01.
Create an ACE with a low Sequence, Action: Permit, approved source/destination and correct host netmasks, Protocol: TCP and the range as Destination port range.
Add every other Permit rule required by the flow template. Do not leave fields blank or assume Any semantics without checking the saved entry on the installed firmware.
Before binding, ensure intended residual test traffic is covered by a deliberately broad temporary Permit rule or may safely fail.
Narrow a temporary broad permit only in a separate change after the positive test. Repeat management, positive and negative tests after each restriction.

Because bindings drop unmatched traffic, a blanket final Deny is not needed for that effect. An explicit Deny ACE can still classify a precisely defined flow, but cannot replace a complete Permit template. Sequence is documented as processing order, but conflict resolution for overlapping ACEs is not explicit; avoid them or test their effect before production binding.

Create port ranges

Open:

Security > Port range & binding > Port range

Select Add.
Under Name, enter a purpose-based name that identifies service and range.
Enter the first port as Minimum port.
Enter the last port as Maximum port; use the same value for one port.
Save and check Configuration source in the table.

Since ACE selection shows only the name, record name, minimum and maximum in the change ticket. Never reuse a range merely because its name sounds similar.

Create ACLs and ACEs

For all three families:

Open Security > MAC ACL & ACE, Security > IPv4 ACL & ACE or Security > IPv6 ACL & ACE.
In ACL, select Add, enter 4–30 letters/numbers under Name, then Save.
Check Profile name and Configuration source.
In ACE, select Add, set fields from the flow template, then Save.
Check ACL name, Sequence, Action, match fields and Configuration source in the saved entry.

Use Edit for existing rules or select and Delete them. Sequence accepts 1–2147483647; 1 is first. Gaps such as 10, 20, 30 allow insertions. Permit forwards matches; Deny discards them.

MAC fields

ACL name: rule’s target ACL.
VLAN ID: 1–4094; leave empty for every VLAN.
Source MAC address and Source MAC address mask.
Destination MAC address and Destination MAC address mask.
802.1p value: priority 0–7, with 0 lowest.
EtherType value: hexadecimal protocol value, only for Ethernet II packets.

A MAC ACL supports at most 128 ACEs.

IPv4 fields

ACL name, Sequence (1–2147483647) and Action (Permit or Deny);
Service type: DSCP 0–63;
Source IP address and Source netmask;
Destination IP address and Destination netmask;
Destination port range and Source port range from defined ranges;
Protocol: Any, Select from a List, or Select from ID with Protocol ID 0–255;
list entries including IPv4:ICMP, IPinIP, TCP, EGP, IGP, UDP, HMP, RDP, IPv6:Rout, IPv6:Frag, RSVP, IPv6:ICMP, OSPF, PIM and L2TP;
for ICMP, Any, Select from List or Select from ID with ID 0–255, plus ICMP code 0–255;
TCP Flags Urg, Ack, Psh, Rst, Syn, Fin, each Set, Unset or Don’t care.

An IPv4 ACL supports 128 ACEs. Use ranges only with an appropriate transport protocol and flags only when intentional and testable.

IPv6 fields

ACL name, Sequence (1–2147483647) and Action;
Service type DSCP 0–63;
Source IP address and Source IPv6 prefix length;
Destination IP address and Destination IPv6 prefix length;
Destination port range and Source port range;
Protocol: Any, Select from a List with TCP, UDP or IPv6:ICMP, or Select from ID with Protocol ID 0–255;
for ICMP, Any, Select from List with an offered ICMPv6 type or Select from ID with ID 0–255, plus ICMP code 0–255;
TCP Flags Urg, Ack, Psh, Rst, Syn, Fin as Set, Unset or Don’t care.

An IPv6 ACL supports 64 ACEs. Recheck prefix lengths and necessary ICMPv6/Neighbor Discovery flows before binding.

Check the policy before binding

Compare ACE count, family, ACL name, Action and ascending Sequence with the plan; correct broad or contradictory criteria.
Check MAC masks character by character, IPv4 netmasks and IPv6 prefix lengths.
For range rules, compare name and recorded Minimum port/Maximum port.
Check family evidence for every permitted flow: one family needs its evidence; MAC plus IP needs matching Permit ACEs in both.
For every negative test and family, document the matching Deny ACE or absent match causing the expected drop.
Check every Configuration source and record starting MAC ACL, IPv4 ACL, IPv6 ACL for each target port.
Test independent management access and confirm test and production ports should receive the same ACLs for any combination.

Bind ACLs to ports in a controlled manner

Path:

Security > Port range & binding > Port binding

The table shows Port, MAC ACL, IPv4 ACL, IPv6 ACL and Configuration source.

Identify the non-critical test port by number and cabling.
Record all three ACL columns and Configuration source.
Select only one planned family for stage one. Keep other columns at their safe recorded values; do not overwrite effective bindings without impact testing.
Verify IPv4 and IPv6 ACLs are not both selected.
Select Update, recheck the table, and immediately run management, positive, negative and request/response tests while monitoring management in a separate session.
If no MAC-plus-IP combination is planned, bind each next port only after success and retest it.
If MAC plus IPv4/IPv6 is planned, reconfirm matching Permit ACEs in both lists for every allowed flow. Add the second ACL on the same test port and select Update.
Check the displayed binding and repeat all management, positive, negative, operational and request/response tests with the exact combination. Separate tests cannot replace this because joint semantics are undocumented.
Transfer only the proven combination, one port and one verification at a time; never extrapolate from similarly named or partly identical ACLs.

If a stage fails or differs from plan, bind nothing else. Through independent access, restore all three ACL columns on the last port to the immediately preceding snapshot, select Update, and retest management and operations.

For stage two, remove the newly added family or restore its prior value; do not experiment with ACEs in an active combination.

In binding selection, None assigns no ACL from that selector; Not set uses local switch port-binding settings. They differ.

Restore the documented prior state, not a blanket Not set or None.

Change an uplink last. If management and many client networks share it, the template must cover every affected permitted connection. If coverage is unclear, do not bind the ACL there.

Validate the effect after binding

Permitted flows

Establish a new management connection over the intended path and IP family; an existing session is insufficient proof.
Test every permitted template flow from intended source to destination.
Test the exact allowed service, not just host reachability.
Test address assignment, DNS, time, authentication and monitoring when they traverse the port.
For IPv6, test required Neighbor Discovery, router and path-MTU functions on the real path.
Check at least one explicitly unchanged flow for side effects.
For MAC-plus-IP, record results with the exact final combination.

Negative tests

Generate the explicitly blocked flow from an isolated test source.
Prove that flow cannot reach its target while an allowed comparison flow still works.
Do not attribute a timeout to the ACL alone; separately check source, destination, VLAN, routing and service status.
For Deny, also verify no broader permitted use was interrupted.

Rollout is complete only after checking configuration display and documenting a new management login, every permitted test flow and at least one defined negative test.

Typical problems

Management access fails immediately after binding

Make no further changes over the broken path.
Use the prepared independent access.
Restore the snapshot before the failed stage and select Update.
Find the missing flow or incorrect address, mask, prefix, VLAN ID, range or protocol.
Retest the corrected ACL only on the test port.

A permitted service does not work

Verify the ACL is bound to the port on that data path.
Check expected ACL name and Sequence.
Do not swap source/destination; verify IPv4 netmask or IPv6 prefix.
Distinguish Source port range and Destination port range.
Check recorded min/max because selection shows only the range name.
Check protocol, ICMP type/code and TCP flags for excessive restriction.
For MAC ACEs, check VLAN ID, EtherType and wildcard mask.
Remember all unmatched traffic is dropped.
If MAC and IP are bound, restore the last working binding and retest the corrected exact combination only on the test port.

Unwanted traffic remains possible

Ensure the test traverses the bound port and selected family.
Find overlapping/broad Permit ACEs and compare Sequence with stored order.
Check MAC masks: zeros broaden matches.
Check Protocol: Any, broad IP networks and oversized ranges.
Determine whether Not set inherits a local binding or None assigns none.
Repeat with an unambiguous source/destination and service.

IPv6 fails or remains uncontrolled after an IPv4 change

Because IPv4 and IPv6 ACLs cannot share a port, inspect the actual Port binding table, then restore the predetermined dual-stack design. Do not try to select both. For IPv6 ACLs, also check required ICMPv6 and Neighbor Discovery types.

An ACL cannot be deleted

If it still contains ACEs, Sophos Fusion warns. Move ACEs with Edit, or select Fix conflicts, mark entries and use Delete dependants to delete ACEs with the ACL. First ensure the ACL is no longer needed on any port. Dependency deletion removes rules and is not routine cleanup.

Central/Fusion display and expected effect differ

Check Configuration source for ACL, ACE, range and binding.
Do not interpret Not set as no ACL; it inherits local port binding.
Compare switch and port with cabling records.
Reload after Save/Update and check stored state.
Resolve configuration source before retesting; repeated saves do not fix the wrong policy.

Rollback

Remove the effect at the port first; initially leave ACL objects in place.

Reset the binding

Via working or independent management, open Security > Port range & binding > Port binding.
Select the last changed port by recorded number.
Restore MAC ACL, IPv4 ACL, IPv6 ACL exactly. Use None only if none was deliberately assigned, and Not set only if local configuration previously controlled it. After failed stage two, remove/restore the added family.
Select Update and check table and Configuration source.
Retest management, permitted user traffic and operational services.
Reset other ports in reverse rollout order.

Revert one ACE change

If only one rule was wrong and management is stable, use Edit in MAC ACE, IPv4 ACE or IPv6 ACE to restore every previous value. Select and Delete a clearly identified new ACE. Then repeat sequence, policy-effect, positive and negative checks.

If lockout threatens, do not experiment with ACEs first: restore the known binding state, then correct the now-ineffective ACL.

Remove newly created objects

Ensure the ACL is no longer bound to any port.
Select new ACEs and Delete them.
Select the now-empty ACL and Delete it.
Remove new unused port ranges.
On a dependent-ACE warning, do not blindly choose Delete dependants; check dependencies and intended target ACL first.
Compare tables and Configuration source with the initial record.

After rollback, verify a new management login, original permitted paths and every edited port’s binding. Record cause, missing or broad permissions, affected ports, configuration source and test results in the change ticket before another rollout.