Outbound policy rule... enforced, but prioritized when link is down

Hello,

I have an application that must use a single WAN connection if at all possible. In the event the connection goes down, then the app does not work without manually logging into the router and changing it to something else.

Can we get an option to have enforced, but only allow it to choose something else when the WAN is down? I’ve tried Priority, but it seems to pick from any in the list that are active based on some kind of logic, maybe utilization?

We’ve found that “Priority” works as intended so long as the follow-on or secondary WANs are healthy.

'I’ll suggest another option for your consideration – SpeedFusion Cloud. In that situation you would set the priority in SFC and that connection would be maintained as long as you have a healthy WAN in the priority list and the route-able IP (exit point) would be unchanged. We have several examples of where this “saved the day” – one of which is commercial and residential alarm systems . These often have circuitry that is probably 30+ years old (literally) and firmware that is never updated. These panels get “confused” when anything changes.

If you are really certain that “Priority” is not working “as advertised” that would probably justify the submission of a ticket. I must say, however, we’ve found it to work as intended. The Peplink Partner from whom you acquired the router should also be helpful in this.

Priority outbound rules have a Priority Order list. My experience is that the list only works within the Connection Priority group currently active as seen on the Dashboard. So if you want a Priority outbound rule’s Priority Order list to work, I make everything Connection Priority 1 on the Dashboard. You do this on WAN configuration where you find “Connection Priority” can be set to “Always On (Priority 1)” rather than “Backup” (the Surf Soho defaults to the WAN to Priority 1 and USB to Backup, whereas Balance routers seem to default multiple WAN’s to Always On).

If you don’t have any Priority or Enforced outbound rules, then the order of WAN’s on the Dashboard for Priority 1 defines the order of failover within Priority 1 (drag them around to change the ordering).

Hopefully I have this correct. It has been a learning experience and others are welcome to comment/correct.

Yes, you have it correct @Mark9 . Rules are interpreted “top down” and only apply to WANs that are active and healthy. So, if a given WAN is not “always on” and healthy it will be disregarded.

Your comments regarding WAN Priority are relevant to some of Peplink’s line of routers. Not all. The WAN configuration of a Balance 380 via GUI is a bit different than a MAX BR1 Pro 5G for example.

@Xerxes, if you have a dual WAN situation, another straightforward approach should be to change “Connection Priority” in your backup WAN’s configuration to “Backup”.

I have four WANs on a Balance One.

Sorry for resuming a long ago topic but this is the closest I’ve found to solving my problem.

I have a starlink and want to be able to access the Dishy page (192.168.100.1) on the LAN side of the peplink.
normally it’s fine until the starlink looses coverage and then I cannot reach it.

I have an outbound policy in enforced mode.

However when the link is unhealthy, event log shows ‘Starlink (IF_WAN) down (no schedule)’, I am unable to get to the Dishy page.

Is there a way to enforce the outbound policy on an unhealthy link?

isnt starlink deprecating that page? or they may have already?

that direct page, probably. however the debug and statistics are still accessible with API calls which require routing. I’m just using that page as a stand in for routing / testing.
If I can / cannot get there, then the API calls will be ok / not ok etc.

Given Peplink pulls the API data anyway once you enable the ‘Starlink’ feature in the WAN interface it may be redundant but until the bosses change their mind, I’m stuck trying to make it work.

I’d also like to understand why the enforce policy doesn’t enforce on unhealthy links despite saying it should