• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2903
  • Last Modified:

Subnetting help on a 172.16.x.x network

We are building a network inside of vmware/vsphere 5.1 and need some guidance in whether we should expand the subnet mask or manage everything through a routing table.

Subnet 1
Core Devices (router, switches, servers, etc.)
172.16.0.X /24

Subnet 2
Data (PC's, printers, etc.)
172.16.1.X /24

Subnet 3
VoIP (phones, etc.)
172.16.2.X /24


Question:
Firewall (virtual network device)
We currently have a NIC on it for the core subnet. Do we/can we expand that NIC's subnet mask to say, a /16 in order to fully communicate with everything? ...
Or do we create a NIC on the firewall for each subnet and add routes in the router? ...
Could we also bind a NIC to multiple subnets?

Just not sure what the "best practice" is when everything is entirely virtual, including the router and firewall.
0
Paul Wagner
Asked:
Paul Wagner
  • 3
  • 2
  • 2
1 Solution
 
Jon SnydermanCommented:
Definitely don't switch to a /16 subnet.   You will end up with some odd behaviors that will be difficult to track down\resolve and your security will be flawed by having that open broadcast domain.

Depending on the virtual firewall brand or vendor that you are using, if it supports VLANs, interface subsets, what your security needs are on each subnet, etc, either one of the other two solutions would be completely acceptable.   Best practice, IMO, would be separate virtual interfaces.  But it depends on the firewall capabilities and how secure your want each subnet to be from each other and how different you want the rule sets to be.   If you can provide some more details, we may be able to go a little deeper in the recommendation.  

~Jon
0
 
Paul WagnerFriend To Robots and RocksAuthor Commented:
Well, two of the subnets will need specific DHCP options applied to them: One for VoIP and the other for Citrix machines.
As always, I'll need every subnet to talk to the core subnet.
The firewall is a software firewall running on a VM of Server 2008.

What other details are you looking for?
(I was already leaning to the second option and just wanted confirmation)
0
 
Jon SnydermanCommented:
Yes, where you need isolated DHCP broadcasts on 2 of the 3 subnets and you will want prioritization on the VoIP NIC, I would definitely go with separate virtual NICs.   Also, you will likely want full communications between 1 and 2, and 1 and 3, but communications between 2 and 3 can and should be limited.

Good luck
~Jon
0
The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

 
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
I would do the following:
1.  Expand one subnet to 172.16.1.x /22 where all your servers, printers and PCs reside as you don't want the PCs to go through router to communicate.  This will give you best performance
2.  Create a /24 subnet for network device management
3.  Create a subnet for VoIP

Enter each subnet belongs to a vlan of its own.

For VMware I will create following networks:

1.  NIC 1:  primary for management network, backup for backup network
2.  NIC 2:  primary for backup network, backup for management network
3. NIC 3 and 4:  vmotion network
4.  At least 2 NICs:  VM network and NICs configured as trunk ports. Use vmxnet 4 as adapter for VMs and configure VLAN on the NIC in OS
5.  At least two NICs configured for VLAN 100.  This is required as some VMware appliances do not allow VLAN options on the NIC in the OS.
0
 
Jon SnydermanCommented:
Mohamed's solution is a very good one, but it will require re-configuring the existing devices on all three networks.   Is this an option?  The /22 will make one network out of 172.16.0.0-172.16.3.255 and all devices should be reconfigured with the new subnet.   The VoIP network will need to be moved to 172.16.4.x or something like that.    If this is an option, then I would agree with Mohamed that eliminating the routing overhead from the firewall VM would be ideal.

Another option also requiring a change, but potentially less painful, would be to use a /23 and move the devices from 172.16.2.x to 172.16.0.x.  Given most of that is DHCP, this should not be too difficult.   Then the existing 172.16.1.x network could remain in place as well as the VoIP network at 172.16.3.x.   The 172.16.2.x network is eliminated or used as your vmotion network.

~Jon
0
 
Paul WagnerFriend To Robots and RocksAuthor Commented:
@Mohammed Khawaja
Are you saying to add these NICs to the Firewall?
0
 
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
No, what I am saying is that in your environment, you have a router.  You create the VLANs on your switches, you create a sub-interface on your router for each VLAN.  When you install VMWare, you create your networking.  It is a good practice to create networks based on VLANs for specific purpose.  As an example, I keep all my management IPs in a VLAN (lets call it VLAN1).  I have a VLAN for my DMZ (VLAN2), VLAN for PCs and servers (VLAN3), backup network (VLAN4), vMotion (VLAN5), etc.

All NICs that are in your ESXi host connected to the switch, it is a good idea to configure ports as trunk ports.  This will ensure you can you the NIC in VMware for various purposes as well as you are not traversing the router when communicating amongst systems that talk to each other quite alot (i.e. servers and workstations) as they will not cross the router.  This will also ensure that the NIC you have assigned for management can be used for backup or vmotion, etc.

If you do not have a good idea of networking or how should networks and VMware should be configured, I suggest you get some help.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now