ICX 6610 IP Access-list not working properly

  • 1
  • Question
  • Updated 3 months ago
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
Photo of Richard Teslow

Richard Teslow

  • 3 Posts
  • 0 Reply Likes

Posted 3 months ago

  • 1
Photo of NETWizz

NETWizz

  • 125 Posts
  • 26 Reply Likes
Good Afternoon:

You have certainly come to the right place.  Could you describe in more detail what you are trying to do and your topology?  I know the thought of, "why can't you just answer my question???"

Background:

VLANs are a layer-2 construct and thus are not directional in nature.  Additionally, VLANs are not truly intended for security in the same sense as that of a firewall zone.   Sure, you can create two or more VLANs, and by virtue of doing this alone you have certainly divided the switch up logically into different broadcast domains, MAC address forwarding tables, and per-vlan-spanning-tree instances; essentially, you have made multiple logical switches.  You can surely divvy up and carve the physical switch interface however you like etc.   - great, but...

As you have stated, you are running Router code, so we know you also have a virtual router inside making this a multi-layer device.  Simply put you assign each VLAN a software-virtual-interface (SVI)  by using a statement like "router-interface ve 123" under the VLAN configuration.  From here you assign the IP addresses and masks to these SVIs (VEs) and by virtue of doing this, you ultimately, automatically create directly-connected routes on the router with the next-hop for that subset being its associated VE.

At any rate, the frames and broadcasts will stay contained within the VLAN, but anything destined to the VE (as its default-gateway) will hit the routing process, where all the Layer-2 information will be stripped and the packet(s) routed.  Ultimately, they get shoved into new Layer-2 frames within the next-hop VLAN, so there is no real security.


****


Right now, from this reading above, I have a mental image of three (3) VLANS.  One is a WAN VLAN (or similar), which presumably contains one physical interface and has an assigned /30 on its VE.  This one either connects to a provider or perhaps an Internet-connected firewall... because surely you are not connecting a multi-layer switch directly to the Internet...

Then I mentally picture two other VLANs...  One of these two can get to the outside world or resources within the other, and the the final VLAN can presumably get nowhere except within itself (otherwise it would be useless)

If this is correct, you would not want to use a VRF (separate routing table) because the isolation would prevent you getting into the one isolated vlan.

I doubt you are interested in mapping community to primary VLANs as this is typically deployed only with isolated VLANS.  Might be a good read though: http://docs.ruckuswireless.com/fastiron/08.0.60/fastiron-08060-l2guide/GUID-6A7FE111-9F4A-4AC6-957F-...


Personally, I would probably deal with security with a firewall connected to your switch and put the items into separate zones, but I see no reason why a rudimentary Layer-3 access-list would not suffice for basic security.


Honestly, I think you may merely be having problems with your access lists.

You would apply them to the layer-3 interfaces (the VEs), which presumably you got or it wouldn't have dropped your traffic.

If you could include your configuration, it may help.


***
At any rate, you need to determine where you are going to place your controls.  If you want to block connections out, that screams of an extended access-list with the source being the same subset as your SVI and the destination being whatever you don't want it to get to.

I recognize the problem is that you create an extended ACL to block the traffic going out.  Then traffic is allowed in, but a reply is dropped not making it back out.

You will probably need to refine your access lists a bit more using a TCP list and the established key word, which matches everything but the first packet.  The first packet goes from a client to a server to initiate the conversation and doesn't have the ACK bit set.

Basically, this would allow a TCP three-way hand-shake to take place.  It is certainly not spoof-proof, but it would allow someone from the outside to initiate a session in while you could still have a line under it to drop IP traffic going out.

Hope that helps.

Not certain if the Brocade does it, but you may want to read into Reflexive Access-Lists, too.





Photo of NETWizz

NETWizz

  • 125 Posts
  • 26 Reply Likes
Did some checking and the Brocade ICX platform has everything you need to make this work with Extended Access Lists.

I think the problem is you have an inbound filter that looks at each packet without reference to to others.  You basically are not examining the State.

You can use the "established" keyword with TCP to look at the ACK flag.  This should be the bare minimum to do what you want with TCP flows.

Specifically "established" is an option that allows TCP traffic to pass if the packets are in response to an outbound initiated session that established in acknowledgement of an (ACK) bit.

Here is the most basic Example:

