03-30-2021 01:47 PM - edited 03-30-2021 01:48 PM
Hi All,
I working on some firewalls and saw the GlobalProtect IPSec crypto profile but was using aes-128-cbc, I decided to change it to use aes-128-gcm, to take advantages of gcm benefits.
Since that change, I have a user who is experiencing issues. They can connect to GP and have no problems accessing internal resources but they are unable to browse or do anything internet related. The pages load extremely slow and more often than not, don’t complete loading. This is happening on multiple browsers. If I disable GP, browsing is fine.
Is it recommended to use aes-128-cbc for globalprotect? I’m running 9.0.12 and GP 5.1.6
i wouldn’t think it’s related to the change but can’t pinpoint the problem.
03-31-2021 02:57 AM - edited 03-31-2021 03:07 AM
Have you checked the data plane and managment plane CPU and memory or global counters during the issue? The new cipher maybe it too CPU intensive?
This is a nice article:
But you also may need to follow the bigger one:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClkBCAS
Also if the aes-128-cbc cipher makes the packet bigger maybe you also need to check the MTU for the VPN on the workstations and also their VPN logs:
As a final thing test with IPSEC as it is with better performance than SSL.
03-31-2021 07:45 AM
Thanks for the reply.
All connections are IPSec, not SSL. Memory/CPU are fine. The issue so far is only for 1 user.
As a test, I had them connect to a different firewall that still uses aes-128-cbc for globalprotect and they do not have the issue.
I'm still looking into possible MTU issue due to changing to aes-128-gcm. Could be related to this specific user's ISP
03-31-2021 01:40 PM
MTU seemed to be the issue. I changed MTU to 1380 on the client and that resolved the issue.
So now the question is why did this happen. Physical interface is MTU is default (1500). Tunnel interface MTU is default (1400)
When I run "show global-protect-gateway flow tunnel-id <tunnel>", it shows MTU as 1424 (for aes-128-gcm) and 1420 (aes-128-cbc). This makes sense since it's auto adjusted 80 for cbc, 76 for gcm.
So I'm assuming this slight difference in the adjustment (4 bytes), was causing a fragmentation issue somewhere in the path. I would have thought more users would have been impacted
03-31-2021 11:45 PM - edited 03-31-2021 11:46 PM
Nice that you solved this.
It depends on the ISP provider network, your network or the users network where the users connect and so on. This is why such issue is hard to catch and you have to look in the vpn logs of the affected workstation. If the issue is solved, please mark the discussion/qustion as complete.
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!
