- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-10-2019 10:24 AM - edited 04-10-2019 10:26 AM
04-10-2019 11:08 AM
Which model of firewall are you using?
Do you have threat profiles enabled for that traffic?
Each firewall model has a throughput limit based on the horsepower of the firewall. If you run traffic through the threat stack, it slows it down more. For example, I had a PA-500 and the max throughput is rated at 100mbps for traffic running through the threat stack. That equates to about 10/MB a second. Also, you have overhead from the IPSec encryption, that will slow down most traffic as well.
It is really the price you pay for security. Running traffic through the VPN and firewall means that additional overhead gets added on the traffic. Here are some ideas if you want:
- enable some routes in GP to exclude traffic to certain sites from the VPN
- If you have a GP portal license, you can turn on "exclude video" sites and it won't slow down video.
- create policies to disable the threat stack for certain type of traffic
04-10-2019 11:57 AM - edited 04-10-2019 11:59 AM
04-10-2019 12:13 PM
I understand. The specs for your firewall are high enough. I was just relating my experience where traffic outside of the GP VPN was fast, but traffic over the VPN is slow. That seems to be a universal condition introduced by the overhead of the VPN encryption. That is what I meant by price of security; VPN traffic won't be as fast as regular firewall traffic in my experience. Maybe there is some setting that makes it faster, but I'd love to know that as well. So far across two different PA firewalls, VPN traffic is slower.
04-10-2019 12:17 PM
04-10-2019 12:25 PM - edited 04-10-2019 12:42 PM
So as my recent efforts have lead me down this path, this is a very difficult question to answer.
When I first deployed GP using SSL only type tunnel on my 5220 (With decryption) I noticed a significant disparity in my speedtest results. At home without GP I would get between 90-105Mbps. With GP SSL type VPN tunnel I would get between 10-25Mbps. I opened a few tickets with TAC and got various answers and "fixes."
The best fix I've since deployed is converting the tunnel type to allow IPSec VPN for clients. This setting got me to around 50-65Mbps on a speedtest.
In one of my tickets with TAC they modified the tunnel I use for VPN to a lower amount to account for the encryption overhead (something I hadn't done.) There were varied settings here going down to 1424 down to as low as 1350 which is where I'm currently at. This was done to help prevent fragmentation of the "transfer stream." When this particular change was made I didn't really notice a significant change in throughput capacity.
In one of my tickets an engineer made a great observation, speed test sites aren't really a good measure of "throughput" or capacity while on VPN. They have their own unique setup that doesn't necessarily jive well for a VPN client.
Your best bet is to use a site that tests as if you're transferring a file. So in my case I feel getting 50-65Mbps via VPN w/o split-tunneling is more than enough.
Here is a better site to use: https://www.thinkbroadband.com/download
04-10-2019 12:32 PM
If you're trying to do this on a PA-850 and expecting high throughput I wouldn't. There are A LOT of factors that go into a devices performance specs.
I'm assuming your box is doing more than just supporting this single user GP connection. If your client is getting 48Mbps (6MB) of total potential capacity of 500Mbps, what other traffic is the box doing?
04-10-2019 01:03 PM - edited 04-10-2019 01:04 PM
04-10-2019 02:59 PM
The testing you are doing is flawed, at least when compared with a full traffic test. The reason is based on the number of sessions and how they are handled within the dataplane of the firewall.
If you're using a single download from your browser, you are only using a single TCP connection to actually get the content. You'll have multiple connections when browsing the site, but that one object being downloaded is limited by many factors.
If you had 50 PCs downloading 50 different objects from different servers, then you'll have a much more accurate test. Sessions can be distributed across dataplanes and cores, for example.
04-10-2019 03:06 PM
04-10-2019 03:09 PM
04-10-2019 03:27 PM
In all three scenarios, you're still using a single download. There are bottlenecks that can be associated with a single session (and even more when it comes to IPSec). Things like encapsulation/decapsulation and how it is split across multiple cores, and a whole host of things.
The datasheet numbers are for scale, not for individual downloads from a single client.
I don't want to come across as harsh, I just can't think of a better way to say it. A single download is VASTLY different than real clients connecting and doing regular work.
If you insist on using this type of flawed testing, at the very least try doing several downloads at the same time from different sites on that test client at site B. At least then you'll be using multiple sessions to fill the tunnel better.
04-10-2019 03:52 PM
01-27-2020 06:17 AM
Hello @nanukanu I hope you did find a solution for your issue
I'm facing the same issue using PA-200 but the Upload is quite good but the download traffic is slowing down (from 30 Mbps to 2Mbps).
SpeedTest Without Firewall 30 Mbps
SpeedTest with Firewall PA-200 2Mbps
03-04-2020 07:04 AM
Hi @Adam42 ,
I am facing a very similar issue as you are.
Please could you tell which version of the firewall and the global protect you are using. I am suspecting of some version bug and I would like to know if you the version you are using is the same I am.
Thanks
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!