Have you tested with something other than the usual HTTP/S based speed tests?
I would be curious to see what something that is generating a large number of connections / sessions results in, for example a BitTorrent client downloading a dozen or so well seeded Linux ISO files concurrently as whilst Speedtest.net for example does open multiple connections it is still a relatively small number.
Running iPerf to something hosted directly in the same network as your FH WAN (or directly upstream) would also be a good idea, in otherwords a test that makes traffic that must pass through the FusionHub, as when you are testing with the PepVPN and WAN Analysis you are just benchmarking the end to end capacity of the links between your TST and the FH, not actually routing packets via it.
Running that kind of test for a good 10 minutes or so and grab the more detailed graphs for the PepVPN showing the relative WAN to WAN stats that show errors, packet loss, out of order packets, latency etc.
The reason I am suggesting this is as whilst you clearly are getting lower throughput reported on from a device behind your TST vs the built in PepVPN test your method is somewhat flawed here as you are not comparing like for like.
I’m going to assume for now that is a device wired direcly to the LAN of your TST, but as the PepVPN test is showing quite wide vairation in the reported throughput with intervals ranging from ~40Mbps to ~150Mbps at a maxiumum which to me suggets that there is something to look into there.
Yes, direct wired over 10G connection that performs as expected (I realize that the router is limited to 1G. Just mentioning the downstream capability of my LAN).
I don’t really know how to run the tests that you speak of. I do, based on your comments, question the value of the tests available inside the router interface if what you say is true.
What I want, and I don’t think it’s unreasonable, is to see the bandwidth at the desktop that is reported by the Peplink tools. So how does a layman diagnose this? Additionally, my speeds at the desktop are significantly faster when I turn the tunnel/s off - both in Speedtest and in usage.
Worst case, if the router sees that the VPN traffic is slower than a single WAN connection, it should report it and use a non-bonded approach - but this would go against Peplinks marketing. I’m not happy.
I have many outbound policies to enable exceptions for my streaming devices, most based on MAC addresses, and finicky websites, based on domain. They are all set to Fall-through to the Fusionhub OP. In the FH OP, I removed Priority and set Fallthrough, and have one policy following it that uses the best WAN based on Fastest Response. This is so I can still use the fastest connection if the tunnel/s are down, rather than use the link that’s next in a Priority list in a VPN OP. I am not using Expert Mode, with exceptions ‘above the line’ since this has been shown not to work for domain-based exceptions - it does work for the MAC-based exceptions however.
The client that I’m testing on IS NOT listed in the exceptions policies above the VPN policy - it actually is listed but turned off - it is for testing and my previous test screenshots show that it is not being applied when OFF.
Please tell me why you don’t see that the tunnel is being used when you see “Choopa” in Speedtest. If I knew why you see this as a concern, I could respond more directly. Here is a list of the policies if this helps. Thank you!
I have been using peplinks for many years and I’m trying to share my knowledge of troubleshooting with you.
I have no idea what “Choopa” is in the speed test as it doesn’t mean anything to me.
Based on the outbound policies, please move the policy “All Traffic via fusionhub” above the Grey bar “Pepvpn/ospf etc.”
-Change the policy from priority to enforced and to the pepvpn tunnel you which to use.
-Change the source ip to the exact source ip of the device that you are running the speed test on.
-After you have made these changes REBOOT the peplink to clear all the sessions so we can start fresh.
-Remove not just disable all rules that have a domain name in them as there is an error that makes the speed half of what it should be.
I don’t know if your model is afffected.
-Post a new screenshot of the outbound policies.
I didn’t write the peplink algorithms and I’m just thinking that it’s picking a policy that we didn’t expect.
So whilst unlikely I would actualy bypass your switches and LAN etc, and plug straight into the TST.
If your test machine has a 10G NIC in it and is connecting at 10G you potentially have some interseting possibility for buffers in the switches to get invovled here although typically this is mroe of a problem when a large traffic flow is coming from a high speed link into a lower speed like, but consider this:
You have a very high speed connection (10G PC), connected to a moderate speed connection (1G between your switch and TST), connected to a low speed and variable half-duplex connection (The cell networks).
It does potentially create some interesting behaviour that is rather hard to diagnose, but relatively simple to bypass and rule out entirely.
The tools provided are valid for the tests they are performing, in that you are able to see that traffic between your TST and FusionHub should be good.
The two tests do differ in that the traffic via WAN Analysis is outside the VPN and may be classified differently to traffic sent when the VPN is in use, the PepVPN uses standard ports that many systems used by big carriers to identify traffic on their networks will classify as “VPN” and may get treated differently to traffic sent directly.
This is expected, the VPN and bonding process has a certain level of overhead and there are wide number of factors that can influence this such as the variance between the different WAN links, congestion within one carriers network vs another, a high level of retries or errors on one link can also severly impact the bonding - the algoritihms can only deal with so much before ultimately they have to slow down.
This is why I did suggest running the test with the traffic sent via the VPN but with one WAN only, unless I missed it I think all your testing with the SF tunnels in place has been with both WANs enabled?
If you were testing with only a single WAN enabled do you see performance that is closer to what you would see with 1 WAN but no VPN, or do you see the traffic severly limited just by being inside the VPN, again here we are removing the packet bonding process and testing just whether the traffic being in the VPN is actually a problem (again refer to my expereince above).
I believe there is an open bug at the moment related to using domains to steer traffic and how it is impacting performance, for the purposes of testing I would simplify your setup to the extent that all traffic goes via the VPN and just connect a single device. If it is a pain to remove or disable all those rules perhaps again for the purpose of testing in a clean fashion backup your config, wipe the device and put the bare minimum config in required to enable your SF connectivity and plug a device right into the TST and test.
I know this may be repeating what you’ve already done but using a simple test setup and adding the complexity back in one piece at a time would help to narrow down the scope of what may be causing the behaviour you are seeing.
OK. Thanks for your help.
“Choopa” is the name of the server assigned by Vultr when traffic is going through the VPN.
I need to capture all of the MAC addresses and domains from my OPs before removing them. Unfortunately, the interface truncates the MAC addresses so I’ll have to go into each OP and record them. I’ll post when I’ve done this.
May be handy to try the above 1Gb test file from Vultr from the same location as your FusionHub is hosted, obviously download only but it lets you test at least from within the same place as your hub is hosted rather than a random speedtest server on the public internet.
I’m going to connect my router directly to my test PC. This will tell if there’s something going on inside my LAN - very robust configurations. I never experienced these things up till now but who knows?