Hyper-V and SBS: Noob Networking Advice

Associate
Joined
18 Mar 2011
Posts
5
Location
Cambridge
Hi, guys.

I just have some noob questions regarding network setup.

Our charity will shortly be upgrading our existing server to SBS 2011. I intend to virtualize the environment using Windows 2008 R2 w/Hyper-V role assigned, installing SBS as a guest. A dedicated NIC will be used for the VM (assigned to a virtual network from within Hyper-V) plus one NIC for dedicated management of the host. We're currently using a SonicWall TZ210/Linksys ADSL Router as our Edge device with LAN Gateway 192.168.16.254/24 (this subnet corresponds to our existing LAN setup). The WAN IP is assigned via our ISP and our Edge devices are configured accordingly.

Overall, it looks like this:

Internet <-> Edge (Linksys Router/SonicWall Firewall) <-> LAN <-> Server

I'd like to have the host server on a different subnet to that of SBS e.g. 172.16.0.1/24, VM on 192.168.16.1/24. My question is how would go about configuring my Edge device to accommodate for 2 different subnets?

Would setting up the network like this work?

Edge: 192.168.16.254/24 (Gateway)
Host: 172.16.0.1/24
VM: 192.168.16.1/24 (External)

Would I assign the gateway IP from within my VM as 192.168.16.254? What about the host? Would that also be the same? Assuming so, would I then need to setup a routing policy within the SonicWall to allow the gateway to resolve correctly since they'd be on different subnets?

I'd also like to be able to RDP to both Host and VM from the WAN as well. I'm comfortable configuring the SonicWall but my networking theory is coming up a little short on how to go about implementing the above configuration. I'm also a little confused as to how I'd setup the NAT policies on the SonicWall to accommodate for both of these subnets and how to negotiate incoming WAN requests for different LANs (e.g. port forwarding rules for SBS would be different from those of Hyper-V host). For instance, how would the edge device know how to distinguish between an RDP request from the Host and VM via the WAN?

I'm getting in a bit of a muddle on how to best approach this.

Argh!!!

