Requests have slowly been increasing for secondary IP addresses to be used in virtual server configurations. We encourage the use of cool new technologies at ServerBeach, but there are a couple considerations to be made when setting this up on our servers.

The configuration most folks expect to use is bridging (to borrow VMWare's terms), wherein each virtual machine (with their individual secondary IP) appears to have a separate public interface present on the network. There are two problems with this.

The first is that there is no gateway to be specified for our secondary IPs. Knightfoo explains the reason behind this in a previous related post:

"We keep our primary and secondary IP addresses in separate blocks mostly for security and tracking reasons. All secondary IP addresses are statically routed to the primary IP of the server, so no one can steal your additional IP addresses even if they configured them on their own server. We can also keep track of primary IP usage and see if someone is using a primary IP address that they should not be using."

Since there is no default gateway, the virtual machine doesn't know where to send packets. Now, you may be able to get away with specifying the same gateway that the primary IP uses (though it is on a completely different subnet), but this is not at all recommended, bringing us to the second problem.

When a bridging configuration is used, each Virtual machine has a separate interface on the public network. Naturally then, each interface has a virtual MAC address different from the physical interface on the server. As you already know, automation is one of the things that sets ServerBeach apart from other dedicated hosting providers. These automated systems use MAC addresses for accounting and inventory purposes, so you can start to imagine the problems caused when foreign MAC addresses are found on the network. Again, you may be able to scrape by with this configuration, but it is not recommended and we cannot be held liable for any issues you encounter.

As a work-around to these significant "virtual" road-blocks, we suggest configuring the virtual machine with a private IP on an internal virtual network. To borrow VMWare's terminology for the sake of continuity, this is known as host-only networking. Once this is done, you can use iptables, or RRAS, and NAT to forward traffic destined for the secondary IP address through to the private IP on the internal virtual network. There have been concerns that vhosting will not work on the virtual machine with this configuration, but I have successfully tested this and it does work.


The following is an example of how to do this in Linux. Please keep in mind that even though this uses iptables, there is absolutely no form of security in these rules. They are simply a starting point for routing purposes. Securing the systems is up to you.


1. With Host-Only networking, VMWare uses an internal DHCP server for the virtual server. Do this once, and then set the IP statically.

/etc/sysconfig/network-scripts/ifcfg-eth0 on RedHat Virtual Machine:

/etc/network/interfaces on Debian Virtual Machine:


2. Enable IPv4 Forwarding on Host Machine using one of the following:

3. Add the secondary IP address to your Host Machine.

4. Route traffic destined for the secondary IP through to the VM on internal network/interface (Web and SSH in this case):

5. Route traffic originating from the VM internal interface out through the secondary IP address:


6. Route outgoing traffic destined to the secondary IP to the VM internal interface (allows connections from Host Machine to VM):

7. Allow forwarding to your VM


I hope that helps. Windows VM tips to follow...

CONFIGURE VMWARE

1. VMnet1 is the Host-Only Adapter. Note the subnet this adapter is on in the VM Host Network Settings (ie., 172.16.98.0/24).
2. Set the Virtual Machine to use Host-Only networking.

CONFIGURE THE VIRTUAL MACHINE OS

1. Set a static IP address on the VMnet1 subnet (172.16.98.128/24)

ENABLE ROUTING AND REMOTE ACCESS ON THE HOST MACHINE

1. Click -> Start -> Administrative Tools -> Routing and Remote Access
2. Right Click on Server#### (local) -> Configure & Enable Routing & Remote Access
3. Click -> Next on Welcome Window
4. Select Custom Configuration Click -> Next
5. Select NAT and basic firewall Click -> Next
6. Click -> Finish

CONFIGURE ROUTING AND REMOTE ACCESS ON THE HOST MACHINE

1. Routing and Remote Access should be running on the server now
2. Expand out the Server
3. Expand out IP Routing
4. Select NAT/Basic Firewall
5. In the details pane Right Click and select New Interface
6. Select Local Area Connection and Click -> OK
7. Network Address Translation Properties Window will open
8. Select Radio Button for "Public Interface Connected to the Internet"
9. Select the check box for both "Enable NAT on this interface" and "Enable Basic Firewall for this Interface"
10. Click on the Address Pool Tab
11. Click the Add button and add your secondary IP address. The "Start Address" and "End Address" will be the same in most cases.
    
    *NOTE* You do not want the secondary IP address configured in the TCP/IP Properties of the Host machine.
    
    
12. Click the Reservations button and enter your static IP mappings. That is, specify that you want traffic on your secondary IP mapped to your VM's internal IP.
13. Click on Services and Ports Tab (This is the firewall configuration)
14. Select the services you wish to allow on your primary IP. Select the "On This Interface" radio button for the public interface and put 127.0.0.1 in the Private address field.
15. Add the services you wish to allow on your VM. For the Public address, enter your secondary IP address. The Incoming and Outgoing port are going to be the same. The Private Address will be the internal IP of the VM.
16. Be sure you enable Remote Desktop for the Primary Interface otherwise you will lose access to server.
17. Click Apply and Okay.
18. In services.msc, make sure that RRAS is set to start automatically and Windows ICS is disabled.

RANDOM NOTE #1

When configuring and experimenting with the RRAS firewall, create a batch file to stop the service in case you forget to allow RDC or otherwise render the system inaccessible.

Then add the batch file to the scheduler and have it run some time after you apply your changes. This saved me from having to a create a ticket on a couple of occassions...

RANDOM NOTE #2

To get the VMWare server to start up automatically after a reboot, you can edit the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Run

New string value
Data "C:\Program Files\VMware\VMware Server\vmware.exe -l"
(vmware -l attaches to localhost)

Good luck!

SETTING UP HYPERV ON THE SERVERBEACH NETWORK WITH SECONDARY IPS MAPPED

The following link has some great pictures not included here. You'll have to ignore the fact that this is for configuring HyperV for a wireless interface, and also that BRIDGING IS NOT SUPPORTED at ServerBeach. Our switches in general have PortFast enabled, and sometimes bridged networking can cause spanning tree loops, and is grounds for immediate Acceptable Use Policy suspension. http://sqlblog.com/blogs/john_paul_c...h-hyper-v.aspx

I'll add some nice little pictures here once I get some screenshots together.

CONFIGURE HYPERV

1. Configure an "Internal" HyperV network
2. Set each Virtual Machine to use the Internal network and assign them and your HyperV host on the correct subnet (in this example 10.0.0.1 for the host and 10.0.0.10 for the VM).

ENABLE ROUTING AND REMOTE ACCESS ON THE HOST MACHINE

1. Click -> Start -> Administrative Tools -> Routing and Remote Access
2. Right Click on Server#### (local) -> Configure & Enable Routing & Remote Access
3. Click -> Next on Welcome Window
4. Select Custom Configuration Click -> Next
5. Select NAT Click -> Next
6. Select your public interface
7. Select your Internal HyperV interface
8. Select "I will set up name and address services later" Click -> Next
9. Click -> Finish

CONFIGURE ROUTING AND REMOTE ACCESS ON THE HOST MACHINE

1. Routing and Remote Access should be running on the server now
2. Expand out the Server
3. Expand out IP Routing
4. Select NAT/Basic Firewall
5. Right-click your public interface. Select properties
7. Network Address Translation Properties Window will open
8. Select Radio Button for "Public Interface Connected to the Internet"
9. Select the check box for both "Enable NAT on this interface"
10. Click on the Address Pool Tab
11. Click the Add button and add your secondary IP addresses. The "Start Address" and "End Address" will be the same in most cases.

*NOTE* You do not want the secondary IP address configured in the TCP/IP Properties of the Host machine.

12. Click the Reservations button and enter your static IP mappings. That is, specify that you want traffic on your secondary IP mapped to your VM's internal IP.
13. In services.msc, make sure that RRAS is set to start automatically and Windows ICS is disabled.

NOTES #1

When configuring and experimenting with the RRAS firewall, create a batch file to stop the service in case you forget to allow RDC or otherwise render the system inaccessible.

Code:

net stop "remoteaccess"

Then add the batch file to the scheduler and have it run some time after you apply your changes. This saved me from having to a create a ticket on a couple of occassions...

NOTE #2

RRAS is really finicky about the interfaces installed on the server. If an interface is changed in any significant way, it'll have to be disabled and reconfigured.

Hyper-V is also similarly finicky about its virtual networks. I can't count the number of times I had to remove and recreate networks. Thankfully, this was rather painless with only one VM to propagate changes to.

If you should encounter any difficulties with adding your additional VMs to the server, try resetting HyperV networking, individual VM network binding (in the VM's settings), confirming physical host interfaces, and then reconfiguring RRAS in this order.

NOTE #3

Those who have had HyperV configuration problems solved it by disabling TCP/Offload Engine. http://social.technet.microsoft.com/...8-d22aca6154ee
http://support.microsoft.com/default...b;EN-US;904946

So if this applies to you, run on the host and on any 2008 VMs:

$ netsh int ip set global taskoffload=disabled

and add the following registry key to any 2003 guests:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\DisableTaskOffload

This is a DWORD entry that should have a value of 1.