Vlan issue

[Sheik Mohamed]

Dear Supporters 

I have Cisco 3550 series core switch IOS (tm) C3550 Software (C3550-I5Q3L2-M) .

Already configured 3 vlans (Vlan 2 =192.168.2.0/24,  vlan 10=192.168.10.0/24 ; vlan=192.168.15.0/24)

We need to restrict the access in to particular vlan .example vlan 10 want to access other vlan 2 and vlan 15 but both vlan cannot communicate with vlan10 ??we need to be scure the vlan 10 

Vlan 10 >>>>>can access vlan 2 & Vlan 15

Vlan2 &Vlan 15 xxxxx cannot access vlan 10

is their any accesslist or commands available?? pls share with me the details??? 

Config:

version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname xxxxxx
!
enable secret level 5 5 xxxxx
enable password xxxxxx
!
username admin password 0 xxxxxxx
ip subnet-zero
ip routing
ip name-server 193.188.97.209

ip name-server 8.8.8.8
!         
ip dhcp pool Vlan2
   network 192.168.2.0 255.255.255.0
   default-router 192.168.2.1 
   dns-server 192.168.100.254 
   lease 5
!
ip dhcp pool Vlan10
   network 192.168.10.0 255.255.255.0
   domain-name xxxx
   dns-server 192.168.100.254 
   default-router 192.168.10.1 
   lease 5
!
ip dhcp pool Vlan15
   network 192.168.15.0 255.255.255.0
   dns-server 192.168.100.254 
   default-router 192.168.15.1 
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
!         
!
interface FastEthernet0/1
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/2
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/3
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/4
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/5
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/6
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/7
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/8
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/9
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/10
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/11
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/12
 switchport access vlan 10
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/13
 switchport access vlan 2
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/14
 switchport access vlan 2
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/15
 switchport access vlan 2
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/16
 switchport access vlan 2
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/17
 switchport access vlan 2
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/18
 switchport access vlan 2
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/19
 switchport access vlan 2
 switchport mode access
 no ip address
 spanning-tree portfast
!         
interface FastEthernet0/20
 switchport access vlan 2
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/21
 switchport access vlan 15
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/22
 switchport access vlan 15
 switchport mode access
 no ip address
 spanning-tree portfast
!
interface FastEthernet0/23
 switchport mode access
 no ip address
 spanning-tree portfast
!         
interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport mode access
 no ip address
!
interface GigabitEthernet0/1
 no ip address
!
interface GigabitEthernet0/2
 no ip address
!
interface Vlan1
 description WAN Connection to Firewall 
 ip address 192.168.100.1 255.255.255.0
!
interface Vlan2
 description School Vlan
 ip address 192.168.2.1 255.255.255.0
 !
interface Vlan10
 description Accounts
 ip address 192.168.10.1 255.255.255.0
!
interface Vlan15
 description Special Purpose
 ip address 192.168.15.1 255.255.255.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.100.254
ip http server
!
!
!
line con 0
line vty 0 4
 password xxxxx
 login local
line vty 5 14
 password xxxxx
 login local
line vty 15
 login
!
end

Thanks and regards

Sheik Mohamed Shahul

[Jon Marshall]

You won't be able to do this I'm afraid, at least not for all protocols.

The problem is acls are not stateful. So if you use an acl to stop vlan 2 and 15 from sending traffic to vlan 10 you also stop the return traffic back to vlan 10 ie your switch has no idea that the original packet came from vlan 10.

The solutions are -

1) with some switches the "established" keyword can be used with TCP only connections and this means if the connection was initiated from vlan 10 then the return packets are allowed.

You switch may or may not support it but as I say it only works for TCP.

2) reflexive acls would support all main protocols ie. TCP/UDP and ICMP but your switch very probably doesn't support these.

3) a stateful device eg. a router running a firewall or a dedicated firewall.

Your switch definitely won't support a firewall.

Edit - the above applies to all traffic. If however there are just specific ports you want to block then you may be able to write an acl that would achieve this so it depends on exactly what you are trying to block.

Jon

[Sheik Mohamed]

Dear Paul and Richard

I Tried to put acl  but Any established is not working .. So if any other way to block ..In case i can use cyberoam firewall it will block ???pls ASAP.

Ip access-list extended TST

Permit tcp 2.2.2.0 0.0.0.255 any established
Permit tcp 15.15.15.0 0.0.0.255 any established
deny tcp 2.2.2.0 0.0.0.255 any
deny tcp 15.15.15.0 0.0.0.255 any

permit ip any any

Sheik

[Jon Marshall]

How are you testing it ie. what are you doing to test it ?

Don't know about the specific firewall model but yes a firewall would do what you want but you would need to modify your configuration ie. you cannot route between all the vlans on the switch.

Jon

[Richard Burts]

