Votes:
I want to use the QOS Roundtrip Sensor with a custom target. How do I set up the PAT rules in my firewalls?
Created on Oct 31, 2014 1:27:23 PM by
Last change on Oct 31, 2014 5:56:57 PM by
2 Replies
Votes:
This article applies to PRTG Network Monitor 14.4.12 or later
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:
In the Fritzbox we had to go into the port forwarding section and set up the following rules:
This rule is set up to take the packets that are coming into the WAN interface on the Fritzbox on IP 168.168.168.1 on port 50001 and PAT them to the inside IP of 192.168.2.18 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.
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 192.178.2.2 50003 interface Dialer1 50003
The Dialer1 interface is a PPOE Connection to our provider with the WAN IP 168.168.1.1. 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.
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.
Along with this PAT rule, we also need to set up our Firewall to allow these packets through.
LAN -> WAN
WAN -> LAN
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.
Created on Oct 31, 2014 3:16:53 PM by
Last change on Oct 31, 2014 5:58:02 PM by
Votes:
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:
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:
There are some advantages:
Note: we still need to open port 50000 on remote NAT to allow incoming packets to go through to remote probe or QoSReflector.
Last change on Aug 28, 2018 4:29:27 AM by
Add comment