Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.
  • VLAN 2 - Normal Users
  • VLAN 3 - IT
  • VLAN 4 - Voice

    1. One DHCP Server ( 2008R2 )
    2. Two Juniper EX2200 PoE in a stack at the local office.
    3. 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

share|improve this question
Are you designing it like this because you can or because you have a legitimate need to? What's the purpose of isolating users from the production servers? That seems counterintuitive. What's the purpose of the IT VLAN? – joeqwerty May 17 '11 at 3:34
up vote 7 down vote accepted

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:

  • / 19
  • / 19
  • / 19
  • / 19

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.

share|improve this answer
+1 for host-based firewalls: unless you're talking DMZ isolation, it rarely works as it requires alot of diligence to get right and maintain. – gravyface May 17 '11 at 2:59
@gravyface: Thanks. I've seen too many situations where well-intentioned sysadmins threw boatloads of time into "compartmentalizing" a network only to give up when some crappy application ends up needing virtually unlimited access. I'd love to have stateful firewall rules sitting between all my VLANs but it's usually just not practical. – Evan Anderson May 17 '11 at 3:05
I have to chuckle a bit on this comment " It involves a lot of communication between the application administrators and the network administrators" I have heard that 3 times now but, you are correct its only me. The reason am doing this is a security, bcast control and organization. I think for a company of 110 people this is way to complicated. Correct me if am wrong but I can still eliminate bcast issues with only a few vlans ? and thus keeping it simple and easy to manage. Also the above subnets and vlans are not what i will use thats just an example. – BrandonB May 17 '11 at 16:49
As far as using a /19 i was under the impression that a /24 is the highest i should go ? – BrandonB May 17 '11 at 16:53

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.