6.2.1 issue routing to internal PepVPN subnet

Hello Peplink users!

One of our main office subnets (or supernets) is
Remote offices with one or more WANs with DHCP assigned addresses on either or cannot route to parts of our internal network.


  1. Ping from a remote office B210rev3 with 6.2.1 and a WAN DHCP connection at to through the PepVPN results in “ cannot be reached using the selected connection.”. Ping from the same B210 through the PepVPN can receive replies from

  2. Ping from another remote office B210rev3 with 6.2.1 and a WAN DHCP connection at to through the PepVPN can receive replies from Ping from the same B210 through the PepVPN to results in “ cannot be reached using the selected connection.”

  3. Pings from other offices with no DHCP WANs can receive replies from all addresses.

We were able to work around this issue with 5.4.9 by adding an Outgoing Policy enforcing connections to to use the Speedfusion connection. A similar policy in 6.2.1 doesn’t correct the routing problem. I’ve also removed all remote Peplink firewall rules and re-created the Outgoing Policies. OSPF shows as PepVPN.

I would greatly appreciate any suggestions on how to get this issue resolved. There are some really nice features in 6.2.1. For now I’ve rebooted each office with DHCP WANs to 5.4.9 for connectivity. Thanks for any help.

Sorry. This probably isn’t clear enough. The only issue is that the Outgoing Policy doesn’t seem to work in 6.2.1. An Outgoing Policy enforcing a destination network through a specific connection worked correctly in 5.4.9. The same policy in 6.2.1 doesn’t seem to have any effect. - Thanks.

I received a recommendation to turn on expert mode in Outgoing Policy. (Thank you!) I moved the policy above PepVPN Routes. Ping still results in “… cannot be reached using the selected connection”. Trace route results in “… cannot be reached”


  1. Can you provide graphical network diagram for above connectivity?

  2. Are you doing ping test via System > Ping in remote Balance router?

  3. Please avoid same subnet if you need both network to communicate.

Thanks TK Liew.

TK Liew - Yes. Ping test from System>Ping. Remotes B, C and D have dhcp assigned addresses in /24 networks that overlap ranges in one /23 HQ network. Outbound Policy in 5.4.9 corrected the vpn routing. Outbound Policy in 6.2.1 does not. Thanks.

Hi GCtrpt,

Thanks for the info. Please take note again, please avoid to use same network segment between HQ and Remote office since communication is needed. Please change it accordingly and try again. Do let me know if you still facing same problem.

Thanks TK Liew. The ISPs provide the addressing for the DHCP connections. Outbound Policy of source: any > destination: enforce SpeedFusion. This policy worked on each of the remote offices with 5.4.9. That policy does not work with 6.2.1. Is it that Outbound Policy in 6.2.1 can no longer apply this rule on PepVPN traffic ? - Thanks for your help.


  1. Just to confirm your purpose is to allow WAN segment of remote office B (, remote office C ( and remote office D ( to access HQ LAN segment ( and vice versa?

  2. If my assumption in item 1 is correct, may I know any Outbound Policy applied on HQ to access WAN segment of remote office B, C and D? If yes please share to me.

Thank you.

TK Liew:

I think what he need is to access ip ( that is on HQ subnet ) from Remote D subnet ( ) for example

Remote Peplink D get confussed because the ip is in two places. At this Wan interface from isp2 and on OSPF SF-VPN info from HQ Peplink.

When this happens, best scenario is that the remote Peplink D doesnt finish updating routes on both sides and the vpn reset itself ( that I think it was 549 version ) and never could finished.

Later on ( I think on 60x ) the vpn status on HQ moved to established and learned and the rest of the network knew that was on remote D and was on Lan of HQ. Only the remote D stayed as updating routes because it doesnt make sense that was on two places ( on isp2 and on LAN of HQ).

On 612 think changes… The VPN was established, and if you declared on HQ LAN and there were a lower subnet on a isp2 ( or lower) the remote D will send the traffic first to WAN with same or lower subnets and then to OSPF subnets.

You could overrule this behavior by using advanced outbound policy ( as described by GCtrp) so from Remote D point of view, any request to was send to the lan of main HQ instead of the that was on isp2 wan or change the to and ( same subnet or lower on LAN of main Balance).

What GCtrp is saying is that this behavior changed on 621 ( I could validate this, I havent upgraded that many devices and I avoid because those are the normal ISP subnets) and you could no longer use advanced outbound policy to override the behavior to send traffic to from remote D to WAN instead of @ LAN of main HQ.

What I think it should be is that OSPF subnets should always win over any WAN subnet and if you like to go to a WAN subnet ( like the you sould use advanced outbound policy to get to the modem gui page at instead of the main peplink gui (or any other device) that have the ip running on the LAN of main HQ.

If you have any further question about this issue feel free to send me a hangout request. This is a normal question that some tier 1 peplink eng ask me because is not easy to diagnose and it depend on what fw version are u running.


Thank you TK Liew and arturogerez.

That is exactly the issue arturogerez.

We only want routing between the remote office LANs and HQ LANs.

We’ll have trouble with moving hosts (including a SCO box with terminals) from the network. If 6.2.1 build 2992 outbound policy can’t get around the route conflict and there are no plans to allow this policy to work in future releases, we’d need to stay on 5.4.9 in those offices or we could get static addresses from those service providers. We really like the new features in 6.2.1 so we have that running in all other offices. The only other issues for us with 6.2.1 were H.323 phone registration and conflicting performance reports between B210s and B2500.

Thanks for looking through this issue !

Sorry. My mistake. Here’s a clearer graphical view. It may be clearer. Thanks.

Hi GCtrp,

Please open ticket for us to take closer look. Please provide serial number of Balance router for the affected sites and turn on Remote Assistance for Balance routers during you open ticket.

Thank you.

Thanks TK Liew. I’ll open a ticket.

An update.

I installed FW 6.2.2 and I found out that the issue that GCtrpt reported is now corrected.

Tks again Peplink for your support.


Thanks for the firmware Peplink. Thanks for the update Arturogerez. I’ll install this update over the weekend and report back. - GC

Thank you Peplink. I could not stop to work with 6.2.2, however, I can report that 6.3.1 corrects this issue on B2500, B210hw3, B380hw5, B310hw4 and B710hw2. It also seems to increase speedfusion throughput beyond reasonable expections. 50 Mb fiber DIA to 100Mb/20Mb cable gives us 47Mb/19Mb speedfusion connectivity. It also got around a Vendor_A 50Mb DIA/Vendor_B 50Mb DIA (peering?) issue that previously limited traffic in each direction to <2Mb. Traffic from Vendor_B to Vendor_A now 27Mb. Vendor_A to Vendor_B is still 1.7Mb, but we’re working with Vendor_B to allow more ingress to our ip/port. Thank you very much Peplink!