Client Agent software conflicts

출처: HashiCorp Boundary docs Some software is known to cause conflicts with the Boundary Client Agent. Refer to the transparent sessions interoperability matrix for a list of the third-party products that have been tested for use with the Boundary Client Agent. The following sections are an incomplete list of potential conflicts and any available workarounds for issues.

Cloudflare WARP client

The Cloudflare WARP client uses a local DNS server to direct traffic. It has built-in checks to prevent it from being run alongside other software that uses the same mechanism. This includes the Boundary Client Agent. If you try to use the Client Agent with the Cloudflare WARP client, it might work, or you might see an error like this one:

Status: Unable to Connect

Error reason: DNS Proxy Failure

Error code: CF_DNS_PROXY_FAILURE

Error description: The WARP Agent must be the only process responsible for DNS resolution on the device. One or more processes are already bound to port 53: boundary-client-agent.

Learn more: https://cfl.re/CF_DNS_PROXY_FAILURE

You can still install both the Cloudflare WARP client and the Boundary Client Agent on the same machine. The two products can coexist as long as the WARP client starts first. Starting the WARP client first binds it to alternate IPs and leaves the domain available for Boundary.

Docker Desktop (macOS)

Docker Desktop sometimes creates a local DNS listener that prevents the Client Agent from running. If you run Docker Desktop 4.26 or later, you must clear the Use kernel networking for UDP option. Otherwise, the Client Agent refuses to start.

Huntress EDR client (Windows)

Host isolation and release do not work as expected in Windows when you use the Huntress EDR client with the Boundary Client Agent. The Huntress EDR client for Windows uses the Windows Filtering Platform (WFP) to isolate devices by blocking all non-essential traffic. This behavior conflicts with the Boundary Client Agent during device isolation. Specifically, the Boundary Client Agent replaces the default DNS resolver with its own, which can prevent fallback to a secondary DNS when the primary (Boundary) DNS fails during isolation. As a result, Huntress is unable to maintain server communication, leaving the device stuck in an isolated state. Huntress cannot isolate and release devices properly in Windows under these conditions. As a temporary workaround, you can manually configure a secondary DNS (e.g., 8.8.8.8). However, this secondary DNS setting is overwritten when you pause or resume the Boundary Client Agent, so you must configure it again each time. This issue does not affect macOS devices, where Boundary and Huntress coexist without additional configuration.

Enabling Internet Sharing on macOS causes the system's DNS resolver (mDNSResponder) to bind to all interfaces on port 53, preventing the Client Agent from starting. Disable Internet Sharing before you run the Client Agent.

OpenVPN

When you run OpenVPN at the same time as the Client Agent, it can create a DNS conflict. If you are unable to establish a transparent session while using OpenVPN, you might need to explicitly specify a network interface and upstream DNS server(s) to use. To configure the DNS server(s) to use, use the override_upstream_dns_servers configuration option:

# The DNS servers must be specified as an IP, or an IP:Port.

# If no port is provided, port 53 is assumed.

# The order of the entries specifies the priority.

# We recommended providing both the VPN DNS servers

# and the default DNS servers, so that DNS requests can

# be resolved even when the VPN is not active.

override_upstream_dns_servers 
=
 [

   "10.0.0.1"
,
 # Example primary VPN DNS server

   "10.0.0.2"
,
 # Example secondary VPN DNS server

   "8.8.8.8"
,
  # Fallback default DNS server

   "8.8.4.4:53"
,
 # Fallback default DNS server with a custom port

]

Note The override_upstream_dns_servers is used for all non-Boundary DNS requests. If you only provide the VPN DNS servers, the Client Agent will not be able to resolve any DNS requests when the VPN is not active. If you configured OpenVPN to push DNS servers to the client, it might create additional conflicts. Refer to the sections below for more information about how this configuration affects macOS and Windows systems.

macOS

When OpenVPN is configured to push DNS servers to the client, the client-side service monitors and updates the system DNS settings. As a result, OpenVPN might attempt to override the Client Agent's configuration. This scenario can create an unstable network environment and lead to disruptions in user connectivity and service access. There is no workaround for this scenario at this time.

Windows

When OpenVPN is configured to push DNS servers to the client, it creates DNSClientNrptRule entries in Windows that control DNS routing independently of the interface priority. Although the Client Agent updates the interface's DNS settings, it does not manage the Name Resolution Policy Table (NRPT). As a result, the OpenVPN rules might override the Client Agent's configuration. This scenario might lead to conflicts, and there is no supported workaround at this time.

Palo Alto Networking GlobalProtect VPN

If you are unable to establish a transparent session while using the Palo Alto Networking GlobalProtect VPN, you might need to explicitly specify a network interface and the upstream DNS server(s) to use. You might also experience conflicts with some versions of the Client Agent on macOS. Refer to the following sections for more information.

DNS server configuration
Primary network interfaces
macOS conflicts
Windows conflicts

DNS server configuration

By default, the Client Agent reads the primary network interface's DNS server configuration and uses that information to resolve domains that are not configured as aliases in Boundary. If the VPN configuration includes custom DNS servers, this information might not be available to the Client Agent, so you must explicitly specify the DNS server(s) to use. To configure the DNS server(s) to use, use the override_upstream_dns_servers configuration option:

# The DNS servers must be specified as an IP, or an IP:Port.

# If no port is provided, port 53 is assumed.

# The order of the entries specifies the priority.

# We recommended providing both the VPN DNS servers

