ā10-03-2017 09:39 AM - edited ā03-05-2019 09:14 AM
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
ā10-03-2017 09:53 AM - edited ā10-03-2017 10:04 AM
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
ā10-04-2017 12:15 PM
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.
ā10-04-2017 12:50 PM - edited ā10-04-2017 12:52 PM
Hi
I have implemented VACL for this kind of filtering. Please see this link:
ā10-04-2017 01:12 PM
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
ā10-04-2017 01:31 PM
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.
ā10-04-2017 01:51 PM
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
ā10-05-2017 09:29 AM
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.
ā10-05-2017 02:30 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide