SpeedFusion limitations


#1

What’s the max throughput on a SpeedFusion VPN bond with the following configuration?:
256-bit AES encryption turned on.
2 x Peplink Balance 380 - 1 at each location.
4 x 100Mbit/sec WAN links from 2 different ISPs - (1 x 100Mbit/sec metro Ethernet + 1 x 100 Mbit/sec FIOS) at each location?
Drop in Mode configured for one WAN at each location.

We’re not getting anywhere near the performance limit of the 380 - i.e. 300 Mbit/sec. In fact, we get less than 100Mbit with SpeedFusion turned on.
With the SpeedFusion turned off, we get close to 100 Mbit/sec between the locations.

Am I missing something here?


#2

Just to clarify the setup. Each of the site will have 1 x 100Mbit/sec metro Ethernet + 1 x 100 Mbit/sec FIOS (total 200Mbps)?

What is the SpeedFusion throughput that you are getting?


#3

Yes, that’s the configuration.
Each WAN link has been independently tested with speedtest.com to perform at near wire speeds i.e. 95-103 Mbps through each Peplink at the endpoints.

Here’s the result of the synthetic test from SpeedFusion™ Throughput Test

TCP Upload
6.8750 MB / 1.00 sec = 57.5751 Mbps 0 retrans
7.4375 MB / 1.00 sec = 62.4460 Mbps 1 retrans
6.1875 MB / 1.00 sec = 51.8614 Mbps 0 retrans
8.0625 MB / 1.00 sec = 67.7063 Mbps 0 retrans
7.4375 MB / 1.01 sec = 62.0698 Mbps 0 retrans
7.2500 MB / 1.00 sec = 60.8818 Mbps 0 retrans
7.1250 MB / 1.00 sec = 59.7852 Mbps 0 retrans
7.4375 MB / 1.00 sec = 62.4836 Mbps 0 retrans
5.6250 MB / 1.00 sec = 47.1203 Mbps 0 retrans
7.3750 MB / 1.00 sec = 61.9921 Mbps 0 retrans

70.8750 MB / 10.04 sec = 59.2431 Mbps 75 %TX 32 %RX 1 retrans 40.42 msRTT
TEST DONE

TCP Download

1.0625 MB / 1.00 sec = 8.9026 Mbps 0 retrans
4.0000 MB / 1.00 sec = 33.5339 Mbps 15 retrans
2.5625 MB / 1.00 sec = 21.5044 Mbps 12 retrans
2.9375 MB / 1.00 sec = 24.6180 Mbps 0 retrans
2.3125 MB / 1.00 sec = 19.4114 Mbps 0 retrans
2.6250 MB / 1.00 sec = 21.9847 Mbps 1 retrans
2.9375 MB / 1.00 sec = 24.6486 Mbps 0 retrans
3.0625 MB / 1.00 sec = 25.7010 Mbps 0 retrans
3.2500 MB / 1.00 sec = 27.2508 Mbps 0 retrans
3.6250 MB / 1.00 sec = 30.4081 Mbps 0 retrans

28.9756 MB / 10.21 sec = 23.7988 Mbps 1 %TX 7 %RX 28 retrans 90.88 msRTT
TEST DONE


#4

The Balance 380 is rated for up to 60Mbps of SpeedFusion throughput, as indicated on the spec page of our website. If you turn off 256 AES encryption it will go higher of course.


#5

Wow, I can’t believe I missed that information.
Was that info. just added to the feature listing?

So, it seems that I’ll have to be running a pair of Balance 710s to get anywhere close to the performance I’m looking for.
That’s $5K down the drain, and another $10K to get 160mbps.
Even with the 710, I’m not sure that I’ll get anything like the performance I’m looking for.

Without the VPN encryption, on a SpeedFusion VPN Bond, are the packets sent in the clear?
Aren’t they then subject to man-in-the-middle type attacks?

I’d like make this work with the existing equipment.
Since I’m using drop-in mode in both locations, is there any impact of this mode on the SpeedFusion VPN Bond?
What’s the SpeedFusion VPN Bond throughput when 256 AES encryption is turned off?
My firewalls have IPSEC tunneling throughput of up 500mbps, is there any impact of tunneling inside the SpeedFusion VPN Bond?

Thanks.


#6

The info has been the same for at least two years, maybe you just assumed router throughput = SpeedFusion throughput?

If you just recently bought these directly from us we can arrange a trade-up to a higher model and you would just need to pay the difference, otherwise just contact your reseller.

With no encryption, the packets are sent in the clear but they could only sniff out half of the packets because the other half would be sent across the other WAN connection. They would need to sniff both lines at the same time and be able to re-assemble the packets back in their original order. Not impossible, but unlikely.

The drop-in mode has no effect on SpeedFusion performance.

SpeedFusion throughput with no 256 AES encryption on the Balance 380 is up to 120Mbps.

You can definitely run an IPSEC tunnel within the SpeedFusion tunnel.

Another thing we want to remember is that best performance is achieved when bonding connections of similar nature in terms of speed and latency.


#7

First, thanks for the reply.

I bought these units from a reseller.

WRT IPSEC tunnels/Drop In Mode etc interoperability with a SpeedFusion VPN Bond, I guess what I’m asking is that how can this work, since the endpoint of the tunnel is a single IP on one of the trunks that make up the SpeedFusion VPN Bond?

