ICX7150-48P TCP established ACL not working as expected

[suddenwolf]

Hi, I'm running into a weird issue after upgrading from a Brocade ICX6450 to a Ruckus ICX7150.

I have the following ACL that I transferred from the 6450:

ip access-list extended no_internal_access
 permit tcp any any established
 permit tcp any host 10.20.1.20 eq http
 permit tcp any host 10.20.1.20 eq ssl
 permit tcp any host 10.20.1.50 eq dns
 permit tcp any host 10.20.1.60 eq dns
 permit udp any host 10.20.1.50 eq dns
 permit udp any host 10.20.1.60 eq dns
 deny ip any 10.0.0.0 0.255.255.255
 deny ip any 192.168.100.0 0.0.0.255
 permit ip any any

I have this ACL applied to a guest VLAN, 98. On the 6450, the ACL is applied "in" on VE98 and everything works as expected. I installed the ACL onto the 7150, and applied the ACL "in" on VLAN 98, since that is how it is now done. However, on the 7150, HTTP and even RDP works to hosts in the 10.0.0.0/8 range in many cases. The ACL is doing something, since ICMP does not work. I tried a simple ACL with just an allow established rule and the deny ip rules, and it seems to be the established rule type that is causing the problem. Removing it solves the problem.

Is this an expected behavior, or is there something I am missing on the 7150 that would make this not work as it does on the 6450? It is running 08.0.95m. Thanks in advance!

[Mayank]

Hi Suddenwolf,

Thank you for posting your query.

I understand that ACL is not working as expected after you moved from Brocade ICX6450 to a Ruckus ICX7150.

I suspect since you have been using ICX 6450 previously and it will be running on an older code if I compare it with the new ICX7150 on code 8095m there are chances of command syntax modification, addition and depreciation.

Hence I am requesting you to have a look at page no 103 concerning ACL on the security guide of 8095m.

Please refer the below link for your reference page no 103.

https://support.ruckuswireless.com/documents/3451-fastiron-08-0-95-ga-security-configuration-guide  

https://support.ruckuswireless.com/documents/3450-fastiron-08-0-95-ga-command-reference-guide

Moving Forward If this issue is not resolved, Please log a ticket with the below link so that we can help you further.

https://support.ruckuswireless.com/contact-us

I hope this information helps you.

Please feel free to leave us a message if you have any concerns.

[suddenwolf]

Thank you for those references, I read through them and while there are some differences since the older code (such as applying the access group to the VLAN instead of VE), I don't seem to see any differences noted about how the established keyword should function.

If I do not find a solution in the near future then I will log a ticket, but I wanted to see if there was any advice in the community first before taking up support time 🙂

[jdryan]

Hi Suddenwolf ,

Based on the ACL shared : 
ip access-list extended no_internal_access
permit tcp any any established
permit tcp any host 10.20.1.20 eq http
permit tcp any host 10.20.1.20 eq ssl
permit tcp any host 10.20.1.50 eq dns
permit tcp any host 10.20.1.60 eq dns
permit udp any host 10.20.1.50 eq dns
permit udp any host 10.20.1.60 eq dns
deny ip any 10.0.0.0 0.255.255.255
deny ip any 192.168.100.0 0.0.0.255
permit ip any any

Permit tcp any established : being on sequence 1 : could be the reason. 

Could you try the below : and let us know if there is a change in behavior. 

ip access-list extended no_internal_access
 permit tcp any host 10.20.1.20 eq http
 permit tcp any host 10.20.1.20 eq ssl
 permit tcp any host 10.20.1.50 eq dns
 permit tcp any host 10.20.1.60 eq dns
 permit udp any host 10.20.1.50 eq dns
 permit udp any host 10.20.1.60 eq dns
 permit tcp any any established
 deny ip any 10.0.0.0 0.255.255.255
 deny ip any 192.168.100.0 0.0.0.255
 permit ip any any

this should allow only the said established connections. 

and as for ping : you could try and add in the ICMP allow statement. 

Do let us know if the same helps ! 

[suddenwolf]

Thank you for the suggestion! I tried moving the established rule as suggested but did not see any changes, I was still able to initiate HTTP connections & RDP connections to devices in the 10.0.0.0/8 range from devices within the guest VLAN.