pfSense WAN-uplink monitoring - multiple IPs?

Hi there community,

long time lurker around Toms Youtube Channel. Just signed up in the forums.
@LTS_Tom
I appreciate your quality content and down to earth approach! Thank you for sharing your in depth knowledge.

We are a MSP/IT-systems company located in Germany. I’m a long time user of Sophos SG UTM and Palo Alto NGFW - I love some of their features, but also hate some stuff. For most of our small clients, pfSense would be a much cheaper and more versatile solution.

So currently I’m heavily evaluating pfSense and OPNsense. OPNsense seems still a little bit unpolished, so I’m already decided that pfSense is the way to go.

I just have some trouble understanding why such a rudementary feature like WAN uplink monitoring is implemented so poorly.

You can only monitor one public IP per WAN. This is not really failproof.

For example:

  • You use the default settings - next hop (ISP gateway) will be monitored. This won’t tell you anything about routing issues after the ISP. It will just tell you if the next-hop is up or not.
  • You use Google DNS 8.8.8.8. Their routing is provided by anycast. If some provider has issues routing to 8.8.8.8, you will have a bad time, eventhough internet routing to other destinations will still work properly.
  • If you use 8.8.8.8, you can’t use it as DNS anymore as it will be marked down in case of failure.
  • You have to use a unique monitor IP per WAN-uplink.

Why not a block of 2 or 4 public IPs which can be used for all the WAN-uplinks?

My favorite block is:
8.8.4.4
8.8.8.8
1.0.0.1
1.1.1.1

This is less prone to false-positives. Most of the other firewall/router vendors have this possibility implemented.

I even wrote a bash-script on a armbian-based microcontroller once, which does exactly the following:

Fill it with an array-list of default-gateways and give it some ping-hosts.
For example:

default gatewas:
192.168.1.1
10.1.1.1

ping hosts:
8.8.8.8
1.1.1.1

The script will set 2 static routes for the ping-hosts over the first gateway in the array list.

Something like:
8.8.8.8/32 via 192.168.1.1
1.1.1.1/32 via 192.168.1.1

I was then evaluating the ping exit codes:
Exit code 0 = success
Exit code 1 = no reply

whatever code was spit out, decided to use this default gateway or try the next one in the array.

So I can’t wrap my head around this.

I’m aware that the pinger-daemon in pfSense is dpinger and it’s also considering packet loss and other values. Yes, this is a benefit compared to normal pinging, but if the basics are not failproof, what kind of use does the packetloss/jitter feature have?

Do you guys have the same problem? Are you using any workarounds?!

Thank you in advance!

I think the pfsense team only see the system as needing the use that data to determine if a WAN is down so it can fail over to the other one. There are better tools such as https://www.solarwinds.com/network-performance-monitor/use-cases/netpath that offer better and more detail route information. But route troubleshooting has not really been something that we have had to spend much time on at all. Most often we just seen ISP’s go down or sites go down, rarely is it something else.

Hi Tom!

I think you misinterpreted my core-question.

I’m not looking for routing-analysis - rather a better approach to make uplink monitoring more fail-proof and being able to use multiple monitoring destinations for each uplink.

Just asking around if you or some other guys on the forum are using any other plugins, special shell scripts or other workarounds for that.

I have not had an issue so I guess I don’t understand the need for multiple IP addresses for the firewall to monitor.

So you are just monitoring the next hop?

We monitor next hop, unless next hop is on premise which is the case sometimes with fiber. When that happens we go one more hop.

I realise you’re wanting to do this inside of PFS (ideally) but would something like FreshPing + Slack provide some sort of solution? I use it to monitor my site, public WAN IP, email server, sip server and some other things for downtime.

Hey Tom! Did your inspiration to do this video come from this thread? :smiley:

I was just browsing youtube and saw your clip released a few hours ago, what a coincidence :wink:

Some people state the same concerns in the comment section as I do. Yes, this might run fine for some people, but I think this is still not very failproof.

We might develop our own gateway extension/dpinger tool, so we can ping multiple IPs and still will be able to evaluate some kind of a average value for packetloss and latency and trigger some actions like mentioned in your video. Is anyone interested? This might take a while as we are still evaluating some scenarios with pfSense.

1 Like

Hi ZaK86,

yes, it would be much better to have it inside of pfSense. We don’t like to rely on external cloud services.

But thanks for your thoughts.

1 Like

Yes, this post and others asking the same questions inspired this particular video. I think it would be interesting to have an official pfsense plug in that kept tracks of a series of IP addresses and their relative route / ping quality would be a great addition to the system.