HA ATP PROBLEM 1:1 NAT NO REACHEABLE

Omnia
Omnia Posts: 20  Freshman Member
We have in datacenter 2 atp 800 and 2 atp 500 attested on 2 xs3800 switches in stacking.

when the 2 firewalls failover (either atp 800 or 500) the firewall interfaces reach them correctly and even the VPNs do not fall, while the 1: 1 NAT servers are no longer reachable and they can no longer navigate.

I tried to perform an arp cleaning of both switches and firewalls but the problem is not solved.

In order to make the servers reachable, I have to ask the ISP for an arp cleanup of their HSRP, and immediately everything is working again.

I am attaching a schematic diagram and a packet capture of the ATP wanWe have in datacenter 2 atp 800 and 2 atp 500 attested on 2 xs3800 switches in stacking.

when the 2 firewalls failover (either atp 800 or 500) the firewall interfaces reach them correctly and even the VPNs do not fall, while the 1: 1 NAT servers are no longer reachable and they can no longer navigate.

I tried to perform an arp cleaning of both switches and firewalls but the problem is not solved.

In order to make the servers reachable, I have to ask the ISP for an arp cleanup of their HSRP, and immediately everything is working again.

I am attaching a schematic diagram




Some idea? 
«1

All Replies

  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,100  Zyxel Employee
    Hi @Omnia
    After building up Device-HA cluster, both of devices MAC address will use the same virtual MAC address. (Virtual MAC address is come from Active role device which initialed in the first time )


    As your description, you have to ask ISP for an ARP cleanup of their HSRP after Device-HA failover. The issue should come from there is security setting on HSRP.
    You may inform your ISP unlock MAC security setting on HSRP, since both of ports on HSRP will use same MAC address after failover.
  • Omnia
    Omnia Posts: 20  Freshman Member
    edited December 2021
    Hi , Isp Write:


    "Dear Customer,

    from the description to the link you forwarded, the problem occurs only on the addresses on which the NAT is active is it correct, is the firewall reachable?

    Are the free arps also forwarded to the addresses you NAT on?

    On the SUPERNAP side we always receive traffic on the same router active at the time of failover, and there is no reception restriction on receiving garps.

    We kindly request that you can do the tests jointly.

    We look forward to receiving your kind reply.

    Yours truly."
  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,100  Zyxel Employee
    Hi @Omnia
    When failover from Device#1 to Device#2, WAN port of Device#2 will send ARP Announcement.

  • Omnia
    Omnia Posts: 20  Freshman Member
    @Zyxel_Stanley , we check with datacenter and this is the result:

    "Dear Customer,

    following the checks, we found that from a show arp on our interfaces there are many IPs connected to the same mac address (*.*.8ce1), this has changed since the last clear arp performed by us, before the mac address was. 3aa9.

    Let's imagine that on this mac address are the firewall interfaces to which the IP that does NAT are associated, if correct on which IP address?

    The problem could lie here when your Firewalls take charge of the IP on which you do NAT with a different mac address (based on ownership of the HA cluster), and until our ARP table is updated with the mac address correct (8ce1(ATP800-1) or 3aa9(ATP800-2)) you encounter the reachability problem.

    The fact that a clear arp is needed to resolve the ARP resolution seems to indicate that when a failover occurs, the ARP request with the new mac address does not arrive.

    As also suggested by you, you should do a pcap after a failover to check if the IP on which you NAT is updated in our ARP table.

    The NOC SUPERNAP Italia remains available for further clarifications.

    Cordially,"


    it seems that firewalls do not send ARP Announcement, when failover.

    Now we have to carry out a test to verify the arp sending,

    thank you

  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,100  Zyxel Employee
    During Device-HA switching active role from Device#1 to Device#2. (Device-HA failover)
    Device#2 physical link goes to up and start to working.
    WAN interface will send "ARP Announcement" first.
    -> MAC address will the same as active role, and IP address will be your Public IP address.

    You can take a screenshot on your virtual MAC address first.
    And also capture packets on WAN interface of Device#2 during device role changes from passive to active.
    And then we may have a check if "ARP Announcement" has been sent out.
  • Omnia
    Omnia Posts: 20  Freshman Member
    we found a strange thing, the currently active firewall (device-2) does not appear with the virtual mac in arp reply/request:

    active device:


    passive:


    virtual mac:



    device1

    device2


    It's normal?
  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,100  Zyxel Employee
    After building up Device-HA cluster, both of devices will work by the same virtual MAC.
    If disabled Device-HA function, device will use itself's  MAC address.
    I will send you private message for further check this issue.
  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,100  Zyxel Employee
    Hi @Omnia
    Force to resync Device-HA configuration on Secondary device. 
    Does it helps system uses "Virtual MAC" address?
  • Omnia
    Omnia Posts: 20  Freshman Member
    edited January 25
    deleted
  • Omnia
    Omnia Posts: 20  Freshman Member

    this morning the ATP800 firewall interface was not responding.
    The web interface was unreachable neither via its public IP nor is LAN one.
    I had to shut down the switch port in order to trigger the HA pocedure, and the firewall web interface came online again.
    Now the management web interface of the offline firewall is unreachable:


    Here's the link to download the Pcap of 20012022, when the faulty firewall was up and running, and of this morning, after the switch: https://we.tl/t-q5Q0CUODuJ

    Filtering by "arp", it shows that the firewall is using its own MAC, and not the virtual one.

    Please address this issue quickly, customers are starting to get unmanageable.

Security Highlight