I have a Balance Two, with dual WANs configured.
I have outbound rules configured as follows:
Rule 1 → Specific traffic to WAN 1
Rule 2 → Zoom Traffic to WAN 1
Rule 3 → Zoom Traffic to WAN 1
Rule 4 → All remaining traffic → WAN 2
There was a recent issue where WAN 1 gateway was available, but had no internet access (due to an ISP issue). When that happened, all traffic was affected. Even that traffic which was destined for WAN 2. The only fix was to disable the outbound rules for WAN 1 and WAN 1 itself in the Peplink UI. Only then did the traffic start flowing again. This doesn’t seem like expected behavior.
Enforced rules, means just that… Only that wan… even if it is marked down.
If you want failover then you should use Priority, and drag the WAN’s into the order you want to use them… Wan1 at the top then Wan2 etc… WAN’s you don’t want at all get moved into column #2.
The enforced rules are for a specific subset of the traffic, not all of the traffic. All but the last rule should have been ignored for the traffic I was encountering issues with. In other words the conditions of the rules appeared to be ignored (but only when WAN 1 was down)
are you sure the packets are tagged with the dscp you expect?
Have you done a wireshark to check?
I feel like any any rules sometimes don’t work as expected.
Can you narrow down more the source or destination ranges or create a grouped network?
The problem isn’t the DSCP packet traffic (or the traffic from the grouped IP range rule). They’re all rules for Zoom-specific traffic.
What I saw happening was that when WAN1 lost its internet connectivity, ALL traffic (regardless of tagging,destination,source,etc.) stopped going through (both Zoom and non-Zoom traffic ).
The non-Zoom traffic should have continued on to WAN2 without issue, but it didn’t.
Hello David ( @heavydawson ),
For a seamless change between WANs during any VoIP, RoIP or Video call, you need to use the Peplink SpeedFusion technology paired with another appliance, such as the Peplink FusionHub, alternative you could use the Peplink SpeedFusion Cloud if you do not want to spin up your own FusionHub.
Happy to Help,
Marcus
Just so I’m clear, at no point was I expecting to (or had configured the Balance Two) to fail-over.
The scenario was:
All Zoom traffic goes to WAN1
All non-Zoom traffic goes to WAN2
In the event of either WAN no longer have internet access, I would expect traffic destined for the remaining (working) WAN to continue outbound without issue. This is the issue. The failure of one WAN appeared to prevent other traffic outbound on the remaining (working WAN).
I was OK with the Zoom traffic no longer working because of the WAN1 failure. I had no expectation that it would be failed over to WAN2
Having “Fall-through to Next Rule” on Enforced, as @WillJones states is available, would be awesome! I don’t find it on my Surf Soho or Balance One. Is this something available on other Peplinks, but not all?
I and others have never been able to get Outbound Priority rules to work properly with dual wans on the Surf Soho. Configuring Outbound Policy
As best as I can, this is related to the Priority list on the Surf Soho Dashboard where you can put only one WAN in Priority 1 as opposed to the Balance One where I don’t even know how to set up anything other than Priority 1 (can you?). Apparently the Priority rule only works on currently active, non-failed Priority grouping of WAN’s and VPN’s, which seems to be a surprise to me and many others who just try to configure Priority to work as we think it (should) work. Is this accurate?
Enforced with Fall-through would act as people expect.
Priority would be basically be what you are talking about. Enforced is enforced.
I wish Peplink would allow multiple WANs in priority 1 on the Surf Soho. Either the hardware can’t keep up with that or they want to upsell. Either way, unless they change their mind, Surf Soho would not be a good option if you need multiple WANs in priority 1. So its a moot point about writing outbound rules in most cases as the device is designed primarily to just allow failover to the next priority.
I’ve always looked at Peplink as having a logical and intuitive interface. The behavior of the Priority rule is not intuitive in my opinion. Even Peplink personnel are confused about it (no names, but a Peplink team member responded in the link I provided above to Configuring Outbound Policy as the answer to making dual wan configuration work on the Surf Soho, later corrected by another Peplink Team member).
Across all Peplink routers it would help if the Priority rule’s WAN list somehow indicated interactions with Dashboard priorities (maybe highlight WAN’s in the Priority rule list which are currently active?).
Given that a successor to the Surf Soho is expected out sometime this year, it would be good to improve the situation if the successor is also going to have Priority on the Dashboard. I suggested Enforced with Fall-through since it would be very simple to add, simple to understand, and provides a work around for people who don’t understand the current Priority rule’s interactions with the Dashboard Priority.
Where has it been said that the successor to the surf soho is expected out this year? Last I read there was simply chatter of taking a B20x without the cellular module.
I saw Cassy from the Peplink Marketing team comment in October “But we always listen to comments on new product development. If you have any idea on the next generation of Surf SOHO (although we don’t have time yet), please feel free to continue the discussion here.” Pepwave Surf SOHO router End of Life
I took the liberty of interpreting that to mean likely within a year. But Peplink hasn’t and doesn’t pre-announce.
I remember that. I would say that is quite an assumption. They have been talking about a new dome for two years now I think and they had said they were hoping to have prototypes over a year ago for testing. No updates since.
I have verified setting Independent is the key for putting WAN and USB on the Surf Soho at Priority 1!!! Now the Outbound priority rules work as expected. Many, many thanks to @Paul_Mossip.
For the record, the order of interfaces within Priority 1 define the order of failover (verified).
