Am deploying and designing a new network for our sourly damaged design. I have never designed a network from the ground up, by my self. The simple run down is this :
- VLAN 1 - Production at the data-center. 10.10.0.0/24
- VLAN 2 - Normal Users 10.10.20.0/24
- VLAN 3 - IT 10.10.30.0/24
VLAN 4 - Voice 10.10.40.0/24
- One DHCP Server ( 2008R2 )
- Two Juniper EX2200 PoE in a stack at the local office.
- Two Juniper EX4200 in a stack at the data-center.
The issue I am confused about is I don't want to allow normal users accesses to prod. but, I need to allow them accesses to exchange, citrix, IM and a few other servers that are classified as production. How do people normally do this ? Do I just assign there port access to VLAN 1 that kind of seems like am defeating the purpose of having them or do I separate the servers that are needed by normal users and put those in VLAN 2 ? My last thought is do I only allow them external access to exchange i.e. RPC or HTTP ?
Thanks guys
In short, the devices that route traffic between your various subnets (assigned to various VLANs) need to enforce communication security policy. At minimum, this means using routers (or devices with router functionality) that support stateless access control lists. If you want to get fancier you might use devices with stateful filtering functionality (typical stateful firewalls, Linux iptables, etc).
I think you may have a simplistic conception of what it means to not allow "normal users access to production". The path you're heading down involves charting out the various protocols (TCP and UDP ports, typically) that the client applications will need to communicate with on the server computers (some of which, in the case of Microsoft RPC, are dynamic by default). Once you've figure out how that communication is supposed to work you build access control lists (or firewall rules) to allow the required communication while denying all other traffic.
This is a hard row to hoe. I've seen very few environments where this was actually completely thought through and implemented. It involves a lot of communication between the application administrators and the network administrators (or, if you're one in the same, a lot of studying software documentation). There will typically need to be a lot of testing, and in many cases you're going to learn that "boutique" software application developers haven't ever taken the time to figure out what protocols their applications use to communicate (and often just assume a flat, open network between the client and the server).
In the end you may find that you'll have better luck running host-based firewall rules and being fairly lenient with your intra-VLAN access control lists / firewall rules, not necessarily because that's the right thing to do but because it's the feasible thing to do. Good luck!
As an aside: Seeing your planned subnets increasing by powers of 10 in the third octet says the same thing as your statement "I have never designed a network from the ground up, by my self." If you want to allow room for growth in those subnets consider doing something more like:
Even if you start using those various subnets as /24's you'll have room in each to grow up to /19's (with 4 /19's available for future use, too). With the non-contiguous subnets you're proposing in your answer you're wasting IP space or creating networks that can't be summarized with a single CIDR route.
It is a reasonable plan to split your servers by VLAN but I agree with @Evan that trying to do it by port is virtually impossible, keep the servers for 'real' users completely separate from those used for development. The developers will hate it but firewall them and their test/dev environment off completely if at all possible.
Technically it would be best to avoid using VLAN 1 for anything involved with users or servers, it is often used as the default VLAN for your network devices.
Depends on the number of users you have, but having one of anything is almost always bad, even if it is 'just' a DHCP server.
I mostly agree with @Evan about the subnets, but would not get too carried away with the subnetting and would stick with /24s. If you are in a situation of needing more hosts then add another VLAN, that's why they exist and having a design where you cannot (or it is too complication to) add another is a fundamental flaw which should be addressed early.
The numbering convention for VLANs should also be something other than 1(!),2,3,4, use separate ranges for users, servers, and development.