Link to home
Start Free TrialLog in
Avatar of aando
aando

asked on

How do I keep Subnets from seeing each other in Virtual Environments?

Users in a "multi-tenant" environment can see each other. I am trying to figure out how to limit that. My predecessor set this up and it became a problem because they were sharing the same NAS for backups. One company got a CryptoLocker that infected everyone's backups and took down multiple companies. My company provides hosting for 5 different companies to access network shares. The way the network is setup is that I have a Domain called CompanyX.com. There are 5 different Servers that are part of this Domain. They are all running HyperV. They are all on the IP Scheme 10.16.1.x. On each of the HyperV Servers is a different company's Virtual Servers. Each company has their own IP scheme of 10.16.2.x or 3.x or 5.x etc. They all share the same Firewall/Gateway of 10.16.0.X. When they log in to their network, they only get their shares and can only see their servers. HOWEVER, if you do a simple network scan or search the network, you will see the other Servers. I want to keep them from seeing the other servers but still allow them to use the same Firewall. How can I accomplish this?
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

Use different Physical Networks or Virtual LANS (VLANS)
SOLUTION
Avatar of Matty-CT
Matty-CT

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
From your description, it's not clear to me if the Hyper-V VM Servers are on the same hypervisor or on separate ones.
If the same, then there may be something you can do with the virtual switch(es).  
It's not clear to me, with the NAS setup, whether inter-subnet communication is intended or NOT intended.  Which is it?
It almost sounds like it's intended but some of the consequences aren't wanted.

One simple way to share the same internet gateway is to put each subnet behind a commodity router.  Most routers have their own firewall function.  If you do this then all of the subnets can see the gateway subnet via their WAN/Internet ports but not into the other subnets unless you add a route explicitly for that purpose.  A common NAS could be on the upstream gateway's LAN subnet that every subnet below can reach.  Of course, I'm assuming that there are separate WIRES going to each company; thus LAN.  If there aren't separate LANs then you have to be thinking VLANs.  
Some will complain that there is "double NAT" in doing this.  I've not found real world situations where it matters.  If there's going to be port forwarding from the internet then it's a bit more complicated but clearly worthy of consideration.
Avatar of aando
aando

ASKER

Mr. Hancock, How would I use VLANS on Virtual Servers that share the same physical Host and Physical Networks? Would they still be able to use the same Gateway/Firewall?

Thanks, ME
Avatar of aando

ASKER

Matt-CT that is some great information and you are correct the Subnet was 255.255.0.0 which I assume the last IT guy did so that they could share the same backup storage. The Host use Altaro on the Host to backup to a shared NAS.

Does the VLAN tagging have to be done on the Switch, Firewall or both?

Do you know if Replication from Host to Host will still work if I VLAN things out? I'm assuming they will because the HOST are all on the same Subnet and IP scheme. The Host do replication between each other for Redundancy.

I get changing the VM's to /24 to limit seeing the other subnets. I'm just not 100% sure what I have to do with the Virtual Switches in order to get to the Firewall so traffic can be routed in and out.

Thanks, ME
Avatar of aando

ASKER

Fred Marshall,

1. The HOST are all on the same subnet and Domain so that I can use one backup solution and so I can manage Replications between the different Host. And there is one really big NAS of 24TB that stores all of the backups for these servers. So we did want to share the backup resources and the Firewall, but not the consequences that came with that. A previous IT guy set it up and now I am trying to figure out how to make it more secure and work without spending huges amounts of money.

2. But the HOST have Virtual Servers on them that have their own Domains with AD, Terminal Servers, File Servers etc. Because they are all on a 255.255.0.0 they can share these resources on the host network but then comes the problems with that.

Thanks, ME
*edit* Whoops. We both posted around the same time. I'll read your post and respond later. Hey, it's Saturday night....

Individual VLANs can share the same "firewall" but they cannot share the same IP address space as that's the point. This is why you would have to create unique networks for each customer if you want to be able to isolate them from each other.

