Industrial Switch ACLs: Rule Order, Binding and Access Testing

First, write down clearly who can access whom

An access control list (ACL) is a set of rules used to match packets and take actions. It can restrict certain network access at processing points supported by the device, but it does not automatically protect the entire network just because you created a rule name. Before designing, first write down the communication that maintenance computers, controllers, servers, and guest devices each need, and which access must be denied, then decide where to place the rules.

For example, to allow only a specified computer on the maintenance network to access one service on the control server, you should confirm the source address, destination address, protocol, and service port at the same time. This requirement is not exactly the same as “guests cannot enter the production network”: the former limits one service, while the latter also involves network segments, cross-zone paths, and other allowed services. Writing the goal as a testable communication relationship makes it easier to check the result than directly copying a screenshot of an interface.

The switch matches packet conditions

Depending on the model and ACL type, the device may match conditions such as MAC addresses, VLANs, IP addresses, protocols, and TCP or UDP ports. MAC belongs to Ethernet frames, IP belongs to network packets, and TCP or UDP ports are used to distinguish the corresponding transport-layer communication. They are not physical socket numbers on the switch panel; a TCP destination port and a switch port number cannot replace each other.

Filtering rules usually first parse the fields supported by the device, then decide to permit, discard, or take other supported actions. Permit only means that this filtering condition lets the packet through; it may still fail later because of routing, VLAN, another filtering point, or application authentication. An ACL does not change signal electrical standards, does not automatically translate different PLC protocols into each other, and cannot guarantee packet content security by port number alone.

How rule order changes the result

Common ordered ACLs are tested in the specified order. The first match determines the corresponding action, and later rules are no longer tested. Suppose the first rule permits a certain maintenance computer and the second rule denies a larger range; the specific computer can match the permit first. If the broad deny is moved ahead, it may be denied first, and the later fine-grained permit has no chance to take effect. This is called rule shadowing; having more rules does not mean the policy is more accurate.

The handling when no rule matches must be checked against the specific platform. In Cisco documentation, the corresponding IP access lists have an implicit deny, but this behavior cannot be applied to all vendors, all Layer 2 filtering, or different policy features. The old statement that “no match definitely means discard” and a unified index range are implementation conditions that need confirmation; you should clarify the actual default action and verify it with unmatched packets.

Address masks also cannot be mixed up. Ordinary network masks, wildcard masks, and some hardware match masks may have different bit meanings; check the definition in the current interface. You can first verify with a single known address, then expand to the required range, to avoid reversing one bit and opening too large a range. Commands, sequence numbers, and mask syntax in the manual should correspond to the firmware version and should not be treated as universal commands.

Where rules must be bound to take effect

After rules are created, they usually also need to be bound to supported ports, VLANs, or Layer 3 interfaces, and you must confirm the ingress or egress direction. Ingress generally means packets enter that processing point, and egress means they leave from there; judge from the perspective of this device, not by loosely naming it after the sending direction of the maintenance computer. Two endpoints communicating within the same switching scope may not pass through the Layer 3 filtering location you configured at all.

First draw the actual path, then mark the filtering points. The direction of a maintenance request to the server and the server’s response are different, and basic packet filtering does not necessarily maintain session state automatically. DNS, time synchronization, address acquisition, or management authentication may also depend on other services. You cannot infer that all return traffic and supporting communication are satisfied just by permitting one forward port, and you cannot treat an ordinary ACL as a complete stateful firewall.

Check the supported scope against Feichang Technology products

The Feichang Technology product center page for the M12 managed 16-port gigabit switch, number 3187, lists ACL access control and user privilege management; the four-fiber eight-copper ring network switch, number 2241, also lists IPv4, IPv6, and MAC-related ACL management. They can serve as candidates when on-site access restriction is needed, but the specific matching fields, rule capacity, binding locations, and actions still need to correspond to the documentation of the delivered version.

User privilege management controls device management permissions, while service ACLs filter related packets; the two cannot replace each other. The M12 connector form and industrial environment design also do not prove that all protocol fields can be filtered by hardware. When purchasing, submit the actual access matrix and topology, ask the supplier to confirm the model, firmware, resources, and configuration method, and do not write another brand’s rule count or default behavior as a Feichang Technology capability.

Changes must preserve management access and rollback

Before implementation, export the effective configuration, record the allowed maintenance sources and a reliable recovery entry. First verify a small number of rules in an isolated environment, then gradually apply them to the production path; do not change all VLANs, management addresses, and ACLs in the same operation. The ways a device allows submission and persistent saving may also differ; check whether the correct policy remains after a restart.

Do not delete all rules and leave everything open just to make it work, and do not directly test a broad deny on a production control path. Arrange a maintenance window and agree in advance on observation indicators and rollback conditions. If a remote session is cut off by your own rules, you cannot continue repairing it through the same blocked path; local management, controlled backup, or other supported recovery methods need to be prepared in advance.

Acceptance checks both permit and deny

Use a clearly permitted endpoint to initiate real services and confirm the request and response; then verify denial from a clearly disallowed source, and finally test the boundary case where no rule matches. Observe whether rule hit counters, logs, or mirror evidence correspond to the test time. An increase in the counter indicates that some kind of match occurred; it does not mean the complete application has succeeded, nor does it mean other paths have not bypassed the filter.

Save the rule order, binding locations, directions, default actions, and test results. If permitted services fail, check the matching conditions, return traffic, other policies, and the application separately; if denied services are still reachable, confirm the actual path and bound objects rather than first adding duplicate rules. The value of an ACL comes from an accurate and reviewable boundary; a screenshot showing “enabled” cannot replace end-to-end access acceptance.

Translated from the Chinese technical article. Source first published: 2022-11-11. Source last revised: 2026-10-13. Read the Chinese source