Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 4 replies
  • Subscribers 37 subscribers
  • Views 1704 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

enableha: peer sanity check failed !!! After disabling the HA from the primary device, I cannot enable the HA again

lferrara

I disabled the HA with the hope to get the license synchronization issue:

https://community.sophos.com/products/xg-firewall/f/licensing/117909/cannot-sync-license---after-registering-the-xg-135-and-changing-the-ca-i-have-only-base-license/426528#426528

but no luck. Still license does not sync.

Now I want to enable the HA again, but I am not able to do it.

I am not able to access the web admin of the auxilary device. I tried to perform the system appliance_access enable but still 4444 is not reachable. I guess that the auxilary is in a "unknow" state.

Is there a way to unlock the auxilary and ricreate the HA?

Since I do not have physical access until next week, I would like to configure the HA again without going there physically.

Regards



This thread was automatically locked due to age.
Parents
  • 0

    Hi  

    Could you please connect the auxiliary device over the serial console access and try to reset the device?

    When you enable the appliance access through command, could you please check tcpdump for the request being served or not?

    Regards,

    Keyur
    Community Support Engineer | Sophos Support
    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link

  • 0 in reply to Keyur

    Thanks  

    tcpdump .-nei on port 4444 gives out SYNC status on packets. Of course, I performed the appliance access command, but no changes.

    I will perform a factory reset but I need to go there as the default ip will be changed to 172.16.16.16 and I do not have control on the switch where the VLAN exist.

    I will update the thread.

    Regards

  • 0 in reply to lferrara

    Hi  

    Thank you for your reply, please inform us further.

    Regards,

    Keyur
    Community Support Engineer | Sophos Support
    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link

  • +1 in reply to Keyur

    Hi all,

    I was able to fix the issue. Once you break the cluster, the slave node is not reachable on other interfaces than the HA one (and I knew that). The problem, in my case, was I had access only remotely via SSL VPN.

    So I proceeded in this way:

    • Write down the ip addresses used by the SSL VPN 10.81.234.5-10.81.234.55
    • Connect to XG slave node via HA ip address on SSH (webadmin was disabled)
    • route -n to print the current routing table on the slave node to understand
    • Since both primary XG and slave XG have the same routing table for tun0, I deleted this route table entry "10.81.234.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0" by executing the command: ip route delete 10.81.234.0 netmask 255.255.255.0 via dev tun0
    • then I creted a new ip route to make sure to reach the remote SSL VPN users via XG primary interface: ip route add 10.81.234.0 netmask 255.255.255.0 via 192.168.0.3 dev Port1
    • In this case: 192.168.0.3 is the primary XG LAN interface and PORT1 is the XG slave port to reach XG 192.168.0.3
    • After that, I was able to reach 192.168.0.4 (XG slave LAN interface) from VPN
    • On the Slave node, I enabled SSH on DMZ zone and configured it as slave node for HA
    • Re-create the cluster from Primary XG webadmin

     

    Hope this can help users on community.

    Regards

Reply
  • +1 in reply to Keyur

    Hi all,

    I was able to fix the issue. Once you break the cluster, the slave node is not reachable on other interfaces than the HA one (and I knew that). The problem, in my case, was I had access only remotely via SSL VPN.

    So I proceeded in this way:

    • Write down the ip addresses used by the SSL VPN 10.81.234.5-10.81.234.55
    • Connect to XG slave node via HA ip address on SSH (webadmin was disabled)
    • route -n to print the current routing table on the slave node to understand
    • Since both primary XG and slave XG have the same routing table for tun0, I deleted this route table entry "10.81.234.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0" by executing the command: ip route delete 10.81.234.0 netmask 255.255.255.0 via dev tun0
    • then I creted a new ip route to make sure to reach the remote SSL VPN users via XG primary interface: ip route add 10.81.234.0 netmask 255.255.255.0 via 192.168.0.3 dev Port1
    • In this case: 192.168.0.3 is the primary XG LAN interface and PORT1 is the XG slave port to reach XG 192.168.0.3
    • After that, I was able to reach 192.168.0.4 (XG slave LAN interface) from VPN
    • On the Slave node, I enabled SSH on DMZ zone and configured it as slave node for HA
    • Re-create the cluster from Primary XG webadmin

     

    Hope this can help users on community.

    Regards

Children
No Data
Unfiltered HTML