This article applies as of PRTG 22

Connection settings for the QoS (Quality of Service) Round Trip sensor

To successfully monitor the quality of a network connection between two probes using the QoS (Quality of Service) Round Trip sensor, you should be aware of the following note:

Note: You must ensure that firewalls, NAT rules, etc. allow the UDP packets to reach the target probe. The Windows firewall on the target system are automatically opened by the probe.

If you want to know more about how the sensor works and about some technical details behind this note, read the six answers below.

Question 1:

Which firewall settings are required exactly?

When creating the QoS (Quality of Service) Round Trip sensor, PRTG asks you for a port number. The default port is 50000. When you want to deploy more than one QoS (Quality of Service) Round Trip sensor, we recommend that you use a different port for each instance of the QoS (Quality of Service) Round Trip sensor, (that is, 50001, 50002, and so on). Each new port that you use in a QoS (Quality of Service) Round Trip sensor must be allowed to pass on the entire path between the involved probes. The protocol of the traffic generated by this sensor is UDP.

Question 2:

Is this saying that the firewall configuration that already allows my PRTG core server to communicate with all of my remote probes is insufficient for the operation of the QoS (Quality of Service) Round Trip sensor?

In short, yes. To find out which ports PRTG uses, see Which ports does PRTG use on my system?. The core-probe communication is encrypted TCP traffic. The nature of TCP traffic is very different from the nature of UDP traffic. That is why the QoS (Quality of Service) Round Trip sensor uses UDP and the core-probe connection is a TCP connection.

Question 3:

If I configure a QoS (Quality of Service) Round Trip sensor on my local probe, do I need to configure the firewalls on remote probes to allow inbound UDP traffic for this sensor?

The QoS (Quality of Service) Round Trip sensor is always configured between either two probes or a probe and a QoS reflector. The firewalls or routers of the involved probes must be configured to allow or forward the UDP traffic for the configured port in both ways.

Question 4:

Firewall configuration is a hassle. Paessler could probably have avoided that by defining remote probes to automatically open those NAT rules by initiating testing to my local probe, right? This means having sensors on both ends.

Although equipment for use at home normally supports configuration-free protocols like UPNP that can automatically configure NAT in some cases, most enterprise-grade equipment does not (for several reasons, including security).

Question 5:

If all of this is necessary, would it not be simpler if I opened a single inbound port on my local firewall and configured QoS (Quality of Service) Round Trip sensors on the remote probes pointing at the local probe? It seems to be a lot of work given that they can already reach my PRTG core server.

Each QoS (Quality of Service) Round Trip sensor involves two distinct but connected probes. The connection can be from the local probe to any remote probe, but PRTG will require a different port for each QoS (Quality of Service) Round Trip sensor on the same probe so that it can correlate each type of UDP traffic and can correctly monitor the respective traffic.

Question 6:

Also, I am looking for better ways to monitor non-VoIP connection quality. Would you say that the QoS (Quality of Service) Round Trip sensors are good for that as well?

VoIP is one of the most sensitive types of traffic that will go bad as soon as the connection is not nearly perfect. As a rule of thumb, if the connection is good for VoIP, it will be ok for anything. See the list of metrics that the sensor measures.
It is possible to use the QoS (Quality of Service) Round Trip sensor and configure your own channel limits to make it less sensitive. But in most cases, a Ping sensor from the local probe to the remote location already shows you the latency and reachability to the remote location. An additional SNMP Traffic sensor on the remote router can show you bandwidth consumption.