Firstoff, the Cisco 2821 is just a router. I don't know where you've gotten this "layer 2 router" business from (the statement is an oxymoron in itself), but a 2821 is a perfectly capable IP router.
You don't want to extend a layer 2 broadcast domain across a VPN. You won't like how it performs.
Let's call your existing location "site A" and the new location "site B". Let's call the networks:
- Site A Data subnet - VLAN id 1 - 192.168.0.0/24
- Site A Voice subnet - VLAN id 2 - 192.168.1.0/24
- Site B Data subnet - VLAN id 1 - 192.168.2.0/24
- Site B Voice subnet - VLAN id 2 - 192.168.3.0/24
In your 2821's, you'd setup an IPSEC tunnel between the sites. Here's a decent example using a static key: http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094634.shtml
Once you've got that, you'll create VLAN interfaces on the routers on each end, assigning the routers IP addresses in each VLAN:
Router in Site A:
interface FastEthernet0/0
no ip address
no shutdown
interface FastEthernet0/0.1
encapsulation dot1q 1 native
ip address 192.168.0.1 255.255.255.0
interface FastEthernet0/0.2
encapsulation dot1q 2
ip address 192.168.1.1 255.255.255.0
Router in Site B:
interface FastEthernet0/0
no ip address
no shutdown
interface FastEthernet0/0.1
encapsulation dot1q 1 native
ip address 192.168.2.1 255.255.255.0
interface FastEthernet0/0.2
encapsulation dot1q 2
ip address 192.168.3.1 255.255.255.0
Assuming you've set the IPSEC tunnel up properly w/ the proper addresses being excluded from NAT, traffic between the various subnets in the sites will be transparently encrypted and sent to the other end. The routers at each end will, because of their VLAN interfaces and static routing table entries, automatically tag traffic with the appropriate VLAN tags and drop them onto the Ethernet.
You'll need to configure the switches at both ends with trunk ports to connect the routers to, and you'll have to figure out how to integrate the Site A router into your existing routing topology re: the existing ASA-5505, but this should give you enough to go on to get started.
Keep in mind that, fundamentally, if two hosts are configured with IP addresses in different subnets those hosts will need to communicate through one or more routers with interfaces in their respective subnets in order to communicate. A "layer 3 switch" isn't anything more than a router with the ability to create virtual interfaces that are exposed to the broadcast medium of a VLAN.
re: #1 - To conceptualize VLANs, just imagine that the ports in each VLAN are a physically disperate switch. In a flaw-free VLAN implementation (where traffic can't "leak" between VLANs) that's the effective behavior-- each VLAN acts as a separate switch. ACLs applied at layer 2 will name only MACs (and, if the switch supports quasi-layer 1 ACLs, ports). Any ACLs naming IP addresses, TCP ports, etc, aren't layer 2 ACLs. (There may be switches that have "layer 2.5" functionality whereby they examine the payloads of IP packets without actually being able to route packets, but I'd be wary of such things.)
re: #2 - VLAN tags allow the traffic of multiple VLANs to be carried on a single port, typically called a "trunk". You can conceptualize them as virtually subdividing a connection between two devices into smaller "ports" that each carry the traffic for a single VLAN. There's nothing you can do with "trunking" that you couldn't do by using multiple non-trunked ports, but using trunk ports and tagging packets allows you to carry the traffic of multiple VLANs between physically disperate switches w/o using a large number of physical ports for inter-switch links.
re: #3 - Routing IP between different subnets (irrespective of VLANs-- it's typically convenient to have a 1:1 relationship between VLANs and subnets, but it's not required) requires a routing capability. If you need to route IP between different subnets then you need a router. It could be an embedded layer 3 entity in a switch, or it could be a "router on a stick". Anything that can route IP between different subnets is a router. re: ACLs - Like I said in #1-- I'd be wary of a device that did "quasi layer 3" functions. Either it's a router or it isn't.
A couple decent background questions:
Best Answer
As Joeqwerty already noted, you're approaching this with an inadequate fundamental understanding, combined with vaguely-defined goals. You are setting yourself up for failure, downtime, and security holes. Rather than just answering your questions as asked I'm going to indulge in a little "vLAN 101" tutorial which might be a bit more useful for you.
You seem to have a few fundamental misconceptions about vLAN segmentation and how it fits into network architecture, so let's roll ALLLLLLL the way back to the beginning for a minute:
From a network architecture level you can take the very simplistic view that a vLAN is nothing more than a separate switch, not connected to any other switch (vLAN).
If you look at vLANs in this way it becomes relatively clear how to use them: When you don't want machines in
Group A
to be able to talk to machines inGroup B
you put them in separate vLANs, and force them to traverse a router (ideally one with firewall functionality) to talk to each other.Under nearly all circumstances it's better (and easier) to do this by also putting the machines in different IP networks (subnets) -- Machines within a vLAN are in the same subnet, and can chat amongst themselves as much as they want, but if they want to talk to someone outside their vLAN it's also going to be outside their subnet, so they get handed off to their default gateway, which can handle the security concern of who can talk to whom under what circumstances.
So vLAN architecture in 11 easy steps:
Figure out which machines form logical groups. These are your vLANs
In a very simple environment this could be
Web Servers
andDatabase Servers
.In more complex environments you may have lots of groups, and you may combine multiple groups in a single vLAN -- This is an architecture decision you have to make.
Figure out an addressing scheme that suits your vLANs.
If you're supremely lucky every vLAN will fit into a /24 and you'll be able to build a topology based around that. If you aren't that lucky figure out which vLANs need bigger (or smaller) blocks.
Draw what you have done so far on paper.
Figure out which vLANs need to talk to each other.
What ports/services should be open between vLANs/Networks?
What other conditions need to exist for your environment to function?
Draw what you came up with on paper. Make sure it's sane, then convert it into firewall/router policy.
Draft a firewall/router configuration. Ideally play with it in a test environment.
Draw your switch on paper and map which ports will go to which vLANs.
It's helpful to physically group connections so that they're in the same logical vLAN, but this isn't strictly necessary.
Turn your switch drawing into a switch configuration. Ideally play with it in a test environment.
Clean up your drawings on paper. The logical drawing should look somewhat like this:
(The image has been shrunk to obscure stuff you don't need to read)
Get someone else to look at your design.
You can ask on Server Fault, but it's better if someone familiar with your environment looks at it as they're more likely to catch potential breakage.
Take a weekend and turn your logical design into a physical reality.
(It should go without saying that you should have a rollback plan in case things go horribly wrong, but I'm saying it anyway.)
(If you are VERY good you might be able to skip some of the "Draw it on paper" steps above, but I don't recommend skipping that your first time.)
Re: the two specific questions you asked:
You can't. Breaking your network into vLANs will require an outage window - you will have to reconfigure your switch, move machines into different logical networks, configure routing, probably move some cables around, etc. etc. etc.
Plan for an outage starting at 5PM Friday and extending over a weekend, ESPECIALLY if this is your first time designing a properly segmented network - you will spend some time debugging things that break.
Can you? Yes.
Will it buy you anything in terms of security? Not really.
Will it make the entire project 10 times harder? Absolutely.
Should you design a network this way? NO.