Smart routing of IP traffic within PepVPN & SpeedFusion locally at remote sites

Hello Peplink Engineering,

We have been running some remote sites using the PepVPN/Speedfusion as configured through InControl2. These VPNs are tunneling several VLANs back to the central Balance 580. In our test with just a VoIP handset connected, we are seeing daily data usage of 2GB to 3GB (about 100MB/Hour). It has got us thinking as to how this traffic can be reduced, at up to 3GB/Day on cellular data holding up a VoIP Service, that gets expensive really fast.

This image above shows the past two weeks for one of the remote sites running only a single ATA (VoIP Analogue Telephone Adaptor) currently with the two peeks being when we were doing some remote access into the VoIP ATA at site.
We will take this unusual overhead issue offline with Peplink Support

##Thoughts on PepVPN Improvement opportunities
Separate to the overheads we are currently observing, one of the major improvements we believe Peplink could develop is to locally route the traffic between VLANs instead of back at the main balance router, saving large amounts of IP traffic.

This is an example what we have made up for the point of discussion (not a real network, yet)

  • Network Example
    VLAN 1 (Untagged) 10.00.x.x/16 (not used)
    VLAN 11 10.11.x.x/16, Access to VLAN none (Office PC & Printers)
    VLAN 22 10.22.x.x/16, Access to VLAN 33 (Security work stations)
    VLAN 33 10.33.x.x/16, Access to VLAN none (Security alarms and cameras)
    VLAN 44 10.44.x.x/16, Access to VLAN none (ATMs)
    VLAN 55 10.55.x.x/16, Access to VLAN none (Fleet Vehicles)
    VLAN 66 10.55.x.x/16, Access to VLAN none (VoIP systems)

  • Routers Types
    2 x Main Company HQ Routers (as hot fail over) - Balance 710 on Multi Fibre (good wholesale data costs / fast connections)
    20 x Remote Sites Type A - Router Balance ONE on ADSL2 (cheap ISP data / slow 12/1 connection)
    10 x Remote Sites Type B - Router MAX BR1 on LTE (expensive cellular data / fast 40/40 connection)

Everything at the Main Company Site is connected directly to the Balance 710 LAN Ports via Gigabit switches, the Balance 710 also manages the routes efficiently on the HQ physical network between the VLANs.

On the Remote Sites (Types A & B), everything currently has to pass back to the main company site before it can be routed to the correct VLANs.
At Remote Sites (Type A & B), there are a lot of devices on the differing VLANs that need to converse with each other, sometimes these are large files.

So imagine that a 1GB size file at Remote Site Type A needs to go from VLAN 33 to VLAN 22 and both the target and source devices are physically at Remote Site A, currently the file has to upload at 1Mbps through the VPN to the Balance 710 at the main site and come back at that upload limited speed. Considering there is a local high speed gigabit switch, this ends up being a very slow transfer compared to if the VPN had locally re-routed VLAN the traffic,

So now imagine imagine that same 1GB size file at Remote Site Type B needs to go from VLAN 33 to VLAN 22 and both the target and source devices are physically at Remote Site B, currently the file has to upload at 40Mbps through the VPN to the Balance 710 at the main site and comes back a good speed, though we just used up 2GB worth of Cellular Data, considering that this Type B site also has a local high speed gigabit switch, this ends up being a very costly transfer compared to if the VPN had locally re-routed VLAN the traffic,

What I’m envisioning is that with the help of InControl2 &/or the Balance Router these remote sites routers can build smarter local routing tables with the VLANs, routing & firewall rules of the Balance 710 applied saving VPN traffic.

Benefits (that become marketing and selling points for Peplink)

  • Better throughput for the traffic than needs to be on the VPN with local traffic keep local
  • Reduced data costs for sites dependant on costly data connections
  • Local Routing tables with VLANs staying operational if VPN link is lost
  • Business wide network management from single cloud platform (we understand the big C with M product are already doing this)

Possible Example to go with above
Local Security guards need to access the local security cameras at site (cold be a Type A or Type B site), these are on a VLAN separate to the local workstations (PCs) and printers, the guards may also have access a local GUI for some of there work. The machines the guards use are on VLAN isolating the staff from the the security. At head office, there is a central security team for supporting the regional guards on the same VLANs.

Maybe there is a way already within the Peplink ecosystem to do this, though I’m scratching my head to work it out.
Appreciate your assistance,
Marcus :slight_smile:

My interest is peaked as well. I completely see your point and am surprised to hear about the inefficiencies of extending VLans across geographic spaces. I would also think that it should work as you describe.

1 Like

Hello @jmjones,
It is possible with the initial issue that there is something we have missed in the building of the WAN network that is causing the overhead for that WAN Network, it is not normal from our experience with the PepVPN to have such high overheads. It was just put at the start to give some insight to our thoughts and why we have looked deeper into what else can make the PepVPN even better.

I do believe that there is always room for improvement and it is those of us in the field that have a responsibility to share this valuable experience with our manufactures especially when they are genuinely engaging and interested to hearing back and take on board those suggestions, comments and experience (look at this forum as an example).

The initially issue above I’ll take up offline with Peplink to get resolved.
I look forward to seeing what they can do on the feature request though with the VLANs.
Happy to Help,
Marcus :slight_smile:

Hi Marcus,

In the above scenario it would be recommended to use layer 3 networks at the remote site so that traffic would stay on the remote site when routing between the vlans, this would negate the need for the traffic to pass back to the layer 3 device at the main site to be routed.

You could still pass the vlans that aren’t going to need intervlan routing back to the remote site with L2 over speedfusion.


1 Like