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

Virtual MAC on Interface changes back on HA Mode

Hi!

I am currently operating two Sophos UTM behind a router which is running great.

For redundancy reasons I now want to add another pair to operate in HA mode.

The issue: All UTM's use the SAME Interface MAC when switching to HA mode.

I can manually adjust the virtual MAC (Interface > Hardware) but after some times it's automatically chaning back to default.

Now I have two Sophos UTM (pairs in HA mode) with the same virtual MACs - my router & network of course doesn't like this.

I found an old article that it seems chaning the virtual MAC is no supported in HA mode.

Is there any solution / workaround available?

Thanks

Best regards



This thread was automatically locked due to age.
Parents
  • Let me clarify - you have TWO PAIRS of UTM, each of them in HA mode?

    By any chance did you commission the second pair using a backup of the configuration of the first pair to save typing?

    We did so and ran into the same trouble and also some other issues (i.e. not being able to register both in the SUM).

    Sophos support came up with the recommendation to
    - break up HA
    - manually set different MACs for at least the ports sharing the same uplink (we did it for all).
    - setup HA again.

    Quite an effort but then HA took over the manually set IPs.

  • Hey!

     

    Yes correct, I have TWO UTM, each in HA mode (total of 2x2).

     

    The second pair has configured with an configuration import of the first pair – have not found a way to just import/export the definitions and have many devices, networks etc. configured there.

     

    I already tried to break up HA, but I did not manually adjust the default MAC because it is already different – not sure if I should still manually change it to trigger some sort of „overwrite“ in the background or so?!

     

    Here are some screenshots, the error and behavior is reproducible.

     

    Screenshot 1:

    HA disabled. Both UTM’s have different MAC Addresses for all Hardware Interfaces.

     

    Screenshot 2:
    Now enable HA

     

    Screenshot 3:
    Enabling HA has automatically enabled the virtual MAC addresses in Interfaces > Hardware.

    This is now a MAC conflict, since the virtual MAC addresses at the left are similar to the virtual MAC addresses at the right.

     

    Screenshot 4:

    I now have manually adjusted all 6 virtual MAC addresses. They are now unique.

     

    Screenshot 5:

    After some time, the virtual MAC addresses automatically fall back to the initial/wrong address, causing a conflict again (duplicate).

     

    I have now tried this two times and every time the same fallback to the wrong virtual MAC happens. Whatever I manually enter in the virtual MAC address, it does not stay and reverts back. I were not able to find out when it fall back, feels like it reverts back after 1 hour or so but not instantly.

  • Patrick, you said that you "did not manually adjust the default MAC" - does that mean that the MACs into the DMZ the same on both HA pairs?  I think you must disconnectthe slave and then manually set the MAC on both Master and Slave.  It might be necessary to break HA before changing the MACs.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • Patrick, you said that you "did not manually adjust the default MAC" - does that mean that the MACs into the DMZ the same on both HA pairs?  I think you must disconnectthe slave and then manually set the MAC on both Master and Slave.  It might be necessary to break HA before changing the MACs.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • Hi Bob,

    the physical MACs are different everywhere at all UTMs.

    Once I enable HA, the virtual MACs are defaulting to the same virtual MACs, causing a conflict.

    If I then change the virtual MAC manually, it will not stay. After some time, the virtual MACs revert back to "default".

    See above Screenshot 3. As soon as I enable HA, the virtual MAC will get automatically set to "00:1a:8c:f0:7a:60" at both eth0's.

    I then manually change the virtual MAC to "00:1a:8c:f0:7a:70" at UTM1 and "00:1a:8c:f0:7a:80" at UTM2 - reference Screenshot 4.  Hoewever, it does not stay like this. After some time, the MACs automatically resetting to "00:1a:8c:f0:7a:60" at all appliances.

    So for whatever reason, the virtual MACs are always getting changed back to "00:1a:8c:f0:7a:60" no matter what I do.

    I have the impression that "00:1a:8c:f0:7a:60" is a default virtual MAC for HA's and all appliances are resetting to this MAC in HA Mode.

    Cheers - Patrick

  • Hi Patrick,

    this sounds exactly like the issue we had.

    Reason is that with the import of the configuration some internal parameters (most notably the ASG_ID, a long hex number which is stored in /etc/asg) have been the same on both pairs.

    If you set up HA and then change the MAC of an interface the change will not persist. It'll last up to 20 minutes - just long enough to make you happy and let the consultant go - and then revert to "automatic" values maybe derived from the database or the ID.

    What we had to do was

    • break up HA and revert to standalone mode
    • change ASG_ID
    • empty the slave (reimage)
    • set MACs as needed on the (single) node in the GUI
    • built up HA again by adding the slave
  • Hi Alan!

    I was now following the steps you've mentioned. 

    • disabled HA
    • Compared the ASG_ID's / System_ID's - they were indeed the same
    • Resetted the ID's and validated that they have changed
    • Reimaged the slaves
    • Validated that all physical MACs are unique
    • built up HA again 
    • As soon as I enable HA, the virtual MAC got automatically set to "00:1a:8c:f0:7a:60" at both eth0's.
    • Manually adjusted the virtual MACs to unique values again
    • Crossing fingers
    • FAIL - they revert back again to "00:1a:8c:f0:7a:60" after some time

    Unfortunately this did not solve the issue.

    Any other idea is highly appreciated.

    Cheers - Patrick

  • Hi Patrick,

    I can pretty much rule out that the same MAC for HA-interfaces is used everywhere, because I have checked this on some of our HA setups and it is different everywhere. Only the last digit obviously indicates the interface number (X0 eth0, X1 eth1, ...)

    I suspect this is generated from another setting, maybe try different passwords in HA setup etc. or just contact Sophos support.

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • Hi Josef,

    admittedly the error is very rare and happens only in certain situations, however since several people ran into int - it's simply the result of straightforward thinking and installation.

    Since you asked here are the
    steps to reproduce:  

    • get four systems. ensure they all have different MACs (for HW that's an easy one, for virtual they must not be cloned or at least be set to "automatic" collision-free MAC assignment by the VM host). We'll call them A1, A2, B1 and B2
    • join LAN, WAN and optionally DMZ of all 4 systems i.e. by using 3 (virtual) switches.
    • setup A1. As bare minimum assign IPs to LAN, WAN and optionally DMZ
    • do not use virtual MACs here
    • export configuration from A1 and import it to B1
      this is crucial for getting the error as it exports/imports the ASG_ID
    • adapt B1 as needed, i.e. hostname and IPs for LAN, WAN and DMZ
    • optionally  for debugging: ssh into the systems and verify that ASG_ID is indeed the same on both systems
    • join A2 to A1 in active/passive HA and join B2 to B1
    • BANG, both (actually all 4) WAN interfaces share the same MAC, so the A and the B cluster cannot reach WAN.
      same happens for DMZ

    culprit is here:

    sub generate_virtual_mac {
      my $eth_id = shift;
      my $uniq_id = shift;
      $eth_id =~ s/eth//;
    
      $uniq_id <<= 5;
      $uniq_id += $eth_id;
    
      return sprintf("00:1a:8c:f0:%.2x:%.2x", $uniq_id >> 8, $uniq_id & 0xFF);
    }

    Avoiding the error is easy: Instead of the "do not use virtual MACs here" read "do use virtual MACs here".
    Note that your virtual MACs must not start with "00:1a:8c:f0:" and of course be unique.
    When changing the ASG_ID change at least one of the last 11 bits (i.e. add "1" to the ID).