We’ve been using Peplink Balances to connect multiple sites in a hub and spoke configuration and for the most part it works great but we have some issues that I’m hoping someone can provide a suggestion for resolving.
Most of our sites have an MPLS circuit that we do not inculde in the PEPVPN tunnel. The reason we do this is because real time traffic like RDP and VoIP seem to have issues when sent through the tunnel even though we have QOS enabled on the Balance routers. Therefore, we’ve been using outbound policies to route the critical traffic over the MPLS network where we can use the providers QOS. This works for us until there is outage on one of the MPLS circuits. We had an issue today where the MPLS circuit at the datacenter bounced which dropped our user’s RDP sessions. The outbound policy rules we use are set for priority and have a the secondary set to the PEPVPN tunnel but this doesn’t work since the Balance doesn’t monitor a WAN link if it’s not included in the tunnel so the traffic doesn’t fail over to the next WAN. We would ideally like to figure out a way to not drop those real time sessions.
In the past I have suggested that Peplink add the ability to create outbound policies within the Peplink tunnel but I don’t really see that being implemented any time soon. Does anyone else have a suggestion for resolving this problem?
There’s an expert mode available for use, depending on the models that you use (I think this is not included atm for single-WAN MAX routers).
Do try this and see if it helps.
We’re already using expert mode. The only additional functionality that we get from expoert mode is the ability to prioritize rules above the PEPVPN routes. I need to be able to failover traffic from a WAN that’s not included in the PEPVPN (but being routed to the same subnet that the PEPVPN traffic is being routed to) to the PEPVPN. This way we can keep our critical traffic on the MPLS network where the QOS rules work the majority of the time and failover to the PEPVPN if/when the MPLS network goes down.
We used to have Fatpipe routers that allowed us to do this. The Fatpipe devices worked similar to Peplink but they would allow you to include an MPLS WAN inside the load balanced WAN group. When doing this we were able to disable encryption and encapsulation for traffic going over that WAN but leave the other WAN links encrypted. Fatpipe also allowed us to write inbound/outbound rules for traffic inside the tunnel, for example we could have a rule to to always send RDP traffic over the MPLS network unless it’s unavailable then it would seamlessly fail over to one of the encrypted links. The Fatpipe devices were nice in that regard but they weren’t stable enough and were too expensive to keep.
Thanks for the detailed explanation.
I think my solution for this looks similar to one of the rule that you’ve mentioned in post#1, having a priority rule for RDP given to MPLS followed by PEPVPN tunnel. You mentioned that didn’t work because there’s no health check? Can elaborate on the no health check portion?
In addition, is the PEPVPN and MPLS both routing to the same remote subnet? One via Internet and another via a point to point connection?
A better explanation would be that one Peplink doesn’t know when it’s peer drops the MPLS WAN link. If the MPLS WAN link goes down on one end the other end doesn’t know to fail the traffic over to the VPN which would be the backup route.
To answer your second question, yes. The MPLS and PEPVPN both route to the same remote subnet. One is point to point and the other is over the tunnel.
Outbound policies in SpeedFusion will be considered for the next major firmware release.
For your case, i will advice the followings:
Include the MPLS to the SpeedFusion and verify the actual issue for the RDP and VoIP.
This will give us more info to suggest you the solution:
SpeedFusion performance issue
Latency issue
Packet Loss issue
WAN congested issue
You may consider to set the MPLS WAN health check for the remote sites using Center Site (HQ) MPLS WAN IP. With this setting, this should gather the WAN fail-over for remote sites.
The only disadvantage for this will be the WAN fail-over to SpeedFusion for the Center Site (HQ). Again, this should be under control by manually fail-over the RDP & VoIP to SpeedFusion. Seem this is a temporary work around, thus it should be sufficient for you to control the fail-over.
