Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 23 replies
  • Subscribers 2 subscribers
  • Views 38379 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

UTM9 Active-Passive HA on vmWare

TerryJohnson
After three weeks of troubleshooting we still haven't got our active-passive HA pair of UTMs working properly.

All VMs of the same vmWare host as the passive UTM still have its MAC addresses in their ARP tables as the destinations for packets to the UTM IP addresses, so they can't ping the UTM or communicate at all outside of their own subnet. Everything works fine with only one UTM running, and we also have some CentOS Cluster VMs and they can move IP addresses around without any issues.

What mechanism does UTM9 HA use to update ARP?  There must be something subtly different about the way UTM9 does it and the way CentOS does it…


This thread was automatically locked due to age.
  • 0 in reply to marco116
    We have a similar issue.
    Configuration:
    2 ESX Hosts 5.0
    Sophos UTM 9.003-16 - VM

    We deployed the VMs on the two ESX Hosts. After installing and configuring the Master we activated  Active-Passive Cluster via Auto-Configuration.
    After Syncing the SLAVE with the Master, all VMs on the this ESX Host where the SLAVE was running went offline (we were not able to ping or Access the VMs.)
    So we shutdown the SLAVE and all went up again.
    At the moment VLAN Routing is implemented via the UTM.

    Does anyone have a Configuration Guide for implementing Sophos UTM HA with Vmware ESX?

    kind regards
    Marco


    Cool,

    same here.
    I m searching since weeks.
    Glad to hear that I m not the only one:-)
    I will test it this weekend on a ESX 51.
    The ESX itself isn t able to ping too. So it s a problem deep in the system.
    No idea what is going wrong but the ESX 5 is my "favorite" to be the toublemaker.
    Ralf
  • 0 in reply to rprengel
    This thread has a possible solution: https://community.sophos.com/products/unified-threat-management/astaroorg/f/52/t/27886

    The issue is that the vSwitch sees the virtual mac address of the slave and instead of forwarding the traffic out the physical nic, forwards it to the slave vm. The solution posted there was the 'cc set ha advanced virtual_mac 0' command. Haven't tested under v9 so YMMV.
  • 0 in reply to TheDrew
    This thread has a possible solution: http://www.astaro.org/gateway-products/hardware-installation-up2date-licensing/35868-hot-standby-issue-both-macs-active.html

    The issue is that the vSwitch sees the virtual mac address of the slave and instead of forwarding the traffic out the physical nic, forwards it to the slave vm. The solution posted there was the 'cc set ha advanced virtual_mac 0' command. Haven't tested under v9 so YMMV.


    I will test it again.
    my ha is realized with seperated physical Nics in both ESX 5.1 HP 36 Microservers.
    nic 1 normal network traffic
    Nic 2 HA between the two Astaros  running on the two Microservers
    Nic 3 PPPOE Dial-in

    alf
  • 0 in reply to BAlfson
    It sounds like you didn't run this with cc.  As root, try
    /usr/locl/bin/confd-client.plx set ha advanced virtual_mac 0

    Cheers - Bob


    Hallo,

    a question.
    When and where should this commando be set?
    On the slave before starting HA or on the after building the ha?

    Thanks
    Ralf
  • 0
    Hi, Ralf,

    I think this is done on the Master after activating HA.  I haven't actually done this, so I'd be interested in your result. [:)]

    Cheers - Bob
  • 0 in reply to BAlfson
    Was able to get the ESXi lab updated so I have a bit further to report on this.

    The thread I reported earlier does work for v9. It appears to be an arp caching issue with ESXi's vSwitches, as I suspected. Clearing the arp cache in ESXi (unlike ESX) requires a complete reboot of the host machine.
  • 0 in reply to TheDrew
    Was able to get the ESXi lab updated so I have a bit further to report on this.

    The thread I reported earlier does work for v9. It appears to be an arp caching issue with ESXi's vSwitches, as I suspected. Clearing the arp cache in ESXi (unlike ESX) requires a complete reboot of the host machine.


    Hallo,
    what is about this
    Code:
    /usr/locl/bin/confd-client.plx set ha advanced virtual_mac 0
    Did you use this too?

    Ralf
  • 0 in reply to rprengel
    I have found the following instruction:

    For every NIC of the Sophos VM set the following:

    ethernet0.ignoreMACAddressConflict = "TRUE"
    ethernet1.ignoreMACAddressConflict = "TRUE"
    ethernet2.ignoreMACAddressConflict = "TRUE"

    This setting can also be set an the Sophos VM:
    Options- Advanced -General - Configuration Parameters 
    ethernet0.ignoreMACAddressConflict = "TRUE"

    Furthermore on the vSwitch of the ESX the following settings must be done:
    (see attachment)

    We will try those setting next week during a migration.
    Has anyone found an other solution in the meantime?

    Kind regards
    Marco
  • 0 in reply to marco116
    In another forum i also found the following solution:


    • Use the ASG VMWare Images and change adapters to E1000 for best performance.


    • Set MTU on HA interface to 1500 with the command "cc set ha advanced mtu 1500" in Astaro CLI, to prevent use of jumbo frames. (Will not work)


    • Use a dedicated VLAN in ESXi for the two ASG HA interfaces.


    • Disable vitual HA MACs with the command: "cc set ha advanced virtual_mac 0" in Astaro CLI to ensure that VMs residing on same vSwitch as the passive ASG can communicate with the active ASG on other vSwitch.


    • If WAN has DHCP assigned IP address from ISP - set identical MAC address on the two ASG's WAN adapters by editing Virtual Machine settings in ESXi.

        Note: This requires editing the .vmx file for the VMs and setting "ethernet0.ignoreMACAddressConflict = "TRUE"" for the adapters used for WAN (replace ethernet0 with relevant number for interface).

    We will try this as well next week. 
    If anyone can try this before I would appreciate your feedback.

    kind regards 
    Marco
  • 0 in reply to marco116
    I have found the following instruction:

    For every NIC of the Sophos VM set the following:

    ethernet0.ignoreMACAddressConflict = "TRUE"
    ethernet1.ignoreMACAddressConflict = "TRUE"
    ethernet2.ignoreMACAddressConflict = "TRUE"

    This setting can also be set an the Sophos VM:
    Options- Advanced -General - Configuration Parameters 
    ethernet0.ignoreMACAddressConflict = "TRUE"

    Furthermore on the vSwitch of the ESX the following settings must be done:
    (see attachment)

    We will try those setting next week during a migration.
    Has anyone found an other solution in the meantime?

    Kind regards
    Marco

    Hallo,
    the hints in the quote
    and 
    /usr/locl/bin/confd-client.plx set ha advanced virtual_mac 0
    and
    a reboot of both esx-servers 
    seems to be the solution.

    Ralf