The machine running our PRTG core server does not have full internet access. Which URLs do I need to make available to the core server so I can use the auto-update functionality and automatic software activation? Are there sensor types that connect to external sources?
Which servers does PRTG connect to for software auto-update, activation, etc.?
This article applies to PRTG Network Monitor 19 or later
PRTG connections to external servers
PRTG needs to connect to several external servers for full functionality. These connections are required for several purposes, such as PRTG updates and licensing, for notifications, and for monitoring with certain sensor types.
See the table below for external servers that PRTG tries to reach, depending on your PRTG usage.
To use PRTG Auto-Update, the machine that is running the PRTG core server needs internet access (either directly or via proxy) to different (sub) domains so that update checks and downloads can work correctly:
|(Sub) Domain||Protocol||Port #||Remarks|
|downloads.paessler.com||Hosted on Cloudflare|
*Note: Because the IP addresses can change dynamically, we do not recommend that you apply policies based on IP. Understand that we cannot provide IP addresses for Amazon servers.
PRTG license activation
Software activation is a one-time process that is necessary for all installations running with a license key. PRTG will try to automatically activate every installation on first start up. Later, it will periodically connect at least every 7 days and receive updates on the license, for example, the remaining maintenance days. For this all to work, the machine that is running the PRTG core server needs internet access (either directly or via proxy) to at least one of the following (sub) domains:
|(Sub) Domain||Protocol||Port #||Remarks|
Note: Because the IP addresses can change dynamically, we do not recommend that you apply policies based on IP.
When you receive emails from PRTG that are created using the PRTG default HTML email templates, your email client may try to connect to the Paessler server to download images (for example, colored sensor icons). To be able to view these emails properly, allow your email client to get the images from our server.
|(Sub) Domain||Protocol||Port #|
Emails from Paessler directly come from mailserver.paessler.com with IP 126.96.36.199
Several sensor types need to connect to external servers to show monitoring data. Make sure that the probe system(s) on which you run such sensors can reach the target domains.
|External Source||Sensors and Remarks|
|*.amazonaws.com||Amazon CloudWatch sensors: The first part of the domain depends on your region and configuration.|
|https://api.prtgcloud.com:443||Cloud HTTP and Cloud Ping sensors|
|http://windowsupdate.microsoft.com and other Windows update domains||Windows Updates Status (PowerShell) sensor (if WSUS is not available)|
|Automatic Root Certificates Updates (via Akamai CDN)||SSL-secured sensor connections (see Why is there strange traffic on a probe when monitoring ESX hosts?)|
|DNS servers||DNS resolution for several sensor types (see How DNS query works on Microsoft TechNet)|
|External Source||Notification Type|
|*.amazonaws.com||Amazon SNS notification: The first part of the domain depends on your region and configuration.|
See this article for the URLs that PRTG uses for the preconfigured SMS providers:
See this article for the URLs that PRTG uses for the Geo Maps providers:
You can send support requests and support bundles by using the Contact Support form in PRTG. PRTG will securely transmit these requests to Paessler via the PRTG Cloud. Make sure that your PRTG server has access to the internet and can reach the following URLs:
|(Sub) Domain||Protocol||Port #||Usage|
|activation1.paessler.com||https||443||Login page RSS Feed|
|www.paessler.com||https||443||Login page RSS Feed|
- Which information does PRTG send back to Paessler?
- Which ports does PRTG use on my system?
- Proxy Configuration in PRTG Manual: Core & Probes
- PRTG Cloud Status: @PRTGCloudStatus
Would it be possible to provide a range of IP addresses/subnets of the above-mentioned servers? Applying policy based on domain names and a subsequent resolution has a severe impact on our enterprise firewall performance.
It looks lake this FQDN is also used 3.base.maps.api.here.com
thank you for your reply and input.
Please note that there's a dedicated article for the URL's used by Geo-Maps, please refer to:
Luciano Lingnau [Paessler Support]