ESXi firewall not working

[virtualkitten]

Hi,

I have setup a firewall rule for the vSphere Client. What I want to achieve is that no one from any public IP can connect via SSH and/or vSphere Client.

So, following some information went to the vSphere and setup the rules. But I can still connect from my IP at home,

Any advice ? Do I need to reload the firewall ?

[cykVM]

Did you enter the private network/subnet in there from where connections are allowed (e.g. your local network)?

But it's a very basic firewall anyway, better to put up a real one in between.

[RichardBush]

Are you connecting to your IP from a IPv4 address ?

Just add the ip range of your network to the allowed, so for example 192.168.1.0 255.255.255.0, or if you wanted to allow only private ip ranges you could add all the below?

10.0.0.0 255.0.0.0 (10.0.0.0/8)

172.16.0.0 255.240.0.0 (172.16.0.0/12)

192.168.0.0 255.255.0.0 (192.168.0.0/16)

Add the ranges in the brackets

Rich

[CoolRam]

@RichardBush: has given how to pass the allowed IP range you need to pass. If you tried this way it will work.

[PaulWestNet · Accepted solution]

It sounds like you have given the ESX host a routable WAN IP and have it plugged into the Internet, which is pretty much asking for trouble. The ESX firewall isn't meant to be used as a hardened firewall exposed to the Internet scum of the world. Doing so will eventually lead to what the fellow in this post ended up with.

You are restricting remote IPs, but that host still has a routable IP, which means people can poke away at it and see if they can sneak around the firewall.

If you really insist on connecting the host to the Internet directly with no hardware firewall in-between, at the very least, install a virtual firewall on the host, give the WAN NIC to it exclusively, give a secondary NIC to the virtual firewall's LAN side on a separate vSwitch, and move your VMKernel management interface to the LAN side (don't do this unless you have a secondary NIC, or you may risk locking yourself out of your own host if the virtual firewall fails for whatever reason). That way, the only exposed IP address is the one that feeds into your virtual firewall - not a VMKernel management interface.

Using a virtual router would also give you the ability to set up VPNs and apply other rules that the ESX host itself simply can't do. It'll also let you take advantage of advanced features, like rate limiting, IP banning, maybe even an intrusion detection setup. Plus, you'll have better logs to view if something is going on. I'd recommend pfSense, but there are lots of options out there.

[RichardBush]

wow was early in the morning when I replied, I didn't even pick that up.

Just for clarity, id suggest you place a firewall between the outside and inside as per Paul's post above, this stuff shouldn't be routable from the outside.

Also adding those rules in would only stop ssh and vsphere host client, not connections to the other services, at the end of the day this firewall is very basic, and should only ever be used for reducing local network footprints. A firewall VM isn't a difficult thing to build out.

Rich in CYA mode..

[virtualkitten]

You are right. In everything.

This hosts is setup in a remote Datacenter, I do not have physical access to it and it is a standalone server...  some people recommends pfSense, but yeah, it has production sites so I need to take extra care. Not sure about what I will be able to do in terms of NICs, I do not think I can change that unless networking is virtual.

Do you have some more information on how to proceed ?

[virtualkitten]

I was setting up proper IP addresses.

The issue was: firewall was disabled, either this is the default or the previous system administrator disabled it.

Regards

[PaulWestNet]

The ESX firewall is definitely enabled by default. The first thing I do on a host when I first set it up is allow access to SSH through the firewall, so it's definitely active. The default configuration does expose port 443, though, of course, or your VI client wouldn't connect so you can adjust the firewall for other stuff *grin*.

Switching the configuration over can be easy or complex, depending on how the VMs are configured and whether or not there are other hosts with VMs on them that need to be able to reach the VMs on this host. If the VMs are using public WAN IPs, then you'll either need to switch those to private IPs after pfSense is set up, or you'll need to set up pfSense as a filtering bridge so that the internal VMs can continue using their existing setup (this is more complex on the pfSense side, but may be way easier than reconfiguring all of your existing VMs).

To make this work, you'll need 2 free IPs. One for pfSense so you can reach it to manage it, and one for the internal VMKernel management interface. Ultimately, the external VMKernel's IP will be released - but you don't want to do that until the very end, after you're positive everything is working and you can reach your new internal VMKernel interface through your pfSense setup and you can manage your pfSense (you can set up OpenVPN or something for remote access to pfSense, which is a good idea - make sure it works before you lock things down). You're working with a production environment, so the key is to be paranoid and make sure everything is tested as you go, so you don't lock yourself out of your host or pfSense.

The steps I'd take would be to create my second vSwitch and call it "LAN" and connect it to an unused NIC on the host (just in case pfSense goes down and someone needs to plug in a PC locally to manage the host). I like to rename the original vSwitch to "WAN", so it's more clear, but doing so will require you to edit all of your VMs and tell them the new name of the vSwitch on their NICs (why vSphere doesn't do this automatically, I don't know). Then I'd install pfSense, configure it for remote access via OpenVPN so I can manage it. I'd then make sure pfSense was going to start automatically on host startup, since it's now a critical VM you can't live without (I'd make it the first VM to start). I'd then create a VMKernel interface on my LAN vSwitch and enable it for management and give it an IP appropriate for the LAN network (it'll be a routable, if pfSense is going to be a filtering bridge, or a private if pfSense is going to NAT for you). Then I'd set up the firewall rules to get to my new VMKernel interface (open port 443, 80 (if you want), 22 (if you want), and 902 (VM console port) and test connectivity with the VI client to it to make sure it works and I can see the console of VMs (this is super important if something breaks somewhere). Once I'm sure my core setup is all happy and I can manage the host and pfSense safely, I'd set up my firewall rules for my VMs, then move my VMs from the WAN vSwitch to the LAN vSwitch one at a time and test to make sure my rules worked as I expected (reconfiguring the VM's IP to private IPs, if that's the route I went with pfSense). Once everything was working and no one was calling to complain that I'd just borked the server, I'd delete the VMKernel interface on the WAN vSwitch (I'd want to be absolutely certain I can reach everything before I did this).

Obviously a lot of this is going to take some time if you're not familiar with pfSense. Just test everything as you go.

Here's a quick diagram of the setup:

[Andreykms]

Thank you very much!