New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


What connection settings are necessary for the QoS (Quality of Service) Round Trip Sensor?

Votes:

0

Your Vote:

Up

Down

I want to use the QoS (Quality of Service) Round Trip sensor to monitor the quality of the network connection between two of my probes. On the QoS Round Trip Sensor's manual page I see the following note:

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

I have a few questions regarding this note:

  1. What exact firewall settings are required?
  2. Is this saying that the firewall configuration that already allows my Core Server to communicate with all of my Remote Probes is insufficient for the QoS sensor's operation?
  3. If I configure a round trip QoS sensor on my local probe, do I need to configure the firewalls at remote probes to allow inbound UDP traffic to those sensors?
  4. Firewall configuration is a hassle. Paessler could probably have avoided that by defining remote probes to open those NAT rules automatically by initiating testing to my local probe, right? I.e.: Sensors on both ends.
  5. If all of this is necessary, wouldn't it be simpler if I opened a single inbound port on my local firewall and configured QoS sensors on the remote probes pointing at the local probe? Seems a lot of work given that they can already reach my core server.
  6. Also, I'm looking for better ways to monitor non-VoIP connection quality. Would you say that the PRTG VoIP QoS sensors are good for that as well?

firewall qos rule settings udp

Created on Jul 21, 2015 8:32:25 AM by  Luciano Lingnau [Paessler Support]

Last change on Jul 27, 2015 2:38:17 PM by  Martina Wittmann [Paessler Support]



1 Reply

Accepted Answer

Votes:

2

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 15.2.17 and later

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 Round Trip Sensor, you should be aware of the following note:

Note: You must ensure that firewalls, NAT rules, etc. will allow the UDP packets to reach the target probe. The Windows firewall on the target system will be 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 6 answers below.

Question 1:

What exact firewall settings are required?

When creating the QoS Round Trip Sensor, PRTG asks you for a port number. The default port is 50000. When deploying more than one QoS Round Trip Sensor we recommend that you use a different port for each instance of the Round Trip Sensor, (i.e. 50001, 50002, ...). Each new port that you use in a QoS Round Trip has to be allowed on the whole 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 Core Server to communicate with all of our Remote Probes is insufficient for the QoS sensor's operation?

Briefly: Yes. To find out which ports PRTG uses, have a look at our Knowledge Base article 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's why the QoS sensor uses UDP and the core-probe-connection is a TCP connection.

Question 3:

If I configure a QoS Round Trip sensor on my local probe, do I need to configure the firewalls at remote probes to allow inbound UDP traffic to those sensors?

The QoS Round Trip sensor is always configured between either two probes or a probe and a QoS reflector. The firewalls/routers of the involved probes have to be configured to allow/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 open those NAT rules automatically by initiating testing to my local probe, right? I.e.: Sensors on both ends.

Although home-grade equipment normally supports configuration-free protocols like UPNP that can auto-configure NAT in some cases, most enterprise-grade equipment doesn't (for several reasons, including security).

Question 5:

If all of this is necessary, wouldn't it be simpler if I opened a single inbound port on my local firewall and configured QoS sensors on the remote probes pointing at the local probe? Seems a lot of work given that they can already reach my core server.

Each QoS 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 sensor on the same probe so that it can correlate each UDP traffic and can correctly monitor the traffic.

Question 6:

Also, I'm looking for better ways to monitor non-VoIP connection quality. Would you say the PRTG VoIP QoS 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. The QoS Round Trip Sensor's manual page shows the list of metrics measured by the sensor.
It is possible to use the QoS sensor and configure your own channel limits to make it less sensible. 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 Traffic Sensor on the remote router shows bandwidth consumption.

Created on Jul 21, 2015 8:48:19 AM by  Luciano Lingnau [Paessler Support]

Last change on Jul 28, 2015 8:03:49 AM by  Martina Wittmann [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.