Fix:
Put a Custom rule into the Hosts firewall which allows the whole NAT Range to access the whole NAT Range. Incoming 192.168.0.0/24 allows all inbound from 192.168.0.0/24. (Replace NAT ip range with your own).

Unfortunately, I don’t have a Hyper-V box up right now… There are pictures here: http://sqlblog.com/blogs/john_paul_cook/archive/2008/03/23/using-wireless-with-hyper-v.aspx
and these pictures are pretty handy if you are able to mentally swap out wireless for wired. What sort of issues are you running into? I’m pretty slow to respond to comments ( day job keeps me pretty busy), but I’d be happy to help if I can clarify something…

Jim

Thanks for your patronage! I used to field this particular Hyper-V question a bit when I was with the Support Department, before I switched roles to internal assets. That being said, ServerBeach’s networking structure when it comes to secondary IP’s does require a little bit of extra work to function correctly.

Let me answer your question with two answers, the first being, yes you can do it. The second being, I recommend not. Let me explain how it can be done first:

Instead of creating reservations, you can click on the “Services and Ports” tab, and add each individual port that you want mapped to the private IP. Click “Add” give the service a name, select the incoming IP (public) and port, then define the outgoing (private) IP and port. Click OK, and that IP/Port is mapped.

When you set your reservations, and I can’t believe I didn’t note this above, if you click “allow incoming connections,” then every packet that comes in gets forwarded to the private IP. If you set this, whatever you configure in the “Services and Ports” tab gets overwritten by RRAS, and defaults to whatever is reserved. If you do not check “allow incoming connections,” then the private IP is not remotely accessible regardless of the settings in “Services and Ports.” It’s really a one or the other configuration.

That being said, I recommend forwarding the whole block using reservations, checking “allow incoming connections,” and performing packet filtering either outside the host (external firewall), or internal to the VM (windows firewall or iptables in the guest). Primarily, the reason I say this is ease of troubleshooting. If firewalling is handled either external to your host, or internal to your VM, then it comes naturally to look there than it would be to troubleshoot issues with RRAS, which IMHO, isn’t very robust. Furthermore, troubleshooting measures that incorrectly configure RRAS can quickly result in more VMs offline than the original outage.

There is a drawback to reservations in that the more packets that the VM handles rather than the host, there is a greater impact to performance (virtualized hardware translates into greater cpu time per transaction). However, I believe that ease of administration is ultimately more desirable than squeezing a bit of performance out of the VMs in what can quickly turn into a very long list of ports. This becomes very important when problems require urgent work.

Well, I hope this helps you out with setting up your Hyper-V environment. Please let me know if I can answer any more questions, and also, feel free to hit up our support guys and gals if you need any help with your server specifically.

Jim

EDIT: I just reread your comment, and I see that you have some services sharing IPs. I’d actually recommend getting more IPs in this case and going with a 1 IP per virtual model. They’re $1 per IP per month, so the outlay isn’t really that bad.

Primary ip address: 1.2.3.4
Secondary ip address: 1.2.3.5

1.2.3.4:80 -> 192.168.1.2:80
1.2.3.5:80 -> 192.168.1.3:80
1.2.3.5:25 -> 192.168.1.4:25

Thanks!

BTW I’m a SB-Peer1 customer.