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!