6.2.1 issue routing to internal PepVPN subnet

Product Discussion Peplink Balance
1

Hello Peplink users!

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

Examples:

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

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

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

We were able to work around this issue with 5.4.9 by adding an Outgoing Policy enforcing connections to 192.168.0.0/23 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 192.168.0.0/23 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.

2

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.

3

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”

4

Hi,

  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.

5

Thanks TK Liew.

955×723 82.4 KB

6

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.

7

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.

8

Thanks TK Liew. The ISPs provide the addressing for the DHCP connections. Outbound Policy of source: any > destination:192.168.0.0/23 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.

9

Hi,

  1. Just to confirm your purpose is to allow WAN segment of remote office B (192.168.0.0/24), remote office C (192.168.1.0/24) and remote office D (192.168.0.0/24) to access HQ LAN segment (192.168.0.0/23) 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.

10

TK Liew:

I think what he need is to access ip 192.168.0.3 ( that is on HQ subnet 192.168.0.0/23 ) from Remote D subnet ( 192.168.14.0/24 ) for example 192.168.14.23.

Remote Peplink D get confussed because the ip 192.168.0.3 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 192.168.14.0/24 and the rest of the network knew that 192.168.14.0/24 was on remote D and 192.168.0.0/23 was on Lan of HQ. Only the remote D stayed as updating routes because it doesnt make sense that 192.168.0.0/24 was on two places ( on isp2 and on LAN of HQ).

On 612 think changes… The VPN was established, and if you declared 192.168.0.0/23 on HQ LAN and there were a lower subnet on a isp2 ( 192.168.0.0/23 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 192.168.0.3 was send to the lan of main HQ instead of the 192.168.0.3 that was on isp2 wan or change the 192.168.0.0/23 to 192.168.0.0/24 and 192.168.1.0/24 ( 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 192.168.0.0/23 because those are the normal ISP subnets) and you could no longer use advanced outbound policy to override the behavior to send traffic to 192.168.0.3 from remote D to WAN instead of 192.168.0.3 @ 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 192.168.0.3) you sould use advanced outbound policy to get to the modem gui page at 192.168.0.1 instead of the main peplink gui (or any other device) that have the ip 192.168.0.1 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.

AG

11

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 192.168.0.0/23 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 !

12

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

955×723 87 KB

13

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.

14

Thanks TK Liew. I’ll open a ticket.

15

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.

AG

16

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

17

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!