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:

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.

[netwizz]

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:

SSH@ICX-TEST(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
 

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):

SSH@ICX-TEST(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.

[richard_teslow]

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

[richard_teslow]

Is it possibly caused by my L3 switch not currently having acl-per-port-per-vlan enabled?

Thanks!