Solution to Network Connectivity Issues after the Hardening of the CyberArk PAM self-hosted's Vault on Virtualized Hardware

The CyberArk PAM self-hosted Vault is not typically installed on virtualized hardware but some cases make the scenario justified -- one of them being when standing up a lab environment.

When using Hyper-V (and potentially other hypervisors), after hardening the Vault during the installation process, the Vault may lose network connectivity upon subsequent reboot. This results in the inability to establish inbound or outbound connections for all services.

This issue arises because the Windows Firewall rules created by the CyberArk Vault servers do not take effect, necessitating minor adjustments to two registry keys to resolve the problem.

Determining if your Vault is impacted

The easiest way to tell if you are being impacted by this is by checking the Vault machine's network connectivity. This can be done using Test-NetConnection and seeing that outbound connections to all services such as Active Directory and the NTP server fail.

Another way is checking the Firewall pane under the Monitoring section in the Windows Defender Firewall snap-in.

This pane shows the rules in effect and when the Vault services are running, four rules representing the allowing of outbound and inbound Vault-related traffic should be showing. If it is empty, then there are no effective rules and no inbound or outbound traffic is allowed.

A screenshot of an empty Windows Firewall Defender Firewall pane

A screenshot of the Firewall pane when there is no network connectivity.

The Fix

The fix is straightforward. You simply need to change the two following Windows Defender Firewall-related registry keys from 0 to 1:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\PublicProfile\AllowLocalIPsecPolicyMerge

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\PublicProfile\AllowLocalPolicyMerge

Afterward, reboot the Vault machine. Rules will show up in the Firewall pane and network connectivity will be restored.

A screenshot of a populated Windows Firewall Defender Firewall pane

A screenshot of the Firewall pane when network connectivity is working.

What is happening as part of the hardening?

These keys control if locally defined Windows Defender Firewall rules -- such as the ones created by the Vault when the service starts -- should take effect or not and as part of the Vault hardening, these registry keys are explicitly set to 0 for the Public profile and 1 for the Private profile. It is likely that the intention is for the Vault to take on the Private profile but is for an unknown reason assuming the Public profile.

Even CyberArk is uncertain about why this occurs, as when the Vault hardening process identifies that the Vaults are in AWS, CyberArk explicitly sets both keys to 1.

An exerpt from the HardenWindowsFireWall.ps1 script found in Server-Rls-x.x/Hardening/Scripts

An exerpt from the HardenWindowsFireWall.ps1 script found in Server-Rls-x.x/Hardening/Scripts