We have been cooking up some large internal changes for the multi-platform probe. Soon, probe-to-core communication will happen over the modern internet communication protocol QUIC. If you have recently watched a YouTube video or otherwise used HTTP/3, then you will have used QUIC already.
Firstly, this offers PRTG and Multi-Platform Probe operators an easier setup and onboarding experience (fewer wizard questions, and fewer user roundtrips between Core and Probe). This experience now resembles the Classic Windows Probe onboarding flow.
Secondly, communication security is improved with Ed25519-based probe authentication and TLS 1.3 during communication.
Thirdly, performance is improved over TCP-based NATS communication. The resilience and responsiveness of roaming probes (deployments on ships or satellite up/downlink) will improve drastically.
Curious how PRTG monitors distributed and remote infrastructure in practice? Start a free trial and see your entire network - probes, roaming or not - in one dashboard.
In 2021, QUIC was defined in RFC 9000 as a modern internet communication protocol. Since then, major browsers have adopted it, and it has been widely adopted throughout the internet.
QUIC improves over TCP by fixing head-of-line blocking across streams (one of TCP's famous flaws), adding connection migration and fast reconnects (multi-homing, multi-pathing), adding obligatory connection security (TLS 1.3), adapting flow control and congestion control to modern workloads, and more.
The multi-stream, reliable, highly secure nature of the QUIC protocol facilitates probe-to-core communication in even more environments and situations, while offering better performance characteristics (especially in adverse scenarios such as packet loss or unreliable transport).
Note that while QUIC happens to use UDP as a transport protocol, this does not mean QUIC doesn’t offer reliable delivery. It makes the same delivery guarantees TCP makes.
NATS served us well over the years. As we have learned about how our customers use the Multi-Platform Probe, we have learned that we can get away without the complexity it adds.
The only thing better than NATS: no NATS!
This removes the need to install, deploy, maintain, patch and host a dedicated NATS Server for us and our users.
PRTG (and the operator) no longer need to deal with NATS Tenants, NKeys, or the Paessler-supplied natsmanager.
Additionally, even though we weren’t impacted by them, the NATS ecosystem has collected a number of CVEs. By removing NATS from the system, we prevent past and future issues there from becoming real problems for our users.
Some of our customers used a NATS server to isolate external-facing services on the network. The same result can be achieved by using a firewall. In case this is not sufficient for you, please contact our support! We are exploring options in this space and would love to discuss your specific requirements.
Want to see how PRTG keeps distributed teams and remote sites monitored, no matter what the network throws at them? Download the free trial and check it out for yourself.
In cases where QUIC cannot be used for any reason, a direct TCP/TLS connection is supported as a fallback. This will be an explicit choice during probe deployment/configuration. The TCP connection offers comparable connection security as QUIC.
Once this is released, we ask our existing Multi-Platform Probe customers to re-run the Multi-Platform Probe Configuration Wizard. This will produce a single Probe Access Token, which is a single string to be entered in PRTG. Onwards, the Probe and PRTG will communicate using port 23563/UDP for QUIC (or 23563/TCP for the TCP/TLS fallback, if so configured). Remaining 23561 port rules for NATS will be removed automatically by the PRTG installer.
There's no fixed release date yet. The earliest you'll see this is with PRTG version 126, expected in late 2026.