I am not familiar with that particular firewall and so can not say much about it. But in general something that does stateful inspection, as most firewalls do, would accomplish the control that you need.

I agree with Jon's point about not routing between the VLANs and might go a step further and say that you need to disable layer 3 routing on the switch and make it perform only as a layer 2 switch.

HTH

Rick 

[paul driver]

Hello

Just following on from Jon's post , this seems to work for tcp, not tried it for anything much more indepth though.

Example:
Denying 2.2.2.0/24 - 15.15.15.0/24 to access vlan 10
Allow vlan 10 to access vlan 2 & 15
#########################################

vlan 10= 10.10.10.0/24

vlan 2= 2.2.2.0/24
vlan 15= 15.15.15.0/24

Ip access-list extended TST

Permit tcp 2.2.2.0 0.0.0.255 any established
Permit tcp 15.15.15.0 0.0.0.255 any established
deny tcp 2.2.2.0 0.0.0.255 any
deny tcp 15.15.15.0 0.0.0.255 any

permit ip any any

int vlan 10

Ip access-group TST out


res

PauL

[Richard Burts]

Paul

Jon was correct that the established parameter in the ACL entry works for TCP but not for UDP, ICMP, or other protocols. Also using the established parameter works much better when the access list is applied inbound.

HTH

Rick

[paul driver]

Hello Robert

I understand what you are saying regards other protocols  but in the case of svi interfaces and acl logic, I see it as being turned upside down -

outbound = traffic originating from outside the vlan
inbound = traffic origniating from within the vlan

Hence my acl was applied outbound for only establised traffic to be alowed into vlan 10

res

Paul

[Richard Burts]

Paul

My experience is that being an SVI does not change the use of in and out. From outside into the box is still in and inside the box to outside is still out.  And established works by looking at the ACK bit in traffic coming from outside.

HTH

Rick

[paul driver]

Hello Robert

Now youve got me doubting myself , which is very easliy done! -  but this is how I understand RACLS

On a nornal physical interface applied acl logic -

IN - coming into the inferface
OUT - going out of the interface

On a routed svi's -

IN - going out of the vlan
OUT -going into the vlan

Summary. The rule of thumb for the direction of the ACL on SVI above are:

ACL always have the form of

, The direction of the ACL SVI works as below:

• If it’s INBOUND (“ip access-group ACL out”), then it means “It’s going OUT TOWARDS the VLAN10 access ports.”
   
• If it’s OUTBOUND (“ip access-group ACL in”), then it means “It’s going AWAY from the VLAN10 access ports"
  
  
  res
  
  Paul

[Jon Marshall]

Paul

It all depends on where you look at it from but I don't see any difference between a physical interface and an SVI so for me -

inbound means traffic coming into the SVI ie. it must have come from clients on that vlan

outbound means traffic leaving the SVI ie. it must be going to clients in that vlan .

which you yourself have said.

Where we differ is simply in the use of inbound and outbound when referring to acls.  So when you say for an acl -

inbound = it  is going towards the vlan 10 clients ie. it is inbound to the vlan so you apply the acl outbound

I would call that outbound instead ie. it is going away from the SVI but i would still apply the acl outbound

outbound = it is going away from the clients in vlan 10 so you apply the acl inbound

I would say it is inbound ie. it is traffic going to the SVI but again I would still apply the acl in the same direction as you.

Basically I am looking at everything from the perspective of the network device because it is there you apply the acls whereas you are looking it from a client perspective because it is the client traffic you are filtering. I don't think it's a question of right or wrong as both approaches achieve exactly the same thing so there is absolutely no criticism intended.

Whatever works for you really.

Jon

[Richard Burts]

I have re-read this thread a couple of times and realize that there is a complication which I had not fully realized and which means that my response may not have been on the mark and which provides some credibility to Paul's suggestion.

My response was written from the perspective of how we usually implement "established" in an ACL. Typically we are dealing with an issue where our network has sent traffic to some external entity and we are examining traffic from that entity to identify what traffic is in response to sessions initiated from inside our network and to permit that traffic. And in that case the ACL is applied inbound on the interface where the traffic is received.

The complication that I overlooked is that all three of the networks are connected on the same layer 3 switch. So the traffic is not to some external entity but is to other VLANs in our network. One possible solution would have been an ACL inbound on VLAN 2 and an ACL inbound on VLAN 15 permitting TCP to VLAN 10 established. That would have been more traditional but it would have been a bit more complex. Paul's solution has the advantage of processing traffic from both VLANs in a single ACL. And for this environment permitting TCP traffic "established" with the ACL outbound on VLAN 10 probably does work.

HTH

Rick

[Jon Marshall]

Sorry I may have added to confusion.

I wasn't suggesting at any time Paul's acl wouldn't work ie. I can't see why it wouldn't and it saves having to have an acl for each of the other vlans.

I was just commenting on the definitions used by Paul and only to give my own perspective ie.