ACLs, subnet segregation and you.

[EtherNation_Use]

Create Date: Dec 2 2012 12:27AM

Hello. I'm hoping someone can at least point me towards something to help me understand how ACLs work and - more importantly - why mine aren't.

Here's the basic run-down. I have a network running using numerous vlans and subnets. Due to a chain of events that would take too long to explain, I need to add another entity to our physical network while keeping them separated. They have two subnets. For our purposes we'll call them 192.168.1.1/24 and 192.168.2.1/24. They also have their own internet feed, edge firewall, etc. We'll call their edge firewall 192.168.2.254. So what I want to do is allow them to pass traffic between 192.168.1.1/24 and 192.168.2.1/24 and then use 192.168.2.254 as their path to anything else and have absolutely no access to any of our existing networks (referred to as 192.168.3.1/24 in my ACL example below) and none of our existing networks should be able to access theirs. So I wrote up a bunch of ACLs I thought would get me what I wanted. However, in my testing it doesn't seem to work.
Here is my test ACL file:
entry block-3-to-1 {
if {
destination-address 192.168.1.1/24;
source-address 192.168.3.1/24;
} then {
count block_one_to;
deny;
}
}
entry block-3-to-2 {
if {
destination-address 192.168.2.1/24;
source-address 192.168.3.1/24;
} then {
count block_two_to;
deny;
}
}
entry block-1-to-3 {
if {
source-address 192.168.1.1/24;
destination-address 192.168.3.1/24;
} then {
count block_one_from;
deny;
}
}
entry block-2-to-3 {
if {
source-address 192.168.2.1/24;
destination-address 192.168.3.1/24;
} then {
count block_two_from;
deny;
}
}
entry forward-1-to-2 {
if {
source-address 192.168.1.1/24;
destination-address 192.168.2.1/24;
} then {
count redirect_one_two;
redirect 192.168.2.1;
}
}
entry forward-2-to-1 {
if {
source-address 192.168.2.1/24;
destination-address 192.168.1.1/24;
} then {
count redirect_two_one;
redirect 192.168.1.1/24;
}
}
entry forward-1-ext {
if {
source-address 192.168.1.1/24;
} then {
redirect 192.168.2.254;
}
}
entry forward-2-ext {
if {
source-address 192.168.2.1/24;
} then {
redirect 192.168.2.254;
}
} (from Doug_Jaquays)

[EtherNation_Use]

Create Date: Dec 3 2012 7:36PM

ok great so it is the redirect that isn't working.

What is the VLAN configuration on the switch? I.e. what is the IP address on the VLANs?

Thanks
P (from Paul_Russo)

[EtherNation_Use]

Create Date: Dec 3 2012 4:16PM

prusso wrote:
Hello djaquays

So first let me explain how ACLs work. Our ACLs are viewed on the ingress port and acted on on the egress port. This means that as traffic comes into the port the it is compared to the ACL and then marked as to what should happen on the egress port i.e. QoS level or deny or permit etc. The reason we do this is it allows us to carry QoS parameters from the ingress port through the switch and out to the egress port.

Based on this the ACL needs to be applied to the ingress port, failure to do that may be a problem as the source and destination IP and port will be reversed and the ACL will not work. You can only have one ACL policy assigned to the port but if you assign the ACL to the VLAN tad a port is a member of more than one VLAN you should then be able to have that port using more then on policy. In the Summit products the ACLs work top to bottom so if there is a hit on the first entry then the packet does not go through the rest of the ACL.

Ok so those are the basics. Can you give a little more detail as to what is not working with the ACL and how the ACLs are applied? I did notice that you have 192.168.1.1/24 and 192.168.2.1/24 for your subnet statements. I would suggest changing those to 192.168.1.0/24 and 192.168.2.0/24 as you want to look at the whole subnet. Also are you using ICMP to test this or normal traffic? if you are using ICMP then the statements need to have ICMP listed as the L4 port. These entries will stop IP traffic but ICMP is a little different so that has to be listed differently.

Please let us know how it is set up and what isn't working

Thanks
P Hi,

As for what wasn't working: I was able to communicate between 1.0/24 and 2.0/24 and traffic between 1.0/24 or 2.0/24 to 3.0/24 was being blocked.

However, traffic from 1.0/24 or 2.0/24 to anything else did not appear to be forwarded to 2.254.

While rereading the concepts guide again I found that x460s can have user VRs, and ended up building a new VR for the traffic I wanted isolated from everything else, so my immediate need is met. However, I would still like to get a better understanding of ACLs and why mine didn't work.

(from Doug_Jaquays)

[EtherNation_Use]

Create Date: Dec 3 2012 1:11PM

Hello djaquays

So first let me explain how ACLs work. Our ACLs are viewed on the ingress port and acted on on the egress port. This means that as traffic comes into the port the it is compared to the ACL and then marked as to what should happen on the egress port i.e. QoS level or deny or permit etc. The reason we do this is it allows us to carry QoS parameters from the ingress port through the switch and out to the egress port.

Based on this the ACL needs to be applied to the ingress port, failure to do that may be a problem as the source and destination IP and port will be reversed and the ACL will not work. You can only have one ACL policy assigned to the port but if you assign the ACL to the VLAN tad a port is a member of more than one VLAN you should then be able to have that port using more then on policy. In the Summit products the ACLs work top to bottom so if there is a hit on the first entry then the packet does not go through the rest of the ACL.

Ok so those are the basics. Can you give a little more detail as to what is not working with the ACL and how the ACLs are applied? I did notice that you have 192.168.1.1/24 and 192.168.2.1/24 for your subnet statements. I would suggest changing those to 192.168.1.0/24 and 192.168.2.0/24 as you want to look at the whole subnet. Also are you using ICMP to test this or normal traffic? if you are using ICMP then the statements need to have ICMP listed as the L4 port. These entries will stop IP traffic but ICMP is a little different so that has to be listed differently.

Please let us know how it is set up and what isn't working

Thanks
P (from Paul_Russo)

[EtherNation_Use]

Create Date: Dec 2 2012 2:33AM

I've decided I'm simply going to keep posting random thoughts/questions here until I figure it out (in which case it'll simply serve as reference for others) or someone else tells me why I'm horribly wrong.

After spending time playing with my ACLs and not getting them to work. I wondered if it wouldn't simply be easier to create a separate virtual router in our core to handle the new subnets. Reading through the concepts guide I found out that 460s can have VRs with just an edge license, so I think I can actually handle all of this before it even hits our core. I'm going to do a little playing and see how it works.

I assume that as long as no other switches have an ip in these vlans, the VR separation only needs to exist on the one that does.

(from Doug_Jaquays)