Unable to access WebAdmin when HA Active-Passive is enabled.

I contacted our Sophos UTM reseller, they stated that a virtual and physical HA config isn't a supported configuration due to the hardware differences between the virtual and physical machine.

Franc.

I contacted our Sophos UTM reseller, they stated that a virtual and physical HA config isn't a supported configuration due to the hardware differences between the virtual and physical machine.

Franc.

Have you tested the hints in this tread?
https://www.astaro.org/gateway-products/hardware-installation-up2date-licensing/44614-utm9-active-passive-ha-vmware.html

Ralf

Yes I have. The problem is not that it doesn't work, but the issue is that it's not supported. Our reseller isn't allowed (by Sophos) to provide support when such a config is encountered.

I'm not sure how Hyper-V handels MAC Adresses, but the problem in VMware is that the Virtual Switches can't handle the different MAC Adresses for the same VM on different hosts. i don't know the exact Issue, but I always thought that this is the same Problem in Hyper-V.  The last time i had the UTM on a Hyper-V i had to change the settings on the UTM and on the Hosts (i think).

The issue with ESXi vSwitches is that they short circuit the switching process a little in order to improve performance. In a situation like an HA pair, a typical switch will see the mac address on more then one port and happily register that address on both ports. Both Master & Slave see the traffic but only the master responds.

In a vSwitch things happen a bit differently. The switch sees that it has a mac address present both on a vm's virtual port, and on the virtual port corresponding to the physical interface. The vSwitch assumes, rightfully so most of the time, that there's no possible way this guest's mac address can exist both inside and outside of itself, so it drops the external from it's forwarding table.

What happens now to all guests on the same host as the slave is they reach out to the UTM's virtual mac but the vSwitch, instead of forwarding the traffic to the both the slave vm, as well as out the physical nic, only sends it to the slave vm, which does not respond at all (it's essentially sleeping) so traffic never gets out of the host box, meaning all the guests on that ESXi host lose routed access both in and out of the host.

Which is why the virtual mac has to be disabled as per Sophos' instructions to MrGoodBytes. The only other part I'd add to those instructions, is to reboot the ESXi host if possible after rebooting the UTM vm's. ESXi has no facility for pruning invalid mac addresses (other then internal timeouts), which gave me some grief in my lab when I first started playing with this.

Thanks for the clarification. Is this also the reason that it's not supported to have a mix of physical and virtual machines in a HA pair?

And what about the suggestion that UTM should disable the use of virtual mac addresses when it detects it's running in in virtual environment? Wouldn't that solve the issue. Now people have to bump to this thread or other ones, once they notice that the HA stopped working entirely once activated in a virtual environment.

Yes I have. The problem is not that it doesn't work, but the issue is that it's not supported. Our reseller isn't allowed (by Sophos) to provide support when such a config is encountered.

I'm assuming by physical & virtual HA you mean a software license running on own hardware with a UTM vm as backup? Mixing an Appliance & vm definitely isn't allowed (or even works afaiak) because the licensing model is different from appliance to software/virtual.

If the physical/virtual mix is just a software license, one way you can work around the mix is to turn the dedicated UTM hardware into a Hypervisor and run just the UTM on it as a guest. Then it's a basic virtual/virtual UTM HA pair and is now a supported setup.[;)]

Yes I mean running on own hardware, so a physical software license and a virtual software license as backup. That isn't supported according to our reseller. Mixing hardware appliances I'm aware of that that's not allowed.

About the latter, that's indeed the trick, but quite 'dirty' to introduce a virtual layer just because of that ;-)

Thanks for the clarification. Is this also the reason that it's not supported to have a mix of physical and virtual machines in a HA pair?

As I understand it, The main reason it's not supported to have a mix of physical and virtual nodes in an HA setup comes down to hardware capabilities. If you mix a physical node and a virtual node, there are no guarantees that the underlying hardware functions the same, and you can run into issues where the config worked on the physical node, but fails on the virtual node due to quirks of the virtual nodes 'hardware' (typically nic capabilities).

About the latter, that's indeed the trick, but quite 'dirty' to introduce a virtual layer just because of that ;-)

It is and isn't. Yeah, it's another layer to manage and adds complexity when things go wrong (that's why the slave exists, cya for when the primary goes down) but it does make things easier in many ways.

You have consistent hardware across platforms, so when that decrepit old clunker of a Dell finally kicks the can, you can move the primary over to that shiny new IBM your reseller sold ya. [:D] (can you tell I'm an IBM fanbois?) No need to worry about hardware quirks, etc.

The other advantage I see from running the UTM fully virtualised, comes down to HA. If you have a vmware license that offers High Availability (or Fault Tolerance which is even better) and shared storage, you don't even need to mess around with the UTM's HA. Vmware's HA will automatically move the UTM if the underlying host dies. HA does a reboot of the UTM on the new host (some downtime) while Fault Tolerance had no downtime (one dropped ping, that's it)

Thanks for the clarification. We are using VMWare, but our UTM is one the few physical machines we still use. I do have an identical physical host lying around somewhere that I will use for the second UTM for the HA pair.

Thanks again.