5

We have a dedicated server with a hosting provider. We are running ESXi 6.0. The server has a single public IP which is currently being used for the management interface. The provider has also assigned us a /29 block so our VMs can have public IPs. We can only use 1 physical NIC, which I think is causing some of the problems.

They have told us that the default gateway of the IPs from this block should be set to the IP of the ESXi server. Whenever we try to configure this, VMs complain saying that the gateway is in a different subnet, which it is.

They have indicated that because of the way their network is configured, we need to route any IPs from the block they assigned us through the IP of the ESXi server. From what I know, ESXi doesn't support routing, making this impossible.

We've asked if they can assign this block (or even a single IP) to the server so that they are the same as the ESXi IP so we can use them on VMs, but they have told us that their network setup does not allow for this.

Ideally, we want to be able to assign these public IPs to our VMs so that they are directly accessible from the internet. Is there a way to do this? Are we missing something?

If the above isn't possible, is there a way for us to do port-forwarding/anything else, so that we can reach our VMs from the internet?

We have not changed any networking configuration in ESXi, so we still have just a single vSwtich with both the management network and VM network attached to it. This vSwitch is attached to a single physical NIC on the server, which all IPs are assigned to.

Happy to provide any additional information if needed.

Improve this question

2 Answers 2

Reset to default
6

Your hosting provider (Hetzner, at a guess?) is correct.

You will need to assign the single static IP address to your VMware server's VMK interface. This will allow you to connect to the server via the VMware console and create VMs.

Your hosting provider should be able to route your /29 subnet to the server's MAC address.

You will also have a single vSwitch (I would personally rename this to "Public" for sanity) configured within vSphere, which is attached to your physical network card.

You will need to create a second vSwitch (for sanity, I recommend calling it "Private") which is not attached to any physical network interfaces.

Once these two vSwitches are set up, you can then create a virtual machine with two vNICs - one in each vSwitch. Use whatever "router" OS you like (typically something like ipfire or pfSense will do fine), and configure it to NAT packets between your WAN (Public) and LAN (Private) vSwitches.

To use your /29 IP addresses, you will need to create VMs attached to your Private vSwitch, and then NAT port-forward as necessary.

Improve this answer
6
  • Hi Craig. Thanks for that. What IP address would the WAN interface of the router have? This is the part that was confusing me.
    – user284587
    Commented Jun 19, 2015 at 12:28
  • 1
    It would have one of the IPs from the /29 block.
    – GregL
    Commented Jun 19, 2015 at 13:12
  • By the way. Hetzner has a nice detailed documentation on how to set up IPv4 subnets with a VMware ESXi machine (that is hosted by them): wiki.hetzner.de/index.php/VMware_ESXi
    – VFrontDe
    Commented Jun 20, 2015 at 16:25
  • On ESXi 6.7 I can't assign a vNIC to a vSwitch but to a "Port group", which is assigned to a vSwitch. I'm not sure if it makes any difference.
    – Matthieu
    Commented Nov 7, 2018 at 12:28
  • On the router OS (ipfire in my case), what IP address should be assigned to the "red" network? If only one public IP is available, and already used by the ESXi server itself, where can the NAT take place?
    – Matthieu
    Commented Nov 7, 2018 at 12:30
0

I would really, really urge you to not put your ESXi management interface on the Internet directly. Your only security control is then your password, which gives you full keys to the kingdom.

I would suggest that you install a Unified Threat Manager (UTM) like pfsense or Untangle to be your router with a public IP address. Your network would look like this:

Internet ---> VSWitch1 ---> UTM ---> VSwitch2> --- Virtual Machines

Where:

  • VSWitch1 is connected to a real NIC that faces the Internet
  • UTM is connected to VSWitch1 (with one of your public 29-bit IP addresses) and VSwitch2 (with a private IP address)
  • VSwitch2 is not connected to any real NICs
  • Virtual Machines are all connected to the NIC's and have private IP addresses (like 192.168.0.0/24 or 10.0.0.0/8)

With this configuration, you will use the UTM to perform NAT so that your virtual machines have access to the Internet (and vice-versa using port-forwarding, where required). These UTM's come with Firewall features, IPS features, and all the good stuff to protect your network.

For ESXI access, I would actually recommend you make a VPN to your private network. Put your VMKernel on the private network (like 192.168.0.101/24). This way, you authenticate with your VPN and all your traffic is encrypted. The VPN is a feature of the UTM's I mentioned.

Plus! Bonus! They're free and open-source :-)

If you must have direct Internet access to your ESXI - I would still recommend at least putting a firewall/NAT between your ESXI and the Internet, otherwise you're left to the ESXi's [non-existant] security features.

Improve this answer
6
  • 3
    "I would really, really urge you to not put your ESXi management interface on the Internet directly." -- What happens when you have storage issues and need to connect directly to the VMK without any of your VMs running?
    – Craig Watson
    Commented Jun 19, 2015 at 15:59
  • I would mitigate that risk with a dedicated machine. If that's not available, have redundant storage. If that's not available, what about an IP KVM? There are many ways to mitigate that risk without exposing your crown jewels. Do not fix availability issues by reducing your integrity to nearly 0.
    – Ryan
    Commented Jun 20, 2015 at 17:07
  • IP KVM would only work for physical console access, not the VMware Infrastructure Client. Decent measures like good passwords and restricting the interface to only a whitelist of IPs remove the need for this level of paranoia.
    – Craig Watson
    Commented Jun 20, 2015 at 18:12
  • 1
    If you can't think of a better solution than leaving your management interface on the Internet, then I would at least suggest following my solution and putting a 1:1 NAT translation on it so that traffic at least passes through the UTM. Any script kiddie with a 0-day or exploit on an unpatched server is going to beat a password. A whitelist is very dangerous - what if your IP changes?
    – Ryan
    Commented Jun 22, 2015 at 11:43
  • 2
    What happens if you need to debug your server and your datastore is corrupt or unmountable? Your UTM wouldn't be bootable, and you wouldn't be able to access your locked down management console via anything other than an IP KVM, which will give you CLI access only, no VI Console. I dispute the "sloppy comment - if you're in an enterprise setup (and this is ServerFault, so you should be), you should have a static, public IP address. If you're outside of that network, you should have a VPN. I have painful experience of using a UTM on a "cluster in a box" and locking myself out of my own server.
    – Craig Watson
    Commented Jun 22, 2015 at 12:00

You must log in to answer this question.