Overcoming CyberArk Vendor Remote Access (Alero) deployment challenges

February 5, 2025

In this blog I want to try to help others in deploying CyberArk’s Vendor Remote Access (VRA). If you’re not aware, CyberArk VRA was previously known as Alero. If you’re like any decent sized company you’ll have both firewall rules and a proxy to worry about in getting the VRA connector actually working in connecting to the CyberArk VRA SaaS tenant. This can become a real challenge and painful to troubleshoot if you run into issues. Maybe you’ll get lucky and it just magically works before needing anything in this blog. Use this information to troubleshoot your VRA deployment as needed. This blog will focus on providing you with helpful tips on what to try to get VRA actually working.

Anyways, if you’re running into issues, CyberArk released a Remote Access Checker Tool on the marketplace late last year (2024). This tool would help you determine if there are connection issues so it’s worth a look. I won’t be covering using the Remote Access Checker Tool in this blog. You can find the related link at the bottom of the blog.

Note: Don’t test in Production. Use a lab environment and related lab accounts and such to validate these configurations. Some of the items listed may not apply to your environment. I’m not liable for your own actions. Follow your own company’s security policies and procedures.

Firewall rules — Allow Websites direct or via Proxy

This is the one that should be straightforward. It depends on how your company requires traffic to be routed before going outbound. Refer to your company’s internal security procedures.

Request a Firewall rule to allow 443 outbound from your VRA Connector server(s) to these VRA (Alero) sites, or if required, allowed to go through your proxy via your proxy’s related port, such as 8080, or 8443.
Alero US data center:
auth.alero.io
connectors.alero.io
tunnel.alero.io
See CyberArk documentation for the other global Alero data center URL information.
See CyberArk documentation for the Docker/Podman and Snap URLs as they may change over time — https://docs.cyberark.com/remote-access-standard/latest/en/content/installation/prerequisitenetworkrequirement.htm

Firewall rules — RAC Servers — Allow 443 to your PVWA servers and PVWA VIP

Request a Firewall rule to allow 443 from your VRA Connector server(s) to your PVWA server(s), and PVWA VIP.

Firewall rules — RAC Servers — Allow 443 to your HTML5GW servers and HTML5GW VIP

Request a Firewall rule to allow 443 from your VRA Connector server(s) to your HTML5GW server(s), and HTML5GW VIP.

Proxy Challenges — /etc/environment

If you experience issues with just using the /etc/cyberark/ra.connector.container.env file for the proxy configurations, you can set the whole server to use your proxy. Your proxy team can provide details on what proxy server(s) you should set, and the related port(s). See below for the steps with an example.

Log onto the VRA connector server with an account that has root permissions
Edit the /etc/environment file to include the following that matches your proxy information and related domain you want traffic to not go to the proxy for. You can leave off the no_proxy item if you want to send all traffic through your proxy from this server.
For example:
http_proxy=http://myproxy.server.com:8080 https_proxy=http://myproxy.server.com:8080
no_proxy=domain.com
If using vi to edit the file, run :wq! to save your updates to the file. The updates are immediate.
Check on your VRA container name or container ID to use:
sudo podman ps
Restart your VRA container
sudo podman restart <container name> , OR
sudo podman restart <container id>
Run remote-access-cli & log into VRA
Run show-status to determine if the VRA connector tunnel is functional now. It may take a few minutes for the connector to re-establish connectivity to the VRA SaaS tenant.

Proxy Challenges — Set proxy for Snap

I stumbled upon needing to set the proxy for Snap specifically for it to actually work. Even with the system /etc/environment settings configured for whatever reason. Anyways, see below on the related commands.

sudo snap set system proxy.http=”http://<proxy_addr>:<proxy_port>”
sudo snap set system proxy.https=”http://<proxy_addr>:<proxy_port>”
sudo systemctl daemon-reload
sudo systemctl restart snapd

Firewall/Proxy Challenges — NoTLS inspection for tunnel.alero.io URL

Your firewall and/or proxy is likely configured to require TLS traffic inspection. What is TLS inspection for? TLS inspection decrypts and re-encrypts the SSL/TLS traffic traveling through your firewall and/or proxy to search for malware, data exfiltration, and other potential threats. When TLS inspection happens for the VRA URL, it breaks the secure tunnel that the CyberArk VRA connector creates back to CyberArk SaaS. The VRA connector will install but won’t function to move forward with installing all of the other pieces.

Submit for a policy exception to not TLS inspect tunnel.alero.io (US Datacenter). If you use a different CyberArk Data Center, refer to CyberArk documentation.
CyberArk notes this in the documentation here — https://docs.cyberark.com/remote-access-standard/latest/en/content/installation/connectivitytests.htm
Here’s the excerpt — “Related Traffic between the connector and Remote Access SaaS must be using a secure tunnel. If the certificate securing it is terminated or changed, the connection is broken.”

Proxy Challenges — NoAuth rule for URLs

If you’re using a proxy, it likely is configured to require authentication to it as a service account in order for traffic to be allowed outbound to the CyberArk VRA services. This poses a security challenge in that the password then is within a cleartext txt file and would show in logs. Yep, you guessed the file: /etc/cyberark/ra.connector.container.env

Also, if you’re using /etc/environment to set the proxy configs as well; the cleartext password would be there as well. The example proxy auth format is below.

For example:
http_proxy=http://user:password@myproxy.server.com:8080
https_proxy=http://user:password@myproxy.server.com:8080
no_proxy=domain.com

If you’re not comfortable with the cleartext password laying around (and you shouldn’t be), you should request that your proxy team not require authentication to the related Alero URLs. In addition, include the Snap, Docker, and Podman URLs in your request.

Server hardening — Squashfs

When you’re performing VRA installs and/or server hardening, make sure you leave squashfs enabled. The Remote Access Connector install and CLI won’t function if disabled. Reach out to your Linux Support team if you’re not sure where they’re disabling squashfs with whatever OS CIS baseline config.

Assuming this is the correct config file being used for hardening on your server(s):
Edit the file /etc/modprobe.d/CIS.conf and remove the following line:
install squashfs /bin/true
https://community.cyberark.com/s/article/Remote-Access-Errors-related-to-squashfs

Vulnerability Findings — upgrade snap remote-access-cli

As time moves on, older versions of your remote-access-cli snap will show on vulnerability scans. Here’s the manual way of upgrading to the latest version, then removing the old version.

Check what snaps are installed/disabled: snap list — — all
Check for updates: sudo snap refresh
Recheck that the latest version is installed now: snap list — — all
Remove the older and disabled version listed of remote-access-cli snap:
For example — snap remove remote-access-cli — -revision=61
Recheck that version 61 was removed: snap list — — all

Name Version Rev Tracking Publisher Notes
remote-access-cli 1.0.20101 62 latest/stable cyberark -

Looking to accelerate your Privileged Access Management rollout?

Spiderman good luck I'm behind seven proxies meme —credit at bottom of page

Item added to your cart