ICX 6610 IP Access-list not working properly

[richard_teslow]

Hi all,
I've got an ICX6610 running router code that I'm currently using as my core switch with various VLANs. I'm trying to create a one-directional VLAN so that clients inside that VLAN cannot initiate connections out but other clients in other VLANs can connect to clients within. 

So far I've been going down the route of ip access-lists but hitting dead ends. Every time I apply an access list I lose connectivity both directions to the VLAN I'm trying to isolate. Does anyone have any recommendations or ideas that could help?

Thank you!
Rich

[netwizz]

Good afternoon:

I have needed that command before, but I cannot remember the specifics.  I think I was doing dhcp snooping or perhaps dealing with multple-VRFs, but regardless, the documentation would seem to indicate it is a good idea.  If I recall, that command requires a reload though, just FYI.

In the above question you asked where to apply the ACLs.

Apply them to Layer-3 interfaces such as the VEs.  You know a Layer-3 interface because it has an IP address assigned to it.

****

I am trying to make sense of everything you posted, and it is tough because everyone (myself included) has a different way of saying things.  Please correct if I have anything wrong at all:

Reading what you said and looking at this:

Core ICX6610---------------Edge ICX6450-------------Client
    L3 SW                                L2 SW                         PC



My reading is that your Core is the 6610, and it is the one switch in this topology to be running the L3 code.  This 6610 has multiple VLANs that each have a respective router-interface ve ## assigned; since, this is where your routing happens.  That each VE interface IS the Layer-3 routing interface where the default-gateways for the subnet(s) contained in each VLAN terminate as the directly-connected routes.

That the 6450 runs Layer-2 code and is NOT participating in any routing.  That the 6450 merely has some VLANS trunked (TAGGED terminology for Brocade/Ruckus) between it and your 6610, so you can bring multiple VLANs into your 6450 over any given network cable/fiber going to the 6610.


...That one of these VLANS (VLAN 430) is the container for subnet (172.24.43.128/25), which needs to allow only inbound traffic.  That the "clients" as you call them are PCs with IPs within the aforementioned subnet.  That these PCs or "Clients" are physically connected to your edge switch, the 6450 via interfaces assigned to VLAN 430 (presumably as UNTAGGED intefaces), right?

***

If all of the above is correct, you first need to pick the type of access list, where you are going to apply it, what direction you are going to apply it, etc.


To block the most basics of incoming traffic standard access lists suffice, but here we need an extended Access List to control traffic going out, and I would apply it to VE 430 on your 6610.

*****

Looking at your access list:
ip access-list extended deny_client_pcs
 permit tcp 172.24.43.128 0.0.0.127 any established



This permits TCP traffic sourced from 172.24.43.128/25 to anywhere.  Once the TCP session establishes, it CAN get replies, but the kicker is that 172.24.43.128/25 has to start that session to make the TCP three-way handshake.

Regardless, this ACL then drops everything else with its implicit deny.  Essentially, this implicit deny is more or less akin to "deny ip any any."  It is basically a catch-all because generally you permit explicitly what you want and deny the rest.


This one is actually a fairly tough challenge you clearly want to control it in only one place, so it cannot talk out.  Otherwise you would be putting ACLs on all sorts of other VEs to drop traffic inbound from this subnet that is not allowed to talk out - too much overhead.

Obviously, the logical thing that first pops into mind is to create a "deny protocol 172.24.43.128 0.0.0.127 any" type statement, but that's kind of pointless when the next statement is ultimately an implicit deny any.  With only deny statements, its not like you are allowing anything anyway.  Usually deny statements are specific and granular followed with a permit statement such that any packets not denied are permitted and processed before it hits the implicit deny.  For example a permit ip any any, would cause every packet to be processed allowed through.  No packet would fall through getting dropped on the implict deny because processing stops for any given packet once it matches an ACL statement.

***

What you ultimately need is to do some ingress processing of packets coming into 172.24.43.128/25 to allow it in (which would be the default behavior not having any access-lists at all) only so that you can allow the reply.

Probably something like this might work...

ip acces-list extended permit_outside_in
permit tcp any 172.24.43.128 0.0.0.127 established

ip access-list extended deny_out
deny ip 172.24.43.128 0.0.0.127 any


interface ve 430
ip access-group permit_outside_in in
ip access-group deny_out out


*****

My thought would be that this should definitely stop this subnet from starting conversations out.  the permit TCP... established should allow anything from the outside to this subnet being the outside initiates the connection as the source.  In theory , I suspect it might be able to reply through the "established"

************

If that doesn't work, you will probably need reflexive Access Lists, which in this case would be where an incoming connection causes the dynamic creation of a reflexive ACL that mirrors it allowing the reply.


Probably something like this might work... if MIRROR for an ACL meant reflexive mirroring and not mirrored port like it appears to in the ICX family. 😞

ip access-list extended permit_outside_in
permit tcp any 172.24.43.128 0.0.0.127 reflect ALLOW_RESPONSE


Then you basically apply that in the "in" direction.  Traffic received that is allowed automatically creates another reflexive ACL called ALLOW_RESPONSE

That would be the ACL you would apply in the "out" direction; since, it would automatically make permit statements and still have an implict deny to drop everything else that is not permitted.

Otherwise, you could of course make your own outbound list to drop whatever you want to drop (i.e. everything) or specifically put some other permit rules in as exceptions; since, there is an implict deny anyway.... then you could use the keyword EVALUATE to tell it to run the ALLOW_RESPONSE reflexive ACL.


I hate to say this but the context of "mirror" on the ICX is NOT with regard to reflexive access-lists.  It appears to be with mirror ports:

Source:

http://docs.ruckuswireless.com/fastiron/08.0.60/fastiron-08060-monitoringguide/GUID-8CDDEB0F-08D9-41...


therefore I hope you can make this work with the "established" key word being careful who is the initiator, who is talking to whom, on what interface it is applied, and what direction.

Honestly, ACL support is a bit lacking in its capabilities on this and countless other platforms.




In a LOT of ways your best bet is to trunk or route it all the way to a firewall with different firewall zones.