Vlan Security

alliasneoalliasneo Posts: 186Member
Hey Guys,

Just going pretty heavily in to VLAN configuration and I keep hearing that VLAN's can help with network security because it segments the PC's off from the rest of the network. At the moment though I find this hard to believe because at first if you just configure the switch with VLANS, then fine yes the PC's can't communicate. But as soon as you get to say a 'router in a stick' scenario you're enabling intervlan routing and everything pings just fine - so where is the security in this?

Comments

  • drkatdrkat Posts: 703Banned
    We can apply ACL's to permit/deny traffic from vlans - with router on a stick it does allow us to route between them but we have more control over who gets to what
    Married to the game but she broke her vows. That's why my bars are full of broken bottles And my night stands are full of open bibles
  • pham0329pham0329 Posts: 556Member
    ^what he said.


    When all your hosts are on one vlan, there's really no easy way to prevent one device from communicating with the other. When you have them in separate vlans, you can implement ACL, or not even route between them.
  • billyrbillyr Posts: 186Member
    Remember also that all broadcast and multicast traffic is confined within that VLAN (and the trunk links) so you can cut down on traffic sniffing.
  • thedramathedrama Posts: 291Member
    alliasneo wrote: »
    Hey Guys,

    Just going pretty heavily in to VLAN configuration and I keep hearing that VLAN's can help with network security because it segments the PC's off from the rest of the network. At the moment though I find this hard to believe because at first if you just configure the switch with VLANS, then fine yes the PC's can't communicate. But as soon as you get to say a 'router in a stick' scenario you're enabling intervlan routing and everything pings just fine - so where is the security in this?

    Different VLANs mean different subnets in a single physical network. This also means you can assign hosts to different subnets/networks. That
    leads you separate broadcast domains. In such a scenario, once, one of the hosts try to send a packet inside that single network, the packet is restricted to relevant broadcast domain unless a router is implemented and provide the inter-vlan communication.

    That means security between different departments of the same company.
    Monster PC specs(Packard Bell VR46) : Intel Celeron Dual-Core 1.2 GHz CPU , 4096 MB DDR3 RAM, Intel Media Graphics (R) 4 Family with IntelGMA 4500 M HD graphics. :lol:

    5 year-old laptop PC specs(Toshiba Satellite A210) : AMD Athlon 64 x2 1.9 GHz CPU, ATI Radeon X1200 128 MB Video Memory graphics card, 3072 MB 667 Mhz DDR2 RAM. (1 stick 2 gigabytes and 1 stick 1 gigabytes)


  • cisco_troopercisco_trooper Posts: 1,439Member ■■■■□□□□□□
    pham0329 wrote: »
    ^what he said.


    When all your hosts are on one vlan, there's really no easy way to prevent one device from communicating with the other. When you have them in separate vlans, you can implement ACL, or not even route between them.

    Well, you can use switchport protected to keep every single device in the same VLAN from talking to any other device within the same VLAN, provided they are all on the same switch. I have actually started using a local VLAN per switch in my deployments specifically so I can implement this feature. It prevents layer 2 access between end users on the same switch, and then I use ACLs on the layer 3 SVIs to prevent communication between any end user VLANs. I love it and it has even helped in the prevention of malware that can spread laterally across an enterprise. What you are left with is that no end user workstation can communicate with any other end user workstation with ACLs to allows end user workstations to access services in server farms, data centers, and of course the internet when applicable.
  • pham0329pham0329 Posts: 556Member
    I didn't say you can't do it, I said there's no easy way to do it! If I'm going to do switchport protected, I might as well do private vlans as it provide more control. I haven't really implemented private vlan/protected ports in a production environment, but I can imagine the confusion it would cause when a host on a vlan can't communicate with another host on the same vlan
  • cisco_troopercisco_trooper Posts: 1,439Member ■■■■□□□□□□
    switchport protected is pretty easy, but your milage may vary. In smaller environments you're more likely to have people with files shares off their workstations, shared printers, and other non-sense that is flat out not allowed in larger environments. In a large environment there is no good reason for end user workstations to be communicating. If you have a particular workstation in the VLAN that other workstations need to access for some reason you can take that individual workstation out of switchport protected and every machine in that VLAN will be able to communicate with it. It really is a very nice feature. You can do private vlans but they aren't as easy and are better suited for slightly more complex requirements.
  • alliasneoalliasneo Posts: 186Member
    This is interesting. So if I were to implement switchport protected on a 24 port catalyst, no other device could ping another device through that switch without the means of a Layer 3 router for intervlan routing?

    I was thinking, well if two pc's can't communicate what's the point? but then I thought well for e-mail and things it would go off to a server and then back in to your network and the same for networked hard drives. so you wouldn't ever need to ping/directly communicate with another PC right?
  • cisco_troopercisco_trooper Posts: 1,439Member ■■■■□□□□□□
    alliasneo wrote: »
    This is interesting. So if I were to implement switchport protected on a 24 port catalyst, no other device could ping another device through that switch without the means of a Layer 3 router for intervlan routing?

    I was thinking, well if two pc's can't communicate what's the point? but then I thought well for e-mail and things it would go off to a server and then back in to your network and the same for networked hard drives. so you wouldn't ever need to ping/directly communicate with another PC right?

    You will need to have a full understanding of your specific environment before you implement something like this. In a proper design your workstations don't need to have the ability to communicate with other workstations.

    To answer your question, if you have machines switchport protected on the same VLAN on the same switch those machines won't be able to communicate with one another. If you have machines switchport protected on the same VLAN on different switches, the machines won't be able communicate with machines on the same switch, but WILL be able to communicate with machines on the remote switches - switchport protected is only enforced locally. If you have machines switchport protected in separate VLANs, they will be able to communicate as long as proper routing is in place between the two VLANs and there are no ACLs preventing the communication.

    If you are considering deploying this make sure you lab it up first to solidify your understanding of the behavior of switchport protected.
  • pham0329pham0329 Posts: 556Member
    alliasneo wrote: »
    This is interesting. So if I were to implement switchport protected on a 24 port catalyst, no other device could ping another device through that switch without the means of a Layer 3 router for intervlan routing?

    When you place a port in protected mode, it can communicate with any other port in the same vlan, but it cannot communicate with another protected port. However, this only work on the local switch, which means that a protected port on one switch will be able to communicate with a protected port on another switch

    cisco_trooper, have you tested this with VoIP? Doesn't RTP establishes a direct connection between 2 phones for audio?
  • cisco_troopercisco_trooper Posts: 1,439Member ■■■■□□□□□□
    pham the direct RTP establishment depends on the PBX setup. In my environment the RTP sessions are run through the PBX with no direct connections between the two phones. I don't know why that is setup that way, but it is. I think it is a remnant from telco people who didn't know what the heck they were doing. The company grew REALLY fast a few years ago and wasn't always staffed with proper talent.

    That is a great point. +1.
Sign In or Register to comment.