ACL

[Ed Lo]

Hi,

I have 2 subnetworks and I want to seperate them so that they cannot communicate with each other. Below is how I have tried to do it but, it doesn't work as when I attempt to ping from one to another it still goes through. Am I missing something?

(vlan 4 in)
ip access-list standard test
deny 198.168.3.0 0.0.0.255
permit 10.10.1.0 0.0.0.255

interface vlan 4
ip access-group test in

(vlan 2 in)
ip access-list standard test2
deny 10.10.1.0 0.0.0.255
permit 198.168.3.0 0.0.0.255

interface vlan 2
ip access-group test2 in

EDIT:
To clarify the setup here is what it is:

first subet:
VLAN 2
ip address 192.168.3.1

DHCP of 192.168.3.0

second subnet:
VLAN 4
ip address 10.10.1.1

DHCP of 10.10.1.0

[Julio E. Moisa]

Try this config: 

ip access-list extended test
deny ip 10.10.1.0 0.0.0.255 198.168.3.0 0.0.0.255
permit ip any any

interface vlan 4

ip add 10.10.1.1 255.255.255.0
ip access-group test in

#############################

ip access-list extended test2
deny ip 198.168.3.0 0.0.0.255 10.10.1.0 0.0.0.255
permit ip any any 

interface vlan 2

ip add 198.168.3.1 255.255.255.0
ip access-group test2 in

[Ed Lo]

I tried this and at first I thought it worked however it is causing one of them to stop hadning out ip addresses. In this case it is causing the 192.168.3.0 network to stop hadning out ip addresses.

[Julio E. Moisa]

Hi 

I have implemented VACL for this kind of filtering. Please see this link:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/54sg/configuration/guide/config/secure.html#wp1135783

[Richard Burts]

We have a bit of a moving target in this discussion. The initial post only identified a requirement that the two subnets should not communicate (and did not give us any information about which subnet was which interface). Julio made a good assumption about the relationship of subnet to interface and supplied an access list which satisfies the requirement - so far. Then another requirement is added - that one subnet should get ip addresses from the other subnet. Assuming that this is a DHCP request from one subnet to the other subnet then the issue is that the DHCP request comes with a source address of 0.0.0.0 (logical since the device does not yet have an address). So the 0.0.0.0 address does not match a permit and is denied. The solution is to add another statement to the ACL which permits this traffic Permit a source address of 0.0.0.0.

HTH

Rick

[Ed Lo]

I will take a look at the link. But as someone else pointed out my initial post is a bit vague so I've added more detail to how the 2 subets are set up. Hopefully this clarifies a bit.

[Richard Burts]

Thanks for the additional information about how the subnets relate to the vlan interfaces. It does clarify that the ACL suggested by Julio would be effective in preventing communication between the subnets. But a DHCP request coming into the switch would not match the permit statement and therefore would be denied. If you add a line as I suggested to permit these requests it would allow DHCP to be successful. I have implemented extended access lists to permit this type of traffic and it has worked well. You could probably also accomplish this using VACL if you want to use that approach. But an extended access list with ip access-group is capable of achieving both parts of your requirement.

HTH

Rick

[Ed Lo]

So would I do something like this?

ip access-list extended test
deny ip 10.10.1.0 0.0.0.255 198.168.3.0 0.0.0.255
permit ip any any
permit ip address 0.0.0.0

I'm still trying to work out how to do acl so I would like to make sure I get what your saying I should do.

[Richard Burts]

I am not sure if you meant it this way, but your question presents a bit more of the moving target. Originally the requirement was simple - that the two subnets not communicate with each other. Then we added a requirement that a subnet be able to get IP addresses using DHCP to the switch. Now there is a question about whether the subnet should be able to communicate with things outside (other than the second subnet)? If the answer to that is yes then your addition of permit ip any any is certainly appropriate (and it solves the problem with DHCP). If you do not want to enable communication with "outside" then perhaps permit ip any any is a bit broad, and perhaps you want something more focused on the DHCP traffic.

The one thing that we can say with confidence is that the other line that you suggest

permit ip address 0.0.0.0

is incorrect syntax and should not be used.

HTH

Rick