What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags

View all Tags

How can I use the new QOS Custom Target with PAT?



I want to use the QOS Roundtrip Sensor with a custom target. How do I set up the PAT rules in my firewalls?

custom-target prtg python qos qos-reflector qos-roundtrip

Created on Oct 31, 2014 1:27:23 PM by  Greg Campion [Paessler Support]

Last change on Oct 31, 2014 5:56:57 PM by  Gerald Schoch [Paessler Support]

2 Replies

Accepted Answer



This article applies to PRTG Network Monitor 14.4.12 or later

How to set up a QOS Reflector with PAT

What we tested out here at Paessler was setting up a Windows machine running Python and our new QoS Reflector script behind a Fritzbox WAN router and used our PRTG core, which was behind a Cisco 800 series router and a Sonicwall Firewall, to send the reflector QoS packets through a QOS Round-Trip Sensor.

The packets were sent to the reflector over port 50001 and the reflector was set to receive packets on port 50003 so we had to set up PAT on the Fritzbox and respectively on the Sonicwall we had to set up the returning packets (which would be sent back on port 5003 to be translated back to port 50001.


Here is a small diagram showing what the set up looked like: Diagram of Setup

Larger Image

Fritzbox Rules

In the Fritzbox we had to go into the port forwarding section and set up the following rules:

Fritzbox QOS PAT Rule

Larger Image

This rule is set up to take the packets that are coming into the WAN interface on the Fritzbox on IP on port 50001 and PAT them to the inside IP of on port 50003. This way the reflector receives the packets on the expected port 50003. It will bounce this packet back with information on trip time to the originator but on port 50003.

Since our sensor is sending on port 50001, it will expect the answer to come back on the same port so we need to PAT the returning packet with the Sonicwall.

Cisco 800 Series Rule

First we had to set up the Cisco Device to forward the packet to the Sonicwall without PATing the packets. We used the following NAT rule to do this:

ip nat inside source static udp 50003 interface Dialer1 50003

The Dialer1 interface is a PPOE Connection to our provider with the WAN IP This could be any other WAN connection based on the type of connection you have to your ISP. Note that the ports in this rule are both 50003 since we are only NATing this traffic.

Sonicwall Setup

Now that we have the packets being sent through the Cisco, now we have to PAT the packets going through the Sonicwall to the PRTG Core Server. For this we use this rule in the Sonicwall.

Soniwall NAT Rule

Larger Image

Along with this PAT rule, we also need to set up our Firewall to allow these packets through.


LAN to WAN rule

Larger Image


WAN to LAN rule

Larger Image

With these two settings the PRTG server will now receive the UDP packets from the reflector on port 50001 with the information on how long it took etc for the sensor.

See Also

Created on Oct 31, 2014 3:16:53 PM by  Greg Campion [Paessler Support]

Last change on Oct 31, 2014 5:58:02 PM by  Gerald Schoch [Paessler Support]



Hi, I am setting up QoS Round Trip sensor behind NAT and I think it should be updated as the following:

Currently when the Core server sends out UDP packets to destination (remote probe or QoSReflector), destination port is 50000 (as default setting, or we can change to different port) and the source port is random (for example: 40000). But the sensor is listening on port 50000 to receive bounced back packets. So we have to open port 50000 on local NAT/Firewall to let bounced packets to come in. There are some drawbacks:

  • Increase Admin effort (to configure port forwarding or open port 50000 for incoming packets on local NAT/Router).
  • In some cases, we want to use PRTG to test customer network and we don't have access to their network equipments. With current behavior of PRTG, we can't perform the test because port 50000 is not open for incoming connections.
  • Port 50000 has to keep open all the time, so increase security risk.

There is a way to improve this. For basic NAT behavior, when you send out packets to public through NAT on source port (for example: 40000), it will allow incoming packets to go through on the same source port without the need of opening that port on the device. For example: Core server sends out UDP packets to destination on source port 40000 through NAT then NAT will allow incoming packets from public to port 40000 to go through. So to improve:

  • Core server should listen on whatever the source port it uses to send out packets (port 40000 in this example)
  • Or Core server can listen on the destination port the same as it is now (port 50000 in this example) but when sending out packets, it should choose source port the same (port 50000), so bounced packets to port 50000 can go through.

There are some advantages:

  • Administrator does not have to open port on local NAT.
  • Port will only open when there is a packet sending out from internal, and it will automatically close when the connection ends.
  • Can use this sensor to test in any environment without worrying about which ports are opening on the NAT.

Note: we still need to open port 50000 on remote NAT to allow incoming packets to go through to remote probe or QoSReflector.

Created on Aug 24, 2018 1:12:02 PM

Last change on Aug 28, 2018 4:29:27 AM by  Luciano Lingnau [Paessler]

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.