Okay, we used to have a Peplink Balance 200, but recently moved to a Peplink Balance 20 for greater throughput. We didn’t need the features of the 210, so we opted for the much cheaper Balance 20. (The 210 is about $1000 more than the 20.)

Struggled for a while to get remote extensions (phones located on the internet outside of the LAN) to connect to the server. On the Balance 200, it just pretty much worked once the appropriate ports were forwarded to the server IP on the LAN.

On the Peplink Balance 20 though, I was only able to get it to work after I set the default connection mode to be ‘Persistence’. Normally it comes with “Lowest Latency”. In our circumstance, the WAN address the call comes in on is not necessarily our lowest latency line.

To make the adjustment log into your Peplink Balance, then navigate to Outbound Policy. The ‘Default’ setting is the one right above ‘Add Rule’.

Peplink Balance 20 outbound policy

Click on ‘Default’ to open the settings and then use Persistence and “By Source”. Apparently “By Source is the most compatible setting and I had to use this rather than just “By Destination”

Revised for SIP connections

Prior to making the changes, we could call out to the remote extension but the remote extension could not successfully initiate an inbound connection. My guess is that the remote SIP extension pings the WAN and is directed to the asterisk server on the LAN, but then when the asterisk server attempts to open a RTP UDP session with the phone, it fails to do so because the outbound route it was attempting to use was not the same as the inbound route. WAN1 has a lower latency, but also less bandwidth whereas WAN2 has a higher latency, but also higher bandwidth. Our remote phone extension is currently connecting in via WAN2, and with the default settings on the Balance 20, the SIP UDP connection is being sent back out WAN1 instead of where the phone expect to pick it up on WAN2. (my guess as to what’s happening based on the fact we could call the phone, but the phone couldn’t call us.)

I suspect I can probably add a specific outbound policy rather than mess with the default. Probably better in the long run too as it would narrow the scope of the persistence to just the appropriate protocols. I’ll look into that soon and update if I can narrow the scope a bit on the outbound policy and still maintain the connection.