Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 21 replies
  • Subscribers 2 subscribers
  • Views 16705 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

MrGoodBytes_01
Hi Everyone,

I've been having some trouble setting up an Active-Passive/Hot Standby High Availability configuration with two UTM9 nodes. Both are licensed for this configuration.

The problem is whenever I enable the High Availability option, either using Automatic Configuration or manual (following this guide: How to set up High Availability without automatic configuration: Astaro Security Gateway) I loose access to WebAdmin and have to wipe/reinstall the OS to get it working again. Connection to the WAN also drops, but WebAdmin is the primary concern.

The overall configuration:
2 UTM Gateways hosted as Gen1 VMs on Hyper-V 2012 R2 (cluster)
Each VM has 4 NICs as follows:
   - NIC0 = External (WAN)
   - NIC1 = Internal
   - NIC2 = Management (WebAdmin can only be accessed from this VLAN)
   - NIC3 = High Availability

NIC3 connects the two UTM hosts to a private VLAN which they can communicate via. They do connect, as one time I say UTM-2 connect as Node2 before being disconnected from it.

I don't think the problem is related to my nodes, as even with UTM-2 offline and configuring HA on a UTM-1 I still loose connection to WebAdmin on it. Also, with UTM-2 online, the increase in disk and CPU activity suggests that it is indeed syncing as it is supposed to. Yet WebAdmin and WAN access drops out.

This really has me puzzled. Can anyone offer any suggestions?


This thread was automatically locked due to age.
Parents
  • 0
    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).
Reply
  • 0
    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).
Children
  • 0 in reply to solae
    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.