Routing different subnets across hyper-V virtual switch

[NickC_UK]

I am having a nightmare trying to get a hyper-V server to pass traffic between two subnets.

Existing server is 2003 with two NICs, one is internal network the other goes to ADSL router. 2003 simply and automatically routes all traffic between the two subnets, no problem.

Difficulty starts when I try and do the same on the new 2012 R2 hyper-V virtual server. It seems that when one of those NICs is a hyper-V virtual switch it no-longer passes traffic between the two subnets, why not?

To explain the senario further, we have one hyper-V server with two NICs and one virtualised Domain Controller server.
NIC 1 (hyper-V virtual switch) = 192.168.0/24 - main Internal company network.
NIC 2 = 192.168.1/24 - connects to ADSL internet router

Question is how do I route traffic between these two subnets and where is the best place to do this, on the hyper-V host or on the virtualized server?

RRAS might sound like a good idea but, as I have established, on 2012 R2 that can only be installed if accompanied by IIS and Windows Internal Database among other bloat. Not the sort of things one should install on a hyper-V host.

 

[CubanlB]

The best place to do this routing would be at a router, but it seems you want a VM to be doing this, and a Windows server VM at that.

you will need 2 hyper-v switches, which it looks like you have. Give the VM that has routing enable a synthetic nic on each switch, configure IPs, and you should be good to go.

If the IP is different than the previous "router" or gateway, you will need to change hosts or DHCP to point them at the correct gateway.

RRAS is generally not used to do routing, other than for VPN clients.

Vyatta Core or Sophos UTM are two linux based firewall/router packages that work with hyper-v synthetic nics. Most certainly do not put RRAS on the hypervisor.

 

[NickC_UK]

The best place to do this routing would be at a router, but it seems you want a VM to be doing this, and a Windows server VM at that.

you will need 2 hyper-v switches, which it looks like you have. Give the VM that has routing enable a synthetic nic on each switch, configure IPs, and you should be good to go.

If the IP is different than the previous "router" or gateway, you will need to change hosts or DHCP to point them at the correct gateway.

RRAS is generally not used to do routing, other than for VPN clients.

Vyatta Core or Sophos UTM are two linux based firewall/router packages that work with hyper-v synthetic nics. Most certainly do not put RRAS on the hypervisor.

At the moment I was intending to do the routing on the hyper-V host but that doesn't seem to work, any idea why that won't work?

If I have understood correctly you are saying to create two hyper-V virtual switches. Then in the virtualised domain controller use and configure both these networks and set [FONT=&quot]IPEnableRouter[/FONT]=1 on this VM. Have I got this correct.

 

[CubanlB]

It should work, I'm still wondering why though.

I currently have a somewhat similar setup in a hyper-v environment.

One physical nic in the hyper-v host is connected to my DSL modem and that nic is assigned to a vSwitch that has one vm interface connected to it. That same vm has another interface connected to the virtual switch connected to the rest of my lan. It acts as a router just fine.

Still not sure why you want to do this with a windows server though. It should work, it just seems to be an odd way of doing what you are trying to accomplish.

 

[yinan]

Switches don't route

 

[kevnich2]

A switch won't do any routing. A switch only works at L2 with frames. You need either a L3 capable switch or a router to route between subnets. If your server is on two different networks or has a vlan capable NIC in it, you can play around with it to get routing to work but honestly easier to just get a physical L3 switch and use that like it was intended.

 

[NickC_UK]

IPRouterEnable still doesn't seem to work like it did in server 2003.

New attempt at this:

Internal Network workstations
192.168.0.x
gateway: 192.168.0.10
DNS: 192.168.0.10

Hyper-V Host - NIC1
Switch 1: 192.168.0.5
gateway: 192.168.0.10
DNS: 192.168.0.10

Server1 (virtualised) - NIC1
192.168.0.10
DNS: 127.0.0.1

Server 1 - IPRouterEnable

Server1 (virtualised) - NIC2
192.168.1.10
gateway: 192.168.1.1

Hyper-V Host - NIC2
Switch 2: 192.168.1.5
gateway: 192.168.1.1

ADSL router (192.168.1.x)
192.168.1.1

Problem is traffic from Internal Network can ping Server1 NIC2 (192.168.1.10) but cannot ping 192.168.1.5 or 192.168.1.1. Yet we know that direct traffic from 192.168.1.10 gets to 192.168.1.1 because RDP in to Server1 on that address works.

Can anyone explain either what I have wrong here or why this doesn't work in the way 2003 used to.

 

[grendel19]

Hyper-V hosts cannot route, their role is just a host for VM's, nothing else. The IP you assign to a physical NIC installed on that Hyper-V is just for management. From what I understand, you're trying to use Server 2012 as the router for two different subnets. I'm assuming you're using 192.168.0.0/24 and 192.168.1.1/24, and your Hyper-V has two physical NICs, with the management IP assigned to the "internal" virtual switch.

As a previous post mentioned, all you have to do is create 2 virtual switches on the Hyper-V, give them names you'll recognize (i.e. internal, ADSL). Then on the Server 2012, add two virtual NICs, bind one to the "internal" virtual switch and the other to the "ADSL" virtual switch. Then within Server 2012, create static IP's on both virtual NICs, one with the "internal" IP and the other with the "ADSL" IP. Make sure they correspond to the right virtual switch you created on the Hyper-V host.

Install RRAS and create the routing and NAT if necessary, pretty straightforward there. Point your workstations to the right gateway.

Caveat: I have a similar set up at home but I use VMWare instead, so my knowledge with Hyper-V is limited, but I'd imagine they are similar with regards to this. I also use 2008R2 instead doing the RRAS role instead of 2012, but again, can't be that different.