IPSec Crypto / browsing issue?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

IPSec Crypto / browsing issue?

L3 Networker

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. 

4 REPLIES 4

L6 Presenter

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:

 

 

https://live.paloaltonetworks.com/t5/blogs/troubleshoot-performance-related-to-globalprotect/ba-p/31...

 

 

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:

 

https://live.paloaltonetworks.com/t5/globalprotect-articles/troubleshooting-globalprotect-mtu-issues...

 

 

As a final thing test with IPSEC as it is with better performance than SSL.

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

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

 

 

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.

  • 2578 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!