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
How can I use the new QOS Custom Target with PAT?
Votes:
0
2 Replies
Accepted Answer
Votes:
1
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.
Diagram
Here is a small diagram showing what the set up looked like:
Fritzbox Rules
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.
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 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.
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.
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.
See Also
Created on Oct 31, 2014 3:16:53 PM by
Last change on Oct 31, 2014 5:58:02 PM by
Votes:
6
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.
Last change on Aug 28, 2018 4:29:27 AM by
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.
Add comment