Solved: ACL between VLANs on 3560g

kyiver_voip · ‎11-18-2010

I need to configure access restrictions between VLANs in client's network. For some reason the ACLs configuration we have now does not make any difference as all traffic can freely flow between the VLANs. There are three VLANs:

2 DATA - 172.29.1.0/24

10 VOICE - 172.29.2.0/24

99 MANAGEMENT 172.29.99.0/24

Access should be allowed as follows:

admin host 179.29.1.45(vlan2) should have access to all hosts in vlan 10 on the following ports: icmp, ssh, web, 10000

everything else between these vlans should be denied

only admin host 179.29.1.45(vlan2) should have access to vlan 99. Everything else between these vlans should be denied.

The LAN network include 3560g core switch (where vlans are configured), 2590 (vtp) and linksys(manual vlans and trunks) data switches, 3COM and linksys voice switches (manual vlan configuration).

This access list is configured:

ip access-list extended PC_VOIP

permit icmp host 172.29.1.45 172.29.2.0 0.0.0.255

permit tcp host 172.29.1.45 172.29.2.0 0.0.0.255 eq www

permit tcp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 10000

permit udp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 22

permit tcp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 22

And applied like this:

interface Vlan10

ip address 172.29.2.250 255.255.255.0

ip access-group PC_VOIP in

Does it look correct? Unfortunately I still can telnet from vlan2 to vlan10 even though it's not allowed in the access list. Please advise. Thanks.

Here is the config of the core switch:

version 12.2

no service pad

service timestamps debug datetime msec

service timestamps log datetime msec

service sequence-numbers

!

hostname 5-c3560g-core

!

boot-start-marker

boot-end-marker

!

no aaa new-model

system mtu routing 1500

authentication mac-move permit

ip routing

!

spanning-tree mode pvst

spanning-tree extend system-id

spanning-tree vlan 1-2,10 priority 4096

!

vlan internal allocation policy ascending

!

interface Port-channel1

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface Port-channel2

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface Port-channel3

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface Port-channel4

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface GigabitEthernet0/1

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/2

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/3

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/4

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/5

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/6

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/7

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/8

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/9

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/10

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/11

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/12

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/13

description TEST VOICE PORT

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/14

description TELEPHONY SERVER

switchport access vlan 10

switchport mode access

!

interface GigabitEthernet0/15

description TRUNK TO VOICE ACCESS SWITCH 2 Linksys

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 4 mode active

!

interface GigabitEthernet0/16

description TRUNK TO VOICE ACCESS SWITCH 2 Linksys

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 4 mode active

!

interface GigabitEthernet0/17

description TRUNK TO VOICE ACCESS SWITCH 1 3COM

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 3 mode active

!

interface GigabitEthernet0/18

description TRUNK TO VOICE ACCESS SWITCH 1 3COM

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 3 mode active

!

interface GigabitEthernet0/19

description TRUNK TO DATA ACCESS SWITCH 2

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 2 mode active

!

interface GigabitEthernet0/20

description TRUNK TO DATA ACCESS SWITCH 2

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 2 mode active

!

interface GigabitEthernet0/21

description TRUNK TO DATA ACCESS SWITCH 1

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 1 mode active

!

interface GigabitEthernet0/22

description TRUNK TO DATA ACCESS SWITCH 1

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 1 mode active

!

interface GigabitEthernet0/23

description FIREWALL VOICE INTERNAL INTEFRACE

switchport access vlan 10

switchport mode access

!

interface GigabitEthernet0/24

description FIREWALL DATA INTERNAL INTERFACE

switchport access vlan 2

switchport mode access

!

interface GigabitEthernet0/25

!

interface GigabitEthernet0/26

!

interface GigabitEthernet0/27

description TRUNK TO DATA ACCESS SWITCH 2

no switchport

no ip address

!

interface GigabitEthernet0/28

description TRUNK TO VOICE ACCESS SWITCH 2 Linksys

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 4 mode active

!

interface Vlan1

no ip address

shutdown

!

interface Vlan2

ip address 172.29.1.253 255.255.255.0

!

interface Vlan10

ip address 172.29.2.250 255.255.255.0

ip access-group PC_VOIP in

ip helper-address 172.29.2.50

!

interface Vlan99