:(
 
Last edited:
Soldato
Joined
8 Nov 2002
Posts
9,128
Location
NW London
TBH i would say that you are overcomplicating things by having separate subnets. Is there any particular you have to do this?

I'm guessing you're going to say "security", but i can't see how it would improve that compared to having host and VMs on the same subnet. If you want to block people from being able to access it just use windows security and add extra rules to the windows firewall.
 
Associate
OP
Joined
18 Mar 2011
Posts
5
Location
Cambridge
Wow. Thanks for the quick reply, oddjob62!

In truth, there's no particular reason why I've opted for 2 different subnets other than for me being a pedant (I like to keep things organised wherever possible). Our security is pretty well configured (touch wood). I simply liked the idea of separating out the networks according to role.

Eventually, we'll be intending to install a second VM on the host server as well as another 2 VMs on another physical server (all the VMs would need to be on the same network).

E.g.

Host1: 172.16.0.1/24
Host2: 172.16.0.2/24

VM1: 192.168.16.1/24
VM2: 192.168.16.2/24
VM3: 192.168.16.3/24
VM4: 192.168.16.4/24

I could certainly put them all on the same subnet. Even then, I'm still a little confused on how the NAT policies and port forwarding rules on our SonicWall would need to be configured and distinguish requests between host and VM. For instance, I use my WAN IP address to RDP into our existing SBS server when I'm offsite. How would I accomplish this if I intend to use virtualisation since I'd effectively have 2 servers to now negotiate?

I know this seems dumb. I'm clearly missing something here...
 
Soldato
Joined
8 Nov 2002
Posts
9,128
Location
NW London
Well it depends on how many external IPs you have and how many machines you want to RDP to.

RDPing directly to each server is usually a bad idea, as you either need an external IP for each server or you need to remap the RDP server to a different port.

I know very little about sonicwalls, but i would try to get some kind of VPN set up. You then VPN to the office, and RDP to any of the servers using their internal IP address.
I believe sonicwall have a client that you install for VPN connectivity, but that's as much info as i can give you i'm afraid.

Once again... i would definitely recommend having everything on the same subnet.

We have 40 physical server, a 4 node hyper-v cluster running 60 VMs, and see no need for separate subnets.
 
Associate
OP
Joined
18 Mar 2011
Posts
5
Location
Cambridge
Thanks, oddjob62. I forgot to mention we only have 1 external WAN address (sorry).

I think it's beginning to make a little more sense now. I suppose I could simply enable RDP for the host only and then manage the VMs from within Hyper-V (no need to RDP to a VM then). I'm assuming this is possible? VPN certainly isn't a problem.

Just another quick question: Would I essentially orientate the setup of my SonicWall as if I were setting up it for a physical SBS installation? For instance, I currently have multiple NAT entries and firewall rules to manage traffic for SharePoint, Exchange etc. I assume I'd simply need to setup an additional address object within my SonicWall to accommodate for the fact that it's now hosted in Hyper-V? For instance, for RDP I'd simply point it to the host instead of SBS but very little else would need to be changed.
 
Soldato
Joined
8 Nov 2002
Posts
9,128
Location
NW London
I assume I'd simply need to setup an additional address object within my SonicWall to accommodate for the fact that it's now hosted in Hyper-V? For instance, for RDP I'd simply point it to the host instead of SBS but very little else would need to be changed.

Yeah I assume you currently have SBS running on an old server. You just need to change all your port forwarding rules to point to the new SBS server's IP once it's up and running. Once again, i can't tell you where these settings are as i have very little expereince with SWs
 
Associate
Joined
12 Feb 2010
Posts
300
Crunchers, you're getting too hung up on the fact you're using VMs. Since all the WAN communication is via IP, all the config on the Sonicwall is based on the IP you assign within the SBS i.e. exactly the same as if it were a dedicated box.

If you want to have multiple subnets, then you simply assign the Sonic to have a 2nd LAN address on the new subnet.
 
Associate
OP
Joined
18 Mar 2011
Posts
5
Location
Cambridge
Yeah I assume you currently have SBS running on an old server. You just need to change all your port forwarding rules to point to the new SBS server's IP once it's up and running. Once again, i can't tell you where these settings are as i have very little expereince with SWs

Thanks, oddjob62. I believe that makes things a little clearer now. (and yes, SBS is currently running on the old server - sorry).

Crunchers, you're getting too hung up on the fact you're using VMs. Since all the WAN communication is via IP, all the config on the Sonicwall is based on the IP you assign within the SBS i.e. exactly the same as if it were a dedicated box.

If you want to have multiple subnets, then you simply assign the Sonic to have a 2nd LAN address on the new subnet.

Do you mean I should bridge both LAN subnets, vsmora? I've done this on one of our SW TZ100s in another office to bridge both wireless and wired networks that reside on different subnets. Would the gateway then resolve correctly from the host/VM even though one would reside on a different subnet?

As an aside, I'm guessing that it still wouldn't allow me to manage particular incoming WAN requests (e.g. RDP to different servers) without needing to resort to a second WAN IP (i.e. another phone line).
 
Last edited:
Associate
Joined
12 Feb 2010
Posts
300
Each system needs a gateway that is on a matching subnet. Config the port forwarding as though they were 2 seperate Sonic boxes. Where there is a conflict because 2 systems want the same incoming port (e.g. RDP) then decide which system gets the default and remap the other to accept a non-default port on the Sonic (e.g. 8389 maps to host:3389). Finally on the Sonic open any ports that you want to allow to traverse subnets. If you're Sonic can't assign a 2nd LAN address, then either upgrade/replace it or you'll have to rethink how you implement things.

You'd only point the Sonic to the host for SBS requests if the host was configured to be doing it's own bridging/NAT between the subnets, but that makes the network hideously complex. Better to keep all firewalling and NAT in one place.

Edit: As odjobb mentioned, if remapping ports then it can get complex to manage if you have too many.
Edit2: If you use the Sonic as described to route only certain ports between the subnets then they remain firewalled. If you do a straight bridge and allow anything to go between then there is next to no point in using different subnets.
 
Last edited:
Associate
OP
Joined
18 Mar 2011
Posts
5
Location
Cambridge
Another reason why i would avoid having different subnets is that it would mean your sonicwall becomes a single point of failure, as well as network bottleneck.

Understood. Although, the SW is a single point regardless of whether I decide to use two LANs as opposed to one; if it fails, the network would go down either way. Granted, your point on bandwidth contention is something I hadn't considered.

Each system needs a gateway that is on a matching subnet. Config the port forwarding as though they were 2 seperate Sonic boxes. Where there is a conflict because 2 systems want the same incoming port (e.g. RDP) then decide which system gets the default and remap the other to accept a non-default port on the Sonic (e.g. 8389 maps to host:3389). Finally on the Sonic open any ports that you want to allow to traverse subnets. If you're Sonic can't assign a 2nd LAN address, then either upgrade/replace it or you'll have to rethink how you implement things.

You'd only point the Sonic to the host for SBS requests if the host was configured to be doing it's own bridging/NAT between the subnets, but that makes the network hideously complex. Better to keep all firewalling and NAT in one place.

Edit: As odjobb mentioned, if remapping ports then it can get complex to manage if you have too many.
Edit2: If you use the Sonic as described to route only certain ports between the subnets then they remain firewalled. If you do a straight bridge and allow anything to go between then there is next to no point in using different subnets.

If memory serves, I think I came across a white paper from SonicWall a while ago on how to configure the TZ210 for using two LANs. I'll see whether I can find it...

Agreed on leaving the NAT/firewall management on the SW.

I'd thought about using port mappings as a way of managing connections between different subnets. I agree, it may become complex if there are too many.

Agreed on bridging LAN subnets - pointless to do since I may as well use one subnet! Silly suggestion by me in hindsight.
 
Soldato
Joined
8 Nov 2002
Posts
9,128
Location
NW London
Understood. Although, the SW is a single point regardless of whether I decide to use two LANs as opposed to one; if it fails, the network would go down either way. Granted, your point on bandwidth contention is something I hadn't considered.

It shouldn't... the switch should handle all LAN traffic if everything is on one subnet. The SW should just handle traffic between LAN and Internet.

If you start making the SW handle inter subnet traffic, then if it dies, inter subnet traffic dies.

Actually... thinking again, i guess you are putting the SBS server on the same subnet as the workstations right? in that case a separate subnet for the HV Hosts makes even less sense.

That's the last i'm going to say on the issue.
 
Associate
Joined
20 Oct 2002
Posts
2,016
Location
Space, the final frontier
Hold on a minute, if you are using SBS 2011 as you domain controller with additional servers, there is no need to have 3389 open at all (if you want to forward a different port to the Hyper-V host then thats up to you), but SBS is a TS Gateway and with an SSL certificate in place, you can all RDP into your network and any servers/PC's via SSL, meaning for SBS you typically just need 25, 443 and 987 forwarded to the SBS server and 1723 if you want it to handle incoming VPN connections for you domain.
 
Back
Top Bottom