Example:
Device **A **behind a Balance 510 w/SpeedFusion VPN Bond of WAN trunks, each with IP addr **W **and **X **connecting to another Device **B **behind a remote Balance 510 w/SpeedFusion VPN Bond, each with IP addr **Y **and Z .

AFAIK, an IPSEC tunnel can only be established between say **W **and Y. What, if any advantage - does SpeedFusion offer in this case?
In my case, I also have another IPSEC tunnel established between **X **and **Z. **Again, any advantage of using SpeedFusion in this scenario?


#8

SpeedFusion throughput with no 256 AES encryption on the Balance 380 is up to 120Mbps.


#9

When using drop-in mode, usually the firewall sitting behind the Peplink will terminate the IPsec tunnels and the advantage is that the tunnel will not break if one of the WAN connections fail.


#10

So, to clarify - using my example above, a tunnel established between:
The primary WAN links in drop-in mode, i.e. Firewall **A **(IP address W[10.10.10.1]) and Firewall **B **(IP address Y[172.18.10.1]) will be re-established using IP address **X **[10.11.11.1]and IP address **Z **[172.11.11.1] (secondary, non drop-in mode NAT), if the primary WAN links with IP address W and Y fail . This is because the firewalls will think the WAN links are still up, as the packets are now getting routed over the secondary or tertiary WAN links on the Peplinks.
This would seem to work without Speedfusion - right?

Illustration:

Firewall A[10.10.10.1]<->Peplink A.WAN1<—IPSEC TUNNEL—>WAN1.Peplink B<->[172.18.10.1]Firewall B

Upon failure of either or both WAN1 links.
Firewall A[10.10.10.1]<->Peplink A.WAN2[10.11.11.1]<—IPSEC TUNNEL—>[172.11.11.1]WAN2.Peplink B<->[172.18.10.1]Firewall B


#11

SpeedFusion is definitely needed if you want to create the “Unbreakable” VPN. If using IPsec only, the tunnel would definitely break upon the failure of the individual WAN connection it is established with. You would then have downtime while the new IPsec tunnel gets established with the new IP address.

SpeedFusion uses all WAN links simultaneously to create one virtual tunnel, so there is no need to re-establish the VPN in the event of a single WAN failure. It simply will never break unless all WANs fail at the exact same time.

This is why SpeedFusion is so much better than IPsec, plus it is dead simple to configure. Customers can also enjoy increased throughput in the tunnel because of bandwidth bonding, which you would never see using IPsec alone.


#12

In drop-in mode, i.e. where there’s another Firewall inline, how can traffic be passed from a network behind the firewall to a remote network behind another firewall that’s also using drop-in mode?
Say I want to pass traffic from 192.168.0.0/24 to 192.168.1.0/24. using drop-in mode, I configure an IPSEC tunnel between the firewalls that these addresses sit behind.
There’s no routing necessary, the firewalls detect, encrypt and pass the traffic between them based on the source and destination addresses.

Are you saying that Speedfusion makes it unnecessary to create this IPSEC tunnel?
I found that I can’t pass traffic between the networks without the IPSEC tunnel between the firewalls.
Again, I’m specifically talking about drop-in mode.


#13

Here are the options for routing an IPsec VPN through the Peplinks:

  1. Send the IPsec VPN through a SpeedFusion VPN. This can use both WANs on each side simultaneously, and if a WAN link goes down - the IPsec VPN remains established because SpeedFusion is essentially an “unbreakable VPN”. You can disable encryption with SpeedFusion; however there is still the bonded VPN throughput rating of the router to consider.

  2. If SpeedFusion is not used, you can lock IPsec traffic down to the drop-in mode WAN under Network> Service Passthrough> IPsec NAT-T, and check “Route IPsec Site-to-Site VPN”. This does not allow for failover. If you want to include WAN2 for failover, service passthrough support for IPsec NAT-T must be disabled and UDP 500 needs to be forwarded to your firewall. An outbound policy rule using the priority algorithm will determine which WAN is the primary. With this method, if you lose WAN1 the IPsec VPN will go down and have to be re-established. Sessions will be lost so they will also have to be re-established.


#14

Using SpeedFusion, your firewall simply needs to have a Nat exclusion policy described below:

When Source = 192.168.0.0/24
And Destination = 192.168.1.0/24
Don’t NAT

The Balance needs a static route for the 192.168.0.0 network pointing to the firewall under: Network> LAN> Static Route Settings. Once that is done you will see the private IP addresses under Status> Client List.


#15

Thanks for the info.
I’ll give that configuration a try.

To clarify, the Balance needs only a single static route for 192.168.0.0 and not one for 192.168.1.0?
How does the Balance sitting in front of 192.168.0.0/24 know where 192.168.1.0/24 is? Or, is that done on the firewall?
And how does the Balance know how to send the packets from 192.168.0.0/24 to 192.168.1.0/24 and vice-versa.
Does it advertise the routes? I guess I’m asking how to make sure that these non-routable IPs are kept inside the SpeedFusion VPN.


#16

Each Balance needs a static route pointing to the firewall for its local network. The Balance will advertise the local network through SpeedFusion and know how to route to the private network on the other side.