ip address 172.29.99.253 255.255.255.0

!

ip classless

ip http server

ip http secure-server

!

ip access-list extended PC_VOIP

permit icmp host 172.29.1.45 172.29.2.0 0.0.0.255

permit tcp host 172.29.1.45 172.29.2.0 0.0.0.255 eq www

permit tcp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 10000

permit udp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 22

permit tcp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 22

!

end

Peter Paluch · ‎11-18-2010

Hi,

I believe your PC_VOIP ACL shall be configured on the VLAN2 interface in the inbound direction, not on the VLAN10 interface.

The concept is somewhat confusing but essentially very logical - the SVIs (interface Vlan2, interface Vlan10) behave just like any other router interfaces. If a PC in VLAN2 sends a packet that goes somewhere outside the VLAN2, this packet will be inbound to the interface Vlan2. It is true that you want to limit packets entering the VLAN10 but from the viewpoint of the interface Vlan10, packets are going out the interface Vlan10 and thereby flowing into VLAN10.

Does this make any sense?

Best regards,

Peter

View solution in original post

Peter Paluch · ‎11-18-2010

Hi Andri,

it would also control access to the VLAN 99 as required, so I need only one ACL?

Yes, you can do it that way. In general, an ACL placed on an inbound direction of an interface applies to all packets coming into that interface, headed towards any destination network. Because an interface can have only one ACL in a particular direction, you need to perform input filtering in a single ACL.

If so do I need to add the following line at the end?

deny ip any any

Technically, it is not necessary because each ACL ends with an implicit "deny any". Despite that, many experienced administrators like to have this line at the very end of an ACL because of various reasons: to explicitly declare that the policy of the ACL is "drop all that is not permitted explicitly", to make sure that inadvertent additions to the ACL do not have any effect (because they are placed after this line) and simply to have the entire behavior of the ACL defined explicitly, instead of relying on a built-in implicit behavior.

Also, is separate ACL required to block access in opposite direction, from VLAN 10 to VLAN 2?

Yes. An ACL placed on the Interface Vlan2 in the in direction filters all the traffic coming into that interface. It does not filter packets that are leaving the interface in the out direction. In order to have control over both directions of data flow, you need to place additional ACLs on your interfaces.

Best regards,

Peter

View solution in original post

Peter Paluch · ‎11-18-2010

Hi,

I believe your PC_VOIP ACL shall be configured on the VLAN2 interface in the inbound direction, not on the VLAN10 interface.

The concept is somewhat confusing but essentially very logical - the SVIs (interface Vlan2, interface Vlan10) behave just like any other router interfaces. If a PC in VLAN2 sends a packet that goes somewhere outside the VLAN2, this packet will be inbound to the interface Vlan2. It is true that you want to limit packets entering the VLAN10 but from the viewpoint of the interface Vlan10, packets are going out the interface Vlan10 and thereby flowing into VLAN10.

Does this make any sense?

Best regards,

Peter

kyiver_voip · ‎11-18-2010

Hi Peter,

Thanks for your answer. I really hope that it makes sense! So presumably by adding an extra line to this ACL:

permit ip host 172.29.1.45 172.29.99.0 0.0.0.255

it would also control access to the VLAN 99 as required, so I need only one ACL?

If so do I need to add the following line at the end?

deny ip any any

....

Also, is separate ACL required to block access in opposite direction, from VLAN 10 to VLAN 2?

Thanks.

Andri

Peter Paluch · ‎11-18-2010

Hi Andri,

it would also control access to the VLAN 99 as required, so I need only one ACL?

Yes, you can do it that way. In general, an ACL placed on an inbound direction of an interface applies to all packets coming into that interface, headed towards any destination network. Because an interface can have only one ACL in a particular direction, you need to perform input filtering in a single ACL.

If so do I need to add the following line at the end?

deny ip any any

Technically, it is not necessary because each ACL ends with an implicit "deny any". Despite that, many experienced administrators like to have this line at the very end of an ACL because of various reasons: to explicitly declare that the policy of the ACL is "drop all that is not permitted explicitly", to make sure that inadvertent additions to the ACL do not have any effect (because they are placed after this line) and simply to have the entire behavior of the ACL defined explicitly, instead of relying on a built-in implicit behavior.

