Need a sanity check. When deploying multiple ISPs using path monitoring, instead of policy-based forwarding, should the second ISP become unreachable? It makes sense that it does, but it wasn't mentioned in a Palo Alto Networks article.
Setup would be:
ISP1 (e1/1) 0.0.0.0/0 126.96.36.199 priority 10 (with path monitoring)
ISP2 (e1/4) 0.0.0.0/0 188.8.131.52 priority 200
VPN tunnels for both ISP1 and ISP2 using tunnel monitor
With this config:
ISP1 tunnel is up, e1/1 is pingable from outside
ISP2 tunnel is down, e1/4 is NOT pingable from outside
If you don't use PBF, this behaviour is expected.
Without PBF, firewall will try to establish VPN with source IP assigned on eth1/4, but it will forward the traffic over eth1/1 and ISP1, where most probably traffic will be dropped, since it is sourced from IP that doesn't belong to this ISP.
In this case, ISP2 tunnel should come up, in case of failover - path monitor fail and remove default over ISP1
and ISP1 tunnel will go down, respectively.
If you prefer to have both tunnels IP and ready, you could create a PBF so traffic sourced from eth1/4 to always go over ISP2.
I personally always try to avoid PBF, primarily because engineers often forget to check it during pacy troubleshooting. However, the truth is PBF could be very helpful in some situations.
I would say:
- If you need simple failover between two ISP absolutely go for path monitor on static route
- But in addition to the failover you need faster recovery for the IPsec tunnel you will need PBF to keep the second tunnel ready to take over.
Don't forget to you either case you will need tunnel-monitor or PBF with path-monitor for the routing over the tunnel. Once primary tunnel goes down, you need to switch the route to second tunnel. You could again create PBF that will monitor the path over the tunnel and when down, to switch to second. This was the preferred way for IPsec failover way-way back. May preferable way is to use tunnel-monitor, so firewall will "disable" the static route pointing to tunnel1 and fallback to route pointing to second tunnel.
Regarding the monitored host...I am not the best person to define best practices. I have had few cases where path-monitor was required and in all cases we used 184.108.40.206 and it was fine.