Unsolved
1 Rookie
•
13 Posts
0
1946
Dell S4128F-ON VLAN ACL Help
Hello,
I have recently deployed two Dell S4128F-ON switches in a Top of Rack configuration for a collapsed core network design. These switches are handling inter-VLAN routing are configured in VLT with Peer-Routing.
I have came across an issue when applying inbound ACLs to VLAN interfaces.
After applying an ACL to our Servers VLAN inbound I found that all traffic not specified in the ACL was blocked to hosts within the same VLAN. For example, SMB shares were no longer available and Active Directory authentication was unavailable. Traffic permitted by the ACEs such as ICMP and HTTP did however work.
Am I correct in saying that ACLs on these switches also apply to traffic from hosts within the same VLAN? I come from a Cisco background and this is different to how ACLs operate on Catalyst series switches. I remember reading something about this on older Dell PowerConnect 6200 switches were ACLs were handled more like a Cisco ACL VLAN MAP as opposed to an input router ACL?
Also, traffic from the TCP based ports specified from 10.0.0.0/23 to 10.20.0.0/23 seem to be getting dropped, I'm assuming this is due to the nature of switch ACLs being stateless? Would I need to apply the "established" keyword to allow this traffic to pass?
I have listed the ACL below.
deny ip 10.0.0.0/23 192.168.0.0/24
deny tcp 10.0.0.0/23 host 10.0.0.205 eq 22
deny tcp 10.0.0.0/23 host 10.0.0.206 eq 22
deny tcp 10.0.0.0/23 host 10.20.0.1 eq 22
deny tcp 10.0.0.0/23 host 10.30.0.1 eq 22
deny tcp 10.0.0.0/23 host 10.60.0.1 eq 443
deny tcp 10.0.0.0/23 host 10.60.0.1 eq 22
permit icmp any any
permit tcp any any eq 80
permit tcp any any eq 443
permit tcp any any eq 8080
permit tcp any any eq 8443
permit tcp any any eq 53
permit udp any any eq 53
permit udp any any eq 123
permit tcp any any eq 21
permit tcp any any eq 22
permit tcp any any eq 25
permit tcp any any eq 5060
permit tcp any any eq 5938
permit udp any any eq 5938
permit udp any any range 3478 3481
permit ip 10.0.0.0/23 10.60.0.0 0.0.0.255
permit tcp 10.0.0.0/23 10.20.0.0/23 eq 4172
permit udp 10.0.0.0/23 10.20.0.0/23 eq 4172
permit tcp 10.0.0.0/23 10.20.0.0/23 eq 22443
permit udp 10.0.0.0/23 10.20.0.0/23 eq 22443
permit tcp 10.0.0.0/23 10.20.0.0/23 eq 32111
permit tcp 10.0.0.0/23 10.20.0.0/23 eq 42966
permit tcp 10.0.0.0/23 10.20.0.0/23 eq 9427
permit ip 10.0.0.0/23 10.1.1.0 0.0.0.255
Many thanks.
DELL-Josh Cr
Moderator
Moderator
•
8.5K Posts
0
September 30th, 2020 10:00
Hi Greig,
There is an implicit deny all statement at the end of the ACL that blocks all traffic not specifically permitted. Adding a permit any any to the end should allow all none denied traffic to work. Let us know if you have any additional questions. Page 1364 https://dell.to/3l28MeU
DELL-Josh Cr
Moderator
Moderator
•
8.5K Posts
0
September 30th, 2020 12:00
Yes, that should work.
Greig_Mitchell
1 Rookie
1 Rookie
•
13 Posts
2
September 30th, 2020 12:00
Hi Josh,
Would adding permit ip 10.0.0.0/23 10.0.0.0/23 at the end of the ACL also give the same effect and allow non-denied traffic within the same VLAN?
Many thanks.
Greig_Mitchell
1 Rookie
1 Rookie
•
13 Posts
0
October 8th, 2020 01:00
Thanks Josh, that has worked.
Interestingly I came across a stranger issue when connecting our new VDI environment up to these switches.
When Logged into a VM on the destinated VDI VLAN I noticed that incomplete TCP handshakes to some hosts within the 10.0.0.0/23 network were occurring while others were fine. Running a packet capture from within the client VM showed that TCP packets to these hosts where hung at SYN_SENT flag while on the server side the transmission was sitting at SYN_RECIEVED, however the ACK flag was never processed resulting in the connections failing to go to the established state.
Oddly, our current VDI environment is connected to a stack of 2x Dell N1524 switches in Layer 2 mode (no routing) which are then connected to the S4128F-ON switches via an LACP port channel. This environment is on the same VLAN and did not experience these issues.
Adding a permit ip any any statement at the end of the inbound ACL for VDI VLAN interface (10.20.0.0/23) solved the TCP handshake issues within the new VDI environment on the S4128F-ON switches.
What I don't understand is that this ACL already had permit ip 10.20.0.0/23 10.0.0.0/23 specified so surely it shouldn't have made a difference what switch these environments were connected to?
Could this be a potential firmware bug with the S4128F-ON switches? We are currently running on firmware from late April this year.
DELL-Josh Cr
Moderator
Moderator
•
8.5K Posts
0
October 8th, 2020 09:00
I was not able to find anything about a known issue with the firmware.