AHA Audit Failed: VPN Connectivity / ConfigurationIssue These alerts indicated the VPN tunnel between our data-centers and your public IP address is either DOWN, or the VPN pairs are NOT the same.Your VPNs in ServiceNow are identified as <DATACENTER_ID>-<ServiceNow-public-IP>_<Customer_public_IP>We need to validate on both YOUR end as well on the ServiceNow end and when this type of alert occurs, the AHA or the Advanced High Availability feature becomes temporarily unavailable. What is a VPN? A virtual private network (VPN) creates a private network from a public internet connection. VPN services establish secure and encrypted connections. It is important to know the required maintenance and changes on the VPN configuration need to be done on BOTH sides. For alternatives, please read the following blogs:You Don't Need a VPN Pt I - LDAP Integrations, User Data Imports & the MID Server solution and You Don't Need A VPN Part II - LDAP Integrations, User Data Imports, & the Internet solution CauseThere are two main causes for this AHA Audit Failed: VPN Connectivity / Configuration alert: 1. If the VPNs are UP and running, but the alert triggers, check the VPN Configuration is correct for each of the pairs. The alert checks the encryption domain (IP addresses defined in a tunnel) in each of the VPN pairs. If they do not match, we consider that an AHA failure even if both tunnels come up, since technically the VPN connectivity are not equal in both sites. 2. If one VPN is failing and trigger the alert as the system is not able to establish a VPN tunnel between ServiceNow and the customer public IPs.ResolutionAt first, we need to check the datacenter that are currently responsible to managing the standby/failover nodes and those that contain the VPN tunnels that need to be worked on. In order to do that, you can follow the link given below with your instance name and that can help you get started. So, the process to find it can be done by using the following link : <instance-name>/xmlstats.do?include=cluster Once you are able to see the xmlstats, now you need to navigate to the nodes section and there you will be able to see whether that's the primary or secondary node. If that is secondary, then the node name is the one that needs to be checked out by the networking team, which has been mentioned below. Now that you know which datacenter and node you need to look at with your networking team, the next set of steps can guide your networking team to fix the issue: Ensure with your network administrators the VPNs are are UP and running.If the VPNs are UP, we need to validate the correct encryption domain ranges (IP addresses defined in a tunnel) have been set. Please confirm the values expected. They are on CIDR format and look like e.g. 209.173.53.167/20.If the firewall has restrictions, please update it with the list public ServiceNow IPs: KB0679421 - Questions about Inbound and Outbound firewall rules needed to the instances and datacentersIf the problem has been resolved, we would leave a day to check it is stable, then move the alert for closure.If the tunnel is not being used, please make sure that you inform ServiceNow regarding the decommissioning of the tunnel. More information on VPNs is our docs: Virtual Private Network (VPN)