Download Globalprotect
Susanne Sima
I'm trying to setup globalprotect where once a user successfully logs in, they pull an IP from our dedicated, internal DHCP server with all the DHCP options. So essentially, setup Palo Alto for a DHCP relay for the GlobalProtect clients. I was trying to do this, but the Tunnel Interface I'm using for the GlobalProtect network doesn't have an IP and doesn't show up when trying to configure a DHCP relay. Is there anyway to do this? Thank you.
If that's the case, is there anyway to provide proxy information for clients who do connect? That's my main reason in trying to create a relay for GlobalProtect clients. We have DHCP option 252 in our scope and have that pushing to clients with AnyConnect and was hoping to do the same with GlobalProtect. Is there anyway to push a configs or dynamically assign proxy settings to GlobalProtect clients?
Were you able to integrate this with AD DHCP (In your Lab) or is Reaper Right, that this has not been fixed yet, because of FR 2924 and FR 4703 not being implemented? I do not see 4703 in the Feature Request now. Only 2924.
I recently started a new job and have been thrown right into the fire. Users are complaining about very slow connections from globalprotect. They get speed tests between 3mbps - 20mbps. Internet speed from ISP is 500Mbps. When I attempt from a speed test site, I get a little over 100Mbps off the network but around 20Mbps when I'm on GlobalProtect. This is not split tunnel. Globalprotect connections are IPSec VPN
I don't want to jump to conclusions but I believe the issue is inadequate hardware. Firewall is a PA-3050. When I check the specs, I see max IPsec throughput is 500Mbps. There are over 100 users connecting to globalprotect during peak times. Assuming my understanding is correct, those 100 users are going to be sharing the 500 Mbps throughput? Plus the profiles attached to the security policy rules (av, threat, url, decryption) add some overhead, I'm not entirely sure how much that would impact though. The firewall also has some site-to-site VPNs too. Would Globalprotect share the 500Mbps throughput with those Site-to-Site VPNs too, or is that 500Mbps per tunnel interface?
In this case, version does not appear to be relevant. Before I joined the previous engineer upgraded firewall and gp version to 9.0.11 and 5.1.7. Apparently, issue has been going on since 8.1 days from what I gather
For the guys that have replied, I'm curious what kind of performance you see on your GlobalProtect sessions? I think it might be helpful to set a baseline when talking about GlobalProtect performance. I've read tons of these posts on the forums, but rarely see anyone discuss what we should expect.
In my testing I can never average more than 50-70 mbps GlobalProtect SSL VPN connection (dedicated 3020 firewall with just me, dedicated 1 Gbps internet link on both sides for just me, 30ms latency, no inspection or app-id, no QoS, iperf3). I can open a second SSL VPN connection from a different computer and simultaneously get another 50-70 mbps without impacting the first session. I don't see a significant CPU load on the firewall at either point. I can do testing outside GlobalProtect (static NAT) and pretty consistently get 940 mbps. My assumption is that this is some internal tuning limitations that we can't see.
On my production system, I will have stretches where I can get 50-70 mbps, but this will frequently drop down to the 2-10 mbps range (for minutes at a time). Like the OP, the overall bandwidth usage doesn't explain all of the issues). Certainly, I can see slowness when there are peaks in bandwidth usage, but I also see slowness that doesn't correspond to any bandwidth usage. My assumption is that it is due to firewall load (although the firewall doesn't show 100% CPU, I assume the GP process is somehow throttled and that the performance slowness is due to other stream processing inspections and app-id that is happening).
I can run a simultaneous test (iperf3) where I test using a static NAT (non-GP) at 200 mbps, along side 2 GP connections. The static NAT connection will remain consistent, while the two GP connections will suffer performance hits around the same time.
I should note that I've read the usual comments about SSL VPN and performance (due to a TCP session encapsulated in another TCP session). I can see this demonstrated when I do testing at my DR site and I run into (what I assume) are throttling issues when the interior and exterior TCP sessions have conflicting sliding windows. For example, the session will be cooking along at 70mbps for 30 seconds, then drop to zero and then ramp back up to 70 mbps. I'm planning to do some testing on my test site with GlobalProtect in IPSEC mode to see if this goes away or if my overall bandwidth is improved.
Just a follow up on my post. We enabled IPSEC on GlobalProtect and all our slowness issues were resolved (we get nearly full bandwidth). I still find it hard to believe that SSL VPN performance is so terrible and that Palo Alto is happy with it, but we've moved on to just requiring IPSEC.
I recently found about 30 of my 4,000+ users have crawling speeds (2Mbps) over Global Protect using IPsec when compared to AnyConnect over SSL (30Mbps). During troubleshooting we are certain their ISP is throttling or applying DPI to their IPsec tunnel. To work around their ISP issue, we added the ability for them to connect to Global Protect over SSL (a checkbox in the client settings). Now they are seeing the same speeds as AnyConnect. This may or may not be related to your problem, but something to try in case SSL works faster for them compared to IPsec.
I have already one portal setup on my laptop using GlobalProtect, but when when I try to follow the commands indicated here -3/globalprotect-app-user-guide/globalprotect-app-f...) I get the following error:
Piggy backing off of this earlier thread (LIVEcommunity - Force GlobalProtect Portal refresh of connected clients? - LIVEcommunity - 514881 (p...). It there a way whether by registry or whatever, to force the client to grab its new config. We are switching over from on-demand to always-on and want to have users connect without them having to interact. Is there a way to do this?
Why not just adjust this value down to 1 hour, then after a day or however long it take to get everyone connected up and received the new setting you can adjust the check-in interval back to whatever your standard is. Trying to force the client to check in through a registry/GPO change is probably going to be more effort than worth the result given you can just change the below setting.
This would only apply to people that connect to Globalprotect correct? The main issue we have is the people who just dont connect to GP at all or havent in months. We have some internal gateways spun up in non-tunnel mode for the purpose of user-id/hip and I would like to begin retrieving this information via globalprotect from all clients.
Ive tried editing registries under here Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\Settings. Specifically trying adding connect-method either pre-logon or userlogon and flipped the on-demand key to no but no combination so far has gotten GP to initiate a connection. And I have restarted after each of these changes.
Im able to replicate the scenario on my machine, I connect myself to an on-demand config, flip the portal configs around so Ill hit the an always-on config the next time I connect. So the issue Im having is getting clients to connect to where they get the always-on config. But yes we've tried changing various registry settings but even with connect method set to user-logon and on-demand set to no, the client isnt auto connecting.
If the endpoints are connected/managed from SCCM you can create a package to uninstall and reinstall the GP client coupled with a reboot. When the client reboots the OS will automatically try to connect to it's defined portal to get the app config. When it does this the machines will get the config updates you're wanting them to have.
What registry changes are you making at the moment exactly, and are you trying to get them to utilize a new portal or simply update the connection method on an existing portal without having them connect?
59fb9ae87f