# and the default DNS servers, so that DNS requests can

# be resolved even when the VPN is not active.

override_upstream_dns_servers 
=
 [

   "10.0.0.1"
,
 # Example primary VPN DNS server

   "10.0.0.2"
,
 # Example secondary VPN DNS server

   "8.8.8.8"
,
  # Fallback default DNS server

   "8.8.4.4:53"
,
 # Fallback default DNS server with a custom port

]

Primary network interfaces

By default, the Client Agent creates IPs on the primary network interface to serve its DNS server. Refer to the tabs below for potential conflicts and workarounds for each supported operating system. When you run the Client Agent alongside the PAN-GP VPN, the primary network interface will likely be set to a tun type interface, which the Client Agent cannot use for its IP addresses. You might see errors such as the following in the boundary-client-agent.log file or the boundary client-agent status command response:

[ERROR] macos.addIP: error adding ipv4 address: ifconfig: ioctl (SIOCAIFADDR): Destination address required

To work around the default tun interface, you must provide an explicit network interface using the interface_to_use configuration option. For example:

interface_to_use
=
en0

The interface_to_use option allows the Client Agent to create the IPs it needs to serve the DNS server and proxy traffic. You must restart the Client Agent for it to update its configuration with the new setting. On Windows, the Client Agent might be able to create the IPs that it needs on the primary network interface, but it fails to establish any transparent sessions. You might see the following message:

[INFO] default route change detected, restarting

You must explicitly specify a network interface to use other than the primary one. You can list available network interfaces using the Powershell command Get-NetAdapter, or the older route print command. You must find the index of the interface you would normally use to connect to the internet. In this example, the interface index is 11:

PS C:\> Get-NetAdapter

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed

----                      --------------------                    ------- ------       ----------             ---------

Ethernet                  Parallels VirtIO Ethernet Adapter            11 Up           00-1C-42-B3-F2-75        10 Gbps

Ethernet 2                PANGP Virtual Ethernet Adapter Secure        24 Up           02-50-41-00-00-01         2 Gbps

Alternatively, if you use route print, refer to the following example:

PS C:\> route print

===========================================================================

Interface List

 24...02 50 41 00 00 01 ......PANGP Virtual Ethernet Adapter Secure

 11...00 1c 42 b3 f2 75 ......Parallels VirtIO Ethernet Adapter

  1...........................Software Loopback Interface 1

===========================================================================

Your configuration should look like this:

interface_to_use
=
11

You must restart the Client Agent for it to update its configuration with the new setting.

macOS conflicts

The Palo Alto Networking GlobalProtect VPN client for Mac v6.3.3-1046 conflicts with version 1.0.0 of the Boundary Client Agent. This conflict is a known issue, and there is no supported workaround at this time. If the Client Agent is running, and you connect to the GlobalProtect VPN, the Client Agent might stop working. If you are already connected to the GlobalProtect VPN, and you start the Client Agent, you might lose internet connectivity.

Windows conflicts

The Palo Alto Networking GlobalProtect VPN client for Windows v6.3.3-828 conflicts with version 1.0.0 of the Boundary Client Agent. If the Client Agent is running when you start GlobalProtect, the Client Agent functions normally. However, if GlobalProtect is running when you start the Client Agent, the Client Agent does not work. It cannot resolve target aliases and transparent sessions fail.

Parallels Desktop

Parallels Desktop can conflict with the Client Agent in different ways depending on the VM networking configuration and operating system.

Shared networking

Running a macOS VM in Parallels Desktop with shared networking causes the system's DNS resolver (mDNSResponder) to bind to all interfaces, blocking port 53 and preventing the Client Agent from starting. As a workaround, you can configure Parallels Desktop to use a different network mode. Select an alternative network configuration such as Host-Only, Default Adapter, or Wi-Fi instead of Shared Network. Refer to the Parallels Desktop documentation for more information.

Multiple sessions

When you use the Client Agent on a Windows VM in Parallels Desktop to connect to an RDP target, Boundary may create multiple sessions. One session is Active, while several others show a Pending state. Disconnecting from the target creates an additional session. If session recording is enabled for the target, Boundary records all of the Pending sessions as well as the Active one, but the recording data is not successfully captured. This is a known issue, and there is no workaround at this time.

Cisco AnyConnect VPN

When the Cisco AnyConnect VPN is active at the same time as the Boundary Client Agent, DNS resolution might fail for Boundary aliases. The Boundary Client Agent by default uses the IPv4 range 100.x.x.x for its local proxies. The Cisco AnyConnect VPN treats this range as a secured range, which forces DNS queries to resolve through the VPN instead of the Boundary Client Agent. As a result, Boundary aliases cannot be resolved. You can configure the Boundary Client Agent to use a different IPv4 prefix by setting the v4_prefix option in the client configuration file. This setting overrides the default 100.x.x.x range and avoids the conflict with Cisco AnyConnect VPN. For example:

v4_prefix 
=
 "172.16.0.0/12"

Note You can set the v4_prefix to any valid RFC1918 private IPv4 range, as long as it does not overlap with ranges secured by the VPN. Common options include:

10.0.0.0/8
172.16.0.0/12 Choose a range that best fits your environment.

Uninstall the Client Agent on Mac

If you used the Mac installer, you can run /Library/Application Support/HashiCorp/Boundary Uninstaller.app to uninstall Boundary. The uninstaller removes any installed components, including the Desktop client, CLI, and the Boundary Client Agent.

Client Agent software conflicts