Dell EMC Networking Creating and Applying Management ACL on the X-Series

Creating and Applying a Management ACL on the X-Series: Blocking Host Access to Switch Management

Example Scenario and Requirements

Implementing an X-series switch and wish to prevent users from a specific subnet from accessing the switch management functions. To accomplish this we will create an Access Control List (ACL), populate it with the relevant Access Control Entries (ACEs) and apply the ACL to an interface.
In this scenario, the purpose is to block all clients in subnet 172.31.200.0/24 from accessing the IP address of the switch. The switch has multiple IP addresses, both on the client’s local subnet (172.31.200.3) and on a separate wireless subnet.
If routing is enabled on the X-series, the ACL created must block access both to the IP of the switch in the local subnet, as well as any traffic sourced from the Client subnet destined towards other subnet IPs on the switch (e.g. from 172.31.200.0/24 to 172.30.200.3).

Environment
 

Client Network: 172.31.200.0/24
Client Network Connection: Untagged VLAN 50, Port Gi 1/0/1
Switch IP Addresses:
            VLAN 10 – Wireless –             172.30.200.3/24
            VLAN 50 – Clients                  172.31.200.3/24

 

Steps to Create

Network Administration -> Security -> ACL


Fig. 1 – Accessing the ACL/ACE Configuration Page in the WebGUI

 

Fig. 1a – The final ACL created using this article. Notice how the switch substitutes some port numbers for their well-known use (23 becomes ‘telnet’ and 80 becomes ‘www’)

 

Creating the ACL

IPV4 Based ACL -> Edit -> Add -> Create a Name (no spaces) -> OK -> Close Popup

Fig. 2 – Naming the ACL. Avoid using spaces or non-standard characters in ACL names.

 

Add Entries (ACEs) to an ACL

IPv4 Based ACE -> (ACL name(s) are in Dropdown, select the one you just made) -> Edit -> Add -> Fill in rules for entry -> Ok

Each ACE will target one management protocol we wish to block as well as the unique destination we wish to block. We need to make a separate group of ACEs for the second possible management IP since the alternative is to block the protocols without regard to their destination – which would block any of these protocols attempting to transit the switch which is far beyond what we’re trying to do – or block without regard to protocol and only based on destination which would deny any routed traffic!



Fig. 3 – Adding the ACE to block 172.31.200.0/24 clients from Telnetting to 172.31.200.3. The Options in Red are required for our purposes; logging - circled in Orange - is optional.

 

 

 

Repeat for each protocol (1 for telnet(23), 1 for http(80), 1 for https(443), 1 for ssh(22) [if configured – ssh access to X-series is disabled by default] and destination, and finally a ‘permit all’ statement at the end to permit everything not explicitly blocked – see Fig. 4) -> Ok



Fig. 4 – Creating the ‘permit all’ statement. Failure to add this will result in an implicit deny at the end of your ACL meaning that if the switch reaches the end of the ACL (rules are applied in priority order) and none of the rules have matched, it will deny the traffic. We add a permit all to avoid denying all the specifically targeted traffic and all the traffic we don’t reference at all.

When you are finished, the ACE entries for your ACL should appear similar to Fig. 5, below. The figure has omitted the variables we did not configure for better viewing.



Fig. 5 – Edited for clarity. This shows all ACEs – rules – that make up a particular ACL. See here we are blocking 4 different protocols – 22, 23, 80, and 443 - to two different destinations – 172.31.200.3/32 and 172.30.200.3/32.
 

Applying the ACL to an Interface

ACL Binding -> Edit -> Click Edit Icon by Port -> Leave 'Ingress' Selected -> Check 'Select Ipv4 Based ACL (select ACL from drop down if not already populated) -> OK


Fig. 6 – Applying the ACL to the interface. We select ingress so that all traffic coming in on Gi1/0/1 is checked against the ACL before being allowed further in the switch.