ACL not working properly

[nilssondk]

Hi there

I've got a problem with an ACL that should seperate a guest network from an "corporate" network.

I started out with the following:

!

interface Vlan2

ip address 10.39.1.1 255.255.255.0

!

interface Vlan3

ip address 10.39.2.1 255.255.255.0

!

Both network working properly, no rocket science here... But i needed to seperate those two network. 10.39.2.0 should not be able to access 10.39.1.0. Therefor i created the following setup:

!

interface Vlan2

ip address 10.39.1.1 255.255.255.0

ip access-group 2 in

!

interface Vlan3

ip address 10.39.2.1 255.255.255.0

!

access-list 2 permit 10.39.1.0 0.0.0.255

access-list 2 deny   any

Should be straight forward, but this is the result when i am doing a ping (10.39.1.140 accepts icmp):

rtr-1#ping 10.39.1.1 source vlan 3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.39.1.1, timeout is 2 seconds:

Packet sent with a source address of 10.39.2.1

U.U.U

Success rate is 0 percent (0/5)

     Very good.. I'm happy. but...

rtr-1#ping 10.39.1.140 source vlan 3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.39.1.140, timeout is 2 seconds:

Packet sent with a source address of 10.39.2.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

     How is this possible?

Hardware: C887VA-W-E-K9

Software: 15.1(4)M5

Am i just having a bad day, or is there a not logical explanation?

Thanks in advance!

[cadet alain]

Hi,

the second output you get is normal as you applied a standard ACL to the SVI so it is only matching the source address and the reply is not dropped because it matches the first ACL entry. You should use an extended ACL to get this working .

When you do first test have you got hits against the deny any entry? ---> sh access-list 2

Regards

Alain

Don't forget to rate helpful posts.

[Richard Burts]

Simon

I question the logic of your access list construction. When you apply the access-group in you are checking for the source address of traffic coming into the switch. How could the source be anything other than the permitted addresses? I suggest that it would work much better if you wrote a standard access list that will deny if the source address is VLAN 3 and then permit any. Then apply the access-group as out.

HTH

Rick

Sent from Cisco Technical Support iPad App

[cadet alain · Accepted solution]

H Rick,

Why not simply use an extended ACL inbound:

access-list 100 deny ip 10.39.1.0 0.0.0.255 10.39.2.0 0.0.0.255

access-list 100 permit ip 10.39.1.0 0.0.0.255 any

int vlan 2

ip access-group 100 in

Regards

Alain

Don't forget to rate helpful posts.

[Richard Burts]

Alain

Both solutions work - at least sort of. Your solution prevents VLAN 2 initiating traffic traffic to VLAN 3 (and allows VLAN 3 to initiate traffic to VLAN 2) while my solution prevents VLAN 3 from initiating traffic to VLAN 2 (and allows VLAN 2 to initiate traffic to VLAN 3).

I think I chose the standard ACL solution because it was closer to what Simon was trying to do in his original post.

Both of our solutions prevent communication between the VLANs. But probably the optimum solution is an inbound ACL on both VLANs to prevent traffic going to the other VLAN.

HTH

Rick

Sent from Cisco Technical Support iPad App

[nilssondk]

Hi Alain

Well your extended ACL works as designed, so thats just great, problem solved. However, i still dont understand why my standard acl dosent work? i am denying any, except 10.39.1.0/24...

Richard, the goal was to seperate vlan 3 from vlan 2. The other way around dosent have any impact on functionality in this setup.

Thanks for answers, i have a working setup now. But i'm still a little confused :-)

// Simon

[Richard Burts]

Simon

The standard access list that you wrote checks the source address. Every packet coming into interface VLAN 2 will have the VLAN 2 subnet as its source and can not distinguish whether the traffic is for VLAN 3 or not. The extended ACL suggested by Alain works and the standard ACL applied out rather than in would also work.

HTH

Rick

Sent from Cisco Technical Support iPad App

[nilssondk]

*pling* the explanation i was looking for

Thanks Rick