Also, is separate ACL required to block access in opposite direction, from VLAN 10 to VLAN 2?

Yes. An ACL placed on the Interface Vlan2 in the in direction filters all the traffic coming into that interface. It does not filter packets that are leaving the interface in the out direction. In order to have control over both directions of data flow, you need to place additional ACLs on your interfaces.

Best regards,

Peter

kyiver_voip · ‎11-18-2010

Thanks for clear answers. This is very helpful.

However, this brings another question. One thing I don't understand is why the ACL on interface vlan10 didn't block all traffic when was applied? Is this correct that the default line deny ip any any at the end of the ACL applied to VLAN 10 should have blocked my telnet session from VLAN 2 to VLAN 10? Please advise.

Many thanks.

Andri

Peter Paluch · ‎11-18-2010

Hello Andri,

However, this brings another question. One thing I don't understand is 
why the ACL on interface vlan10 didn't block all traffic when was 
applied? Is this correct that the default line deny ip any any at the end of the ACL applied to VLAN 10 should have blocked my telnet session from VLAN 2 to VLAN 10? Please advise.

Frankly, I don't know. The ACL per itself should have actually disabled all traffic going from VLAN10 to another VLANs because it was applied to incoming traffic from VLAN10, trying to match source/destination that are not even present in the VLAN10. Most certainly, adding the deny ip any any is not required.

I wonder - what is your current SDM setting (partitioning of the TCAM among various applications)? Can you post the show sdm prefer command output here?

Best regards,

Peter

kyiver_voip · ‎11-18-2010

Hi Peter,

Sorry for the delay, I was just visiting this client. Basically it's all good. I was following your advise and everything works perfect. I needed to figure out a few bits about the ACL for VLAN10 though. Because the rules should start with hosts addresses from vlan 10 and its ports.

Many thanks for your advise, it helped a lot!

Best wishes,

Andri

Here is what I added:

interface Vlan2

ip address 172.29.1.253 255.255.255.0

ip access-group PC_USERS in

!

interface Vlan10

ip address 172.29.2.253 255.255.255.0

ip access-group VOICE_TO_DATA in

ip helper-address 172.29.2.50

!

interface Vlan99

ip address 172.29.99.253 255.255.255.0

!

ip access-list extended PC_USERS

permit icmp host 172.29.1.45 172.29.2.0 0.0.0.255

permit tcp 172.29.1.0 0.0.0.255 172.29.2.0 0.0.0.255 eq www

permit tcp host 172.29.1.45 host 172.29.2.50 eq 139

permit tcp host 172.29.1.1 host 172.29.2.50 eq 139

permit udp host 172.29.1.45 host 172.29.2.50 range netbios-ns netbios-dgm

permit udp host 172.29.1.1 host 172.29.2.50 range netbios-ns netbios-dgm

permit tcp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 10000

permit udp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 22

permit tcp host 172.29.1.45 172.29.2.0 0.0.0.255 eq 22

permit ip host 172.29.1.45 172.29.99.0 0.0.0.255

deny ip 172.29.1.0 0.0.0.255 172.29.2.0 0.0.0.255 log

deny ip 172.29.1.0 0.0.0.255 172.29.99.0 0.0.0.255 log

permit ip any any

ip access-list extended VOICE_TO_DATA

permit icmp 172.29.2.0 0.0.0.255 host 172.29.1.45 echo-reply

permit tcp 172.29.2.0 0.0.0.255 eq www 172.29.1.0 0.0.0.255

permit tcp host 172.29.2.50 eq 139 host 172.29.1.45

permit tcp host 172.29.2.50 eq 139 host 172.29.1.1

permit udp host 172.29.2.50 range netbios-ns netbios-dgm host 172.29.1.45

permit udp host 172.29.2.50 range netbios-ns netbios-dgm host 172.29.1.1

permit tcp 172.29.2.0 0.0.0.255 eq 10000 host 172.29.1.45

permit udp 172.29.2.0 0.0.0.255 eq 22 host 172.29.1.45

permit tcp 172.29.2.0 0.0.0.255 eq 22 host 172.29.1.45

deny ip 172.29.2.0 0.0.0.255 172.29.1.0 0.0.0.255 log

deny ip 172.29.2.0 0.0.0.255 172.29.99.0 0.0.0.255 log

permit ip any any