cancel
Showing results for 
Search instead for 
Did you mean: 

ICX7150-48P TCP established ACL not working as expected

suddenwolf
New Contributor

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!

4 REPLIES 4

Mayank
RUCKUS Team Member

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.

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 🙂

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.

Well moving the permit tcp any any established below the deny ip any 10.0.0.0 0.255.255.255 wouldn't allow reply traffic(established tcp) if you wanted to rdp into the guest vlan from another vlan in 10.0.0.0 0.255.255.255.

I'm also seeing similar issues with the established keyword which is allowing any TCP traffic thru which has caused me to re-architect my ACLs. It's possible I don't understand the exact use case for established but I understood it to be similar to a reflexive list. I'm on an ICX 7250-24p with SPR08095m.bin firmware.

***Edit***

Never mind it's working properly in my case, I had a situation where there was asymmetric routing with two gateways on the same subnet so basically the "in" side of the ACLs on the VLANs was seeing traffic leaving and coming back into the VLAN. I was going down the route of adjusting ACLs for this but this was leading to a lot of other unforeseen issues, getting back to symmetrical routing solved all the issues.