In our server farm we use a virtual security appliance. It has a series of VLAN tagged interfaces, WAN, DMZ, LAN 1 through 4. Each is a separate address space such as 10.0.10.0/24 and 10.0.20.0/24 (etc.) Firewall rules allow certain allowed traffic to cross across certain VLANs, and others are completely private. It gives you great flexibility in your network design in terms of defining very granular rules for IP traffic.
It always concerns me a bit to bring VLANs into a discussion about network architecture.  Not that it doesn't belong, but it's an implementation detail in some sense isn't it?  Perhaps that viewpoint seems strange to some.  But the notion is that there is little that VLANs do (other than share copper) that can't be done with REALLANS  :-)  .  Perhaps designing a network with REALLANS on paper isn't such a bad abstraction.  Then, when it comes time to implement then use VLANS if that seems appropriate - which it often is.

Here's an example, we introduced a VOIP system that had its own internet connection.  We didn't want that internet connection to be part of our main network so it had to be on another LAN.  
The higher-level architectural approach would be to introduce a new LAN.  Run new cables and use a different IP range.  Well, if it were truly a separate LAN then the IP ranges could overlap (just like your nextdoor neighbor can use the same subnet that you are using) but that could get to be confusing to the humans working on it).  But, within this architecture is a separate gateway / firewall for the VOIP system as well as separate wires and ports and switches where needed.
The practical solution says that running new cables is expensive and unnecessary IF there's some kind of technology available to use the existing cables and ports.  Well, the phones already support trunked VLAN technology and can daisy-chain off  wall port into a computer on the same desk.  So, we set up a VLAN through all of our switches.  The VOIP gateway/firewall plugs in at the upstream end on the VOIP LAN or VLAN100 or ... whatever.  The phones pick it up at the other end and strip out data to the workstations on their own, original, LAN which is now also VLAN1.  Having VLANs is simply  a communication mechanism that provides time-division multiplexing of the cables.  Packets or frames travel like red and green railroad cars on the same track and within the same train while sharing spatial/temporal space.

So, that's how I'd approach solving this problem:
1) conjure up an architecture of LANs
2) consider how it might be implemented with VLANS if that seems useful.
Iterate back to #1 until the two match.

The commodity router approach that I described uses the same firewall and the same IP address space at the gateway connection for everyone even though they can't "see" each other.
It uses different IP address spaces for each company LAN.  The common storage device could be on the upstream gateway LAN that everyone can access.
Now, as Matty-CT describes, these actual (or notional?) downstream routers can be combined into a single device and the company LANS can exit from individual ports on that device.
In that case, I guess I'd likely put the NAS on a separate downstream VLAN/subnet and route between it and the companies' LANS/VLANS.
While the device manfucturer probably DOES call the LAN ports "VLANS", it's not clear that they represent VLANS externally at all because of their separate ports and copper.  But, inside the device they may actually co-exist with tagging, etc.  Or, maybe they can support trunked LAN ports.  It all depends on the manufacturer but this, again, is about implementation.

In your case, it seems to me that virtual switches and routers may help implement some of these ideas.  Certainly, each server VM can have its own IP address range on the LAN side.  It all depends on the number of NICs or VNICs.  But I'm no expert on doing that.  Andrew Hancock *is*.
Yes you are going to have to re-design your network from scratch, and then have all the VLANs connected and route through the single firewall and gateway - the gateway IP Address will be different for each Client.

So you should have

1. Client VLAN
2. Client Subnet
3. Client Firewall Rules
4. Client Gateway

which is unique for all clients.

It's a major piece of work, which should have been in place before you started multi-tenanting.

I think you will find a whiteboard is handy for your design.
Avatar of aando

ASKER

Been working on this and still hitting some bumps. So if I move all clients to their own VLANs, and route traffic out to the internet via the Firewall and rules, will I still be able to use Microsoft Replication between the host Servers of the individual VM's even though they are on different subnets?

AND will I be able to backup the VM's to shared storage such as a NAS?

Thanks, ME
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of aando

ASKER

Reviewing all of the answers I believe I got some very good help in coming up with a solution and plan of action. While I think all of these gave solutions to what I am trying to accomplish, the details of some were better than others. And in IT details make up the difference. Thank you gentlemen for your help.
Avatar of aando

ASKER

Reviewing all of the answers I believe I got some very good help in coming up with a solution and plan of action. While I think all of these gave solutions to what I am trying to accomplish, the details of some were better than others. And in IT details make up the difference. Thank you gentlemen for your help.