I need to ping an IP outside of my company.
For HA i can acces it through 2 different gateways from 2 different ISP.
They are MPLS connections so im given an end here with an IP assigned by the owner of the remote device which i need to ping. I have a Fortigate Cluster and i nat those gateways to internal IPs.
My problem right now is that i need to ping that device through both MPLS to check availability. I can nat one to my PRTG IP, but for the other i need PRTG to ping using another source IP to ad a new nat rule for the other connection.
Is there a workaround for this?
Thanks in advance,
Tomas
Article Comments
Hello Tomas,
we appreciate your inquiry.
This is indeed a tricky situation: Kindly understand that there isn't a way for PRTG to "choose" it's gateway, the same also applies when issuing a normal ping from command-line. The default gateway will be used.
The recommended solution is indeed to create two distinct devices within PRTG with different addresses (You can name the devices "MyDevice via ISP A" and "MyDevice via ISP B" to make it easier to understand.)
Regardless of that, the actually Policy Based Routing (or NATting) has to be performed by your Router/Firewall.
There is one workaround I can think of which would be using an Port Sensor within PRTG instead, then create your PBR to point two distinct ports to the same port on the remove device using each available gateway. That way you can keep a single device within PRTG and have one sensor for each gateway.
| SourceIP | SourcePort | DestinationIP | DestinationPort | Gateway |
| LocalIP | 8001 | RemoteIP | 80 | Gateway A |
| LocalIP | 8002 | RemoteIP | 80 | Gateway B |
If you don't care about using custom Sensors, you could also create an EXE/Script Advanced Sensor to ping both devices (using powershell test-connection or similar) and supply both destination IP's as parameter within the script instead of using the device's address. This solution requires coding and is less performatic than the port sensors solution, but should also work.
Kindly note that we can't provided detailed assistance regarding the configuration of router router/firewall/device.
Best Regards,
Sep, 2015 - Permalink
Hi tferrin
I dont know if that works but should, but you could script it (quite a hack) with custom sensor.
Sensor 1 -> GW 1
route add 8.8.8.0 MASK 255.255.255.0 192.168.1.2 Metric 1
ping 8.8.8.8 OR tracert 8.8.8.8
route delete 8.8.8.0
Sensor 2 -> GW2
route add 8.8.8.0 MASK 255.255.255.0 192.168.1.1 Metric 1
ping 8.8.8.8 OR tracert 8.8.8.8
route delete 8.8.8.8
I don't know if the builtin PING commando to choose a GW works, can't test it here.
ping -k 192.169.1.2 microsoft.com
cheers
Thomas
Sep, 2015 - Permalink
Hello Tomas,
we appreciate your inquiry.
This is indeed a tricky situation: Kindly understand that there isn't a way for PRTG to "choose" it's gateway, the same also applies when issuing a normal ping from command-line. The default gateway will be used.
The recommended solution is indeed to create two distinct devices within PRTG with different addresses (You can name the devices "MyDevice via ISP A" and "MyDevice via ISP B" to make it easier to understand.)
Regardless of that, the actually Policy Based Routing (or NATting) has to be performed by your Router/Firewall.
There is one workaround I can think of which would be using an Port Sensor within PRTG instead, then create your PBR to point two distinct ports to the same port on the remove device using each available gateway. That way you can keep a single device within PRTG and have one sensor for each gateway.
If you don't care about using custom Sensors, you could also create an EXE/Script Advanced Sensor to ping both devices (using powershell test-connection or similar) and supply both destination IP's as parameter within the script instead of using the device's address. This solution requires coding and is less performatic than the port sensors solution, but should also work.
Kindly note that we can't provided detailed assistance regarding the configuration of router router/firewall/device.
Best Regards,
Sep, 2015 - Permalink