[email protected](config-ext-nacl)#permit tcp 192.168.1.0/24 any ?


  802.1p-priority-marking       Mark packets with 802.1p priority value
  802.1p-priority-matching      Match TCP packets with given 802.1p priority
                                value
  dscp-marking                  Mark TCP packets with DSCP and COS parameters
  dscp-matching                 Match TCP packets with given DSCP value
  eq                            Match only packets on a given port number
  established                   Match established connections
  gt                            Match only packets with a greater port number
  internal-priority-marking     Set internal queuing priority (traffic class)
  log                           Log matches against this entry
  lt                            Match only packets with a lower port number
  match-all                     match all TCP flags listed in the filter
  match-any                     match any TCP flags listed in the filter
  mirror                        mirror traffic that matches against this entry
  neq                           Match only packets not on a given port number
  precedence                    Match packets with given precedence value
  range                         Match only packets in the range of port numbers
  tos                           Match packets with given TOS value
  traffic-policy                Attach traffic policy by name
 <cr>

Hence if you make a rule like: permit tcp 192.168.1.0/24 any established

That inside subnet can reach to anything it wants.  If it establishes contact, a reply can come back.


Another option is to make a reflexive access list using the mirror option.  This is far more advanced and even works with stateless protocols like UDP.


Let's say you create an extended ACL like this (I have not tried this on an ICX, but it should work just hte same):

[email protected](config-ext-nacl)#permit tcp 192.168.1.0/24 any mirror

In this example, as you are aware we are talking about TCP sockets, which is an IP and a port for the source and another ip and socket for the destination.

A web server for example uses HTTP and by default it would listen on TCP 80.

That is to get to it you would address the destination socket to the IP of the webserver with destination port TCP 80.

That said, an OS such as Windows or a firewall that does some form of Dynamic NAT of many devices to one public IP is going to use ephemeral ports, which are merely high-numbered, unique ports.

Let's say you have a device on 192.168.1.0/24 say it has IP 192.168.1.123 and it connects to a web sever on your network that has IP of 10.5.6.7

The OS might generate a random ephemeral port of say 57987.

The socket would look like this:

192.168.1.123:57987 => 10.5.6.7:80

When the webserver answers it addresses the socket like this:


10.5.6.7:80 => 192.168.1.123:57987

^^^  The above is the basics for working with sockets and identical for TCP or UDP of which each have 65,536 ports (if you count 0); regardless, it is a two-byte field..  The difference being the abundance of TCP flags and the three-way handshake make TCP statefull vs stateless.  The PDU is segments in TCP.


Continuing on...

This ACL:
permit tcp 192.168.1.0/24 any mirror

it would permit this egress traffic described above:

192.168.1.123:57987 => 10.5.6.7:80

When outbound traffic is detected, the switch then creates an automatic reflexive "mirror" ACL into the switch's memory.

Specifically, it creates a very specific, temporary ACL something like:

permit tcp host 10.5.6.7 eq 80 host 192.168.1.123 eq 57987

This allows a specific, expected response to come back inbound:

10.5.6.7:80 => 192.168.1.123:57987


With each packet that matches the now inbound reflexive rule, it restarts the timer keeping the reflexive ACL in memory.  If no packets are received, the switch eventually drops the reflexive ACL.  Additionally, if it encounters a TCP FIN flag, it causes an immediate time-out and removal of the reflexive entry.


I hope the above helps.  Whatever you are trying to do, it should be manageable on the 6610 ICX platform.
Photo of Richard Teslow

Richard Teslow

  • 3 Posts
  • 0 Reply Likes
Hi NETWizz,

Thank you so much for taking the time to answer me here. In your first post you asked for a logical design and your assumptions are mostly correct.

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

On the L3 switch I have numerous VLANs that are shared between the the core switching and edge switching, with the L3 switch routing to different VLANs via VEs. One particular VLAN has a few port-based VLAN assignments and those are the clients I need to make one way (inbound into their subnet only). Specifically that client subnet is 172.24.43.128/25. Other VLAN networks have a variety of private IP address ranges and should be able to reach in and connect to clients within

I'm unsure where to apply your suggested ACL, do I apply it to the VE for the VLAN? 

Here's a snippet of the config, I've applied the access list to the VE340 interface and as soon as I do all traffic either direction stops.

interface ve 430
 port-name isolated_network_VLAN_router
 ip access-group deny_client_pcs in
 ip address 172.24.43.1 255.255.255.128
 ip helper-address 1 172.24.33.95
!
!
ip access-list extended deny_client_pcs
 permit tcp 172.24.43.128 0.0.0.127 any established

Thank you again for all the help!

Rich

(Edited)
Photo of Richard Teslow

Richard Teslow

  • 3 Posts
  • 0 Reply Likes
Is it possibly caused by my L3 switch not currently having acl-per-port-per-vlan enabled?

Thanks!
Photo of NETWizz

NETWizz

  • 125 Posts
  • 26 Reply Likes
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
<implicit deny>


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.