topic Acceptable packet loss over Global Protect VPN? in GlobalProtect Discussions

Acceptable packet loss over Global Protect VPN?

EdwardMarshall — Tue, 18 Jan 2022 09:31:46 GMT

Dear all,

I was just wondering if others suffer from packet loss over their GlobalProtect VPN connection which has any impact on the connection or applications? We use a financial package that has a fat app on the endpoint and connects back to an SQL db on campus. This app doesn't deal with packet loss very well and bombs out every now and then. We can replicate this onsite as well.

We have multiple other apps, that operate in a similar fashion and never have any issues, just seems to be this one. We have contacted the provider and they told us to just use terminal services and the VPN is the problem. I have done multiple ping tests from home and my packet loss is always < 1%. I have done the same test with the user and sometimes the loss is up to 1% pinging the financial server over the VPN connection.

Is this normal behaviour? I suppose some packet loss is expected, but what is an acceptable figure?

Thanks for any help or insights into this. I didn't want to open a ticket with support yet, as I'm not sure there is a problem here.

Edward

Re: Acceptable packet loss over Global Protect VPN?

EdwardMarshall — Tue, 18 Jan 2022 09:41:58 GMT

Sorry I realised I didn't supply any technical context with this..
We're currently using GP version 5.2.9 agent using an IPSec tunnel directly back to a single gateway
PA-850's in HA running 10.0.8-h4

Re: Acceptable packet loss over Global Protect VPN?

Stephen_Suley — Thu, 29 May 2025 16:35:48 GMT

Sorry for the late reply, in 2025. I'm looking for some information on expected packet loss for global protect clients to servers reaching Prisma via a service connection and I found your post.

Have you tried adjusting the MTU on your clients desktops? I've seen exactly this when an app over VPN the payload overflows when doing certain activities inside the app like run a big report etc... try adjusting your TCP MTU down to 1380 on a couple of your affected desktops and test again.