Home / server / Questions / 438834
Accepted
Abel
Asked: 2012-10-17 00:37:59 +0800 CST

Where to start for setting up hostname NAT behind one external IP address?

  • 772

Not sure I use the right terms here, which is basically why I am asking (with the right terms I could google it for sure).

I have "one big server" with Windows 2008, with several virtual machines (linux, win7. win2k8) on it. The server is accessible with a public IP address. I would like to enable the following, and just don't know where to start:

  • place websites on different virtual machines (i.e., VM1 hosts a.com and VM2 hosts b.com)
  • sites should work with http and https (ssl) protocols
  • allow remote desktop or similar RDP on each VM
  • allow other protocols, like webdav, scp or ftp, to each machine

I kind of assume I need a VPN for the remote desktop access and I need some kind of host-based or host-based + protocol-based NAT (if that's what this is).

This seems like something that has been done a million times already, I just don't know where to start, what software to use or simply what to google for. Also, I'm afraid SSL wouldn't work this way because the hostname is not visible before the handshake.

windows-server-2008

2 Answers

  1. Best Answer

    There's really a lot to cover in your question, but I'll focus on the SSL website part as it has real limitations beyond skill level/knowledge; it would make sense to break up the rest of the question into smaller chunks if you need specific help for VPN configuration, WebDAV, FTP, etc.

    If you only plan on hosting a few SSL websites or they will be wildcard sites (i.e. *.example.com) and you have a reverse proxy server in front, then you can stick with the one public IP address. If you need multiple domains (example.com, example.net, foo.com, bar.com, etc.) then you might be able to pull off a Subject Alternative Name (SAN) or UCC certificate installed on the reverse proxy. There's a handy chart on wikipedia that shows you a list of popular certificate vendors and how many domains you get with their offering; Global Sign offers up to 40 with their certificate.

    You could also roll with alternative ports (https://vm1:443, https://vm2:444 and so on) and the appropriate NAT rules (in a firewall in front of your VMs) but that's not usually desirable for public sites.

    Now, The reason why you can't just let the server(s) handle the different sites with SSL is because of how SSL works: the SSL conversation (handshake) happens before the host header ("hostname") is sent from the client and interpreted by the server terminating the SSL connection, such as a web server like Apache or IIS or a reverse proxy/web server like nginx. This is because the server doesn't "know" what certificate to present at that point and will (usually) only present the default (or first) certificate defined in the configuration. This "default" SSL certificate can be a Subject Alternative Name (SAN) certificate or a wildcard certificate and this may be fine for your needs.

    Server Name Indication (SNI) is a newish alternative (and actually an extension of the SSL/TLS protocol, which allows the client to specify the host header as part of the SSL conversation) to the multi-SSL site issue but is held back by the aging browser population and is only available in the IE7+ (Vista+ only too), Firefox 2+, etc. so may not be appropriate for your needs if you're expecting the unwashed masses to hit up your SSL sites.

    Because it sounds like you're trying to become some sort of a hosting provider (which is a whole other can of worms), I would want to get as large of a block of IPs from my ISP/colo provider as I can and either proxy ARP or physically assign a public IP address to the VM as part of the provisioning process and let them get their own certificates, etc. Stuff will just work better without NAT and will be less administrative overhead. If each VM will be multi-tenant (i.e. commodity "shared hosting" with as many sites you can stuff on a VM as possible), then you can probably pull off a combination of SAN certificate/IP address, but keep in mind that you can't just add/remove domains to the certificate whenever you please: you have to go through the certificate request/signing process again and they may charge you for it again.

    I would also be very careful to protect the host (the "one big server") and assuming you're using Hyper-V, dedicate a physical NIC (i.e. don't include as a virtual network in your Hyper-V configuration) to the remote management of the box, protected by a real (hardware) firewall, and establish some flavor of secure connection (like an always-on IPSec tunnel), preferably on a separate/guaranteed Internet connection* or at least a public IP on a different block outside of your "client" block(s) for firewall ACL purposes and for QoS. I'd also want to see if your server supports IPMI (DRAC in Dell speak) and use it along with your dedicated physical NIC as part of your management network that's not accessible from the public Internet; this will allow you to get bare metal access to the box so you can reboot it, do firmware upgrades, etc. remotely.

    *This dedicated connection requirement may not be an issue at a managed facility where they will have likely taken their own steps to ensure/guarantee (with an SLA) uptime/bandwidth/resiliency.

    • 1

  2. Im not a windows user but I can give you the right terms which you can google and find out how it is done windows.

    What you are looking for is a "Reverse Proxy" which routes your websites to local ip addresses of VMs. In my case I have used nginx as reverse proxy. I hope this helps, let us know if you need anything else.

    • 0