This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
FAQ
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
New Article

Firewall Constraints and allowlisting for Synthetic Monitoring

HannahM
Dynatrace Guru
Dynatrace Guru

‎05 Jun 2023 06:44 PM - edited ‎21 Oct 2025 12:47 PM

 

Summary

When using Dynatrace Synthetic Monitoring, it's sometimes necessary to allow/ allowlist traffic for monitors to execute successfully and return data to Dynatrace.

Browser monitors use the same technology to return data to Dynatrace, so the RUM rules, described here, should also be added.

In this article, we will only describe the extra constraints for Synthetic.

 

Issues

 

Synthetic monitors fail to reach an application

 

Synthetic Monitor executes from a public location but fails to connect to an application

An affected synthetic monitor may show different failures, such as request timeouts, authentication failures, connection refusals, etc. The key is that the monitor is permanently failing with the same outage.

 

What can you do?
Confirm the following with the relevant Application team:

  1. Should the application be available outside your network?
  2. If so, are there any limitations?

We recommend allowing our traffic by either allowing access by User Agent string or IP address. 

 

Synthetic Monitor executes from a private location but fails to connect to an application

In addition to the checks for public locations, here are some helpful tests you can try from your private location. 

 

Troubleshoot using Curl

Use this command to confirm whether the connection issue relates to Dynatrace or the machine. 

curl -vki <url you're testing>

Or if you're using a proxy:

curl -vki -U proxyUser:proxyPassword -x proxy:proxyPort <url you're testing>

If the site is redirected to another page, you also need to add -L to follow redirects. For example, 

curl -vki -L <url you're testing>

 

What can you do if the result of the command fails?
If the curl command fails, the issue lies in the connection between the machine and the application you're testing. Here's what you can do to fix it:

  1. Update your proxy or allow the IP access.

If the result of the command is successful

  1. Check if the Dynatrace User-Agent string affects the behavior
    1. For HTTP Monitors, add -H "User-Agent: DynatraceSynthetic/1.267.13.20230518-162314"  
      curl -vki <url you're testing> -H "User-Agent: DynatraceSynthetic/1.267.13.20230518-162314"​
    2. For Browser Monitors, add -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 RuxitSynthetic/1.0 v0 t0 cfeatureHash=7efgijmoqtvx caes=1 ccux=1 sia=1 smf=1"  
      curl -vki <url you're testing> -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 RuxitSynthetic/1.0 v0 t0 cfeatureHash=7efgijmoqtvx caes=1 ccux=1 sia=1 smf=1"


What can you do if the command's result fails? You should allow/ allowlist our User-Agent string on your Application/ Firewall. 

 

Troubleshoot using PowerShell

If you're working on Windows, you may only have the option of PowerShell instead of curl. You can use Invoke-WebRequest. 

Without proxy:

Invoke-WebRequest -Uri "<url you're testing>"

With proxy:

Invoke-WebRequest -Proxy "<proxy-url>:<proxy-port>" -ProxyUseDefaultCredentials -Uri "<url you're testing>"

With redirects following and printing raw response:

Invoke-WebRequest -MaximumRedirection 10 -Uri "<url you're testing>" | Select-Object -Expand RawContent

 

What can you do if the result of the command fails
If the curl command fails, the issue lies in the connection between the machine and the application you're testing. Here's what you can do to fix it:

  1. Update your proxy or allow the IP access.

If the result of the command is successful

  1. Check if it's the Dynatrace User-Agent string by adding that header to the Invoke-WebRequest command
    • For HTTP Monitors, add -H "User-Agent: DynatraceSynthetic/1.267.13.20230518-162314" 
      Invoke-WebRequest -Uri "<url you're testing>" -Headers @{"User-Agent"="DynatraceSynthetic/1.267.13.20230518-162314"}​
    • For Browser Monitors, add -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 RuxitSynthetic/1.0 v0 t0 cfeatureHash=7efgijmoqtvx caes=1 ccux=1 sia=1 smf=1"  
      Invoke-WebRequest -Uri "<url you're testing>" -Headers @{"User-Agent"="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 RuxitSynthetic/1.0 v0 t0 cfeatureHash=7efgijmoqtvx caes=1 ccux=1 sia=1 smf=1"}

 

What can you do if the command's result fails? You should allow/ allowlist our User-Agent string on your Application/ Firewall. 

 

Troubleshoot using a Browser on the Synthetic ActiveGate

If it has a GUI, you can test Browser Monitors from your Synthetic ActiveGate. This is usually the case for Windows ActiveGates, so I'll focus on those. 

  1. Open a Chrome Browser on your Synthetic ActiveGate and navigate to the URL you're testing.
    1. If you can't reach it, the problem is that the machine itself can't reach the URL.
      Allow/ allowlist the IP or update your proxy settings.
  2. If you can access Dynatrace from the ActiveGate, playback the monitor in the Browser.
    1. If it fails, it may be the User Agent string. As mentioned above, you can confirm this using curl or PowerShell. 
  3. Open the Browser that the ActiveGate uses to execute the monitors. The default path is C:\Program Files\dynatrace\synthetic\Chrome-bin\chrome.exe.
    1. If this fails, compare the difference in version to the Chrome Browser installed on the machine. 
  4. Sometimes, the service user who starts Chrome doesn't have enough permissions to reach the site. Please do the following to check if that is the case: 
    1. On the Synthetic ActiveGate, download and unzip PsExec https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
    2. Open a command prompt as administrator (Start -> cmd.exe -> Run as administrator) and navigate to the folder you extracted PSExec
    3. To start Chromium impersonating the "Local Service" user, run PsExec with the following command:  
      PsExec.exe -i -u "NT Authority\LocalService" "C:\Program Files\dynatrace\synthetic\Chrome-bin\chrome.exe"​

      (If you installed the synthetic location in a non-standard path, you'll need to adapt the path to chrome.exe)

    4. Then navigate to the URL you're testing. If this fails, you may wish to try setting up Kerberos authentication for your browser monitor or logging in to the Dynatrace Synthetic service as a domain user.

 

Synthetic Monitor data is not returned to, or seen by, Dynatrace

For SaaS tenants

  1. Confirm that the monitor is enabled.
  2. Confirm that there are no maintenance windows during the data gap. This can be confirmed on the browser monitor details page or the HTTP Monitors details page.
  3. If it's on a private location
    1. Check for WebSocket errors in the logs. 
    2. Confirm that no Antivirus or anti-malware applications are running. If there are, try disabling them and restarting the Dynatrace Synthetic/ VUC service. If this resolves the issue, modify the Antivirus or anti-malware application to allow Chromium and the Synthetic module to run without interference. You can find suggestions for rules here.

If you can't find a cause, open a chat or create a ticket. 

 

For Managed tenants

  1. Confirm that the monitor is enabled.
  2. Confirm that there are no maintenance windows during the data gap. This can be confirmed on the browser monitor details page or the HTTP Monitors details page.

  3. Confirm that the Cluster ActiveGate URL is publicly available. It can be limited to access from public location IP addresses if necessary.

    1. select the Test connection to URL button under Settings/Public endpoints in the Cluster Management Console.
      This tests four types of public connectivity to the Cluster ActiveGate: Synthetic, internal and external users for RUM, and external OneAgent comms.

      If Synthetic fails, the Cluster ActiveGate is not publicly available, and you'll need to update your Firewall or Load balancer settings to allow access. You can ignore this if you have limited access to specific IPs.  

  4. Confirm that the Synthetic endpoints are all open
    beacon/[uuid]
    Synthetic health checks /beacon/synthetic/[uuid]
    HTTP Monitors /beacon/synthetic/httpresults[uuid]
    screenshots /beacon/synthetic/screenshot/[uuid]
    Browser Monitors /beacon/synthetic/browser/[uuid]
    Multiprotocol monitors /beacon/synthetic/multi-protocol/[uuid]
    Credentials /beacon/synthetic/credentials/[uuid]

  5. Run a health check. This can be run from anywhere if you're not limiting access to specific IPs.  
    https://<Cluster AG Public Url>:<port>/beacon/synthetic/<environment UUID>?healthcheck&tenantId=<environment UUID>

     

    and the response should be JSON file like this

    {"ts":1680601930205,"activeGateId":nnnn,"activeGateVersion":"1.261.166.20230308-123141","activeGateWorkingMode":"MANAGED","tenantAvailable":false,"syntheticLicenseAvailable":false,"rumLicenseAvailable":false,"rumConfigRevision":-1,"imgAvailable":false,"hmResultsAvailable":false,"failureScreenshotInterval":3600000,"clusterVersion":"","clusterUUID":"","jsAgentVersion":"","protoVersion":1,"httpMonitorsResultsPath":"","screenshotsPath":"","mpmResultsAvailable":false,"credentialsPath":""}

    If you can't find a cause, open a chat or create a ticket. 

 

Solutions

Once you've done the checks and determined the root cause of the problem, here are some possible solutions that you can apply

 

Allow/ Allowlist by User Agent string

Synthetic Monitors can be recognised by the User Agent string they add in the request headers. This string can be used in Firewalls, etc., to identify Synthetic traffic and allow it. 

For Browser monitors, we add 

RuxitSynthetic/1.0

and some extra parameters after that. You can find the full list here.

For HTTP Monitors, we add 

DynatraceSynthetic/{version}

The version changes with each release, so you may wish to use DynatraceSynthetic/instead. The complete list is here.

 

Allow/ Allowlist location IPs

IPs can be used to identify Synthetic traffic and allow it to pass through Firewalls, etc. 

You can find the IPs used by our public locations using the Frequency and Locations page in the WebUI or the Synthetic locations API—GET all locations API call. Further details are available here. These are individual IPs, so the subnet mask is /32 for all of them.

 

We don't list private location IPs, but you can find them in the WebUI in Deployment Status> ActiveGates. You can then filter for either the location you're interested in or all Synthetic ActiveGates and open each ActiveGate details tile to check the IP addresses.

 

Add/update Proxy configuration.

If you need to connect to your application through a proxy or bypass it, you may need to add some further configuration to your proxy to allow access from the machine/ location.

If the necessary change has already been made to the proxy, we provide information on setting up ActiveGate to use different proxy connection scenarios here.

In addition to this, if you need only to add the proxy settings for Monitors (both HTTP and Browser) or S3 (screenshot storage), you can add the following flags to ActiveGate Synthetic user.properties file

  • default Linux path: /var/lib/dynatrace/synthetic/config/user.properties
  • default Windows path: C:\ProgramData\dynatrace\synthetic\config\user.properties
com.vuc.proxy.s3.enabled=false
com.vuc.proxy.monitor.enabled=true

The above snippet would enable Monitors to use the proxy settings specified in custom.properties, but S3 would bypass the proxy and use a direct connection. 

There is no separate setting for Browser and HTTP Monitors; however, Browser Monitors can use PAC files, which can be used to achieve a different proxy for HTTP Monitors and Browser Monitors. 

 

Log in to the Dynatrace Synthetic service as a domain user

Note: this is usually needed for applications using Kerberos authentication. Before making this change, it would be good to try using the Kerberos authetication option.  

 

For applications that need to be opened in a Browser started by a domain user, you can update the user that the Dynatrace Synthetic service logs on as.

IMPORTANT: Dynatrace does not support this and must be re-configured every time the ActiveGate is updated. We recommend disabling auto-update for these ActiveGates, and a maintenance window to cover the update period, and re-configuring the log-on user. 

  1. On the Synthetic ActiveGate, in Services, right-click on Dynatrace Synthetic service> select properties> select Login On tab.
  2. Change  'Local Service' to a domain user, enter the password, and Save.
  3. Restart the Service.

To revert to using the Local Service user

  1. On the Synthetic ActiveGate, in Services, right-click on Dynatrace Synthetic service> select properties> select Login On tab.
  2. Change the domain user to 'Local Service' with no password and Save.
  3. Restart the Service.

If this doesn't resolve the issue, open a support ticket.

 

What's Next

If none of the previous steps resolved the issue, open a chat or support ticket and provide

  • a description of the problem
  • a link to the affected monitor
  • the troubleshooting steps you have already completed and the outcome of each step

You can find further troubleshooting tips for Synthetic in the Synthetic Troubleshooting Map

Version history
Last update:
‎21 Oct 2025 12:47 PM
Updated by:
Dynatrace Guru
Comments
ChadTurner
DynaMight Legend
DynaMight Legend
‎08 Jun 2023 07:49 PM

great write up, thank you for sharing this! 

DanielS
DynaMight Guru
DynaMight Guru
‎08 Jun 2023 08:51 PM

Terrific Guide!!!! Thks for sharing this.