Has anyone experienced an issue where accessing file shares from a Windows 2008 R2 is really slow, often showing the hour glass taking up several minutes or cancel and retry opening file shares multiple times again before it opens up, after establishng a VPN session using Global Protect VPN client v4.1.9-7 (same issue also happened with GP client v4.1.8)
Note that the user is able to ping internal DNS server - or any other internal servers - by NetBios, FQDN, or IP just fine.
I've already setup the Application Override for SMB traffic from the VPN zone to the server, and even check the box "Disable Server Inspection Response" from the VPN secuirty policy. All seems to work fine for me, and I am able to access the file shares just fine without delay after GP is connected. However, I've a number of users who simple keep getting the hours glass when click on the file shares from the shortcut on their computer desktop.
From those users who has experienced the slowness issue, I notice that their home network or hot spots is 192.168.1.xxx, while my home network is 172.25.x.x
I've tested disabling the "direct access to local network" in the GP gateway, and the user who's on home network of 192.168.1.xxx could access the file shares just fine, but that would kill their internet, since I've split-tunnel enabled already.
Re-route their home internet traffic through VPN tunnel is not a possible option at this time.
Windows 7-64bit, Windows 10-64-bit
Greatly appreciated if anyone can help.
It kind of sounds like the client is attempting to find the requested resource on the local network prior to attempting to find it within your corporate network through the GP tunnel. If you can't enable a full tunnel you won't be left with many options to address this outside of one of you donig a re-scheme of your network to avoid the overlap.
@BPry Thanks for taking the time trying to help me out.
I know the issue is with Palo Alto, since I also use Cisco AnyConnect client to connec to Cisco ASA that resides in the same datacenter and network, and all staff were happy to use the ASA for VPN without any delay at all. Unfortunately, the my ASA has reached its end-of-life.
Re-IP my work networks is not a possible option. It will involve a lot of work and some headaches along the way....
Have a non-IT user to change their home network IP scheme ....no, I really do not want to support their home network ...
I'll be looking for a replacement Cisco VPN solution
Can you specify if you are running into OPs issue where your end users have overlapping addressing, or whether you simply are experiancing slow SMB access across GlobalProtect?
It is slow performance over GP VPN, but seems very specific to smb traffic. Other traffic is fine.
Overlapping subnets is not an issue in this case - the local network is different to the server subnet where the smb traffic is delivered from.
It is consistently slow over both wired and wireless networks (as the underlying internet), but, interestingly, 4G / cellular data does not have the same issue.
I don't know how to explain that, as the wired and wireless networks we have tested with have no apparent commonality, they are all completely separate.
No, I've not yet found the solution to this issue, even after I upgraded my fileshare server from 2008R2 to 2016.
My PAN OS is v8.0.12 and I'll upgrade it to the latest v8.1.8 (as of now) soon and see if it will fix the issue.
Did the SMB slowness issue just happen to you recently or SMB has been working fine before? PAN OS version?
I will post back to let you know.
Do you have split-tunnel enabled or are you tunneling all traffic?
If you are running split-tunnel a possible answer to the different pattern would be if it needs to check the local-network for the host or not. Wireless clients are assigned a public address and don't have a local network to check, while the wired and wireless clients would look at the local-network first depending on your GlobalProtect Configuration.
No, it is a full tunnel. I did test with split tunnel, and creating host routes in the tunnel to the affected servers (this should ensure it checks that before the local network) but the result is the same.
Note: even if this were the issue, the local network on the wired/wireless networks is not the same as the server network so it should not check these first.
That's certaintly odd and something that I would raise a ticket with TAC about so they can look at your log files and your firewall configuration to see if they can determine why it might be different between the three subset of users. The most likely culpriate I can think of off hand, outside of a GP bug, would be the following:
1) Differences in matching security policies.
2) Decryption Policies:
3) Different agent settings getting applied based on source location, and therefore the client behaves differently?
Of course all possible scenarios I can think of that would logically cause a performance difference between users would depend on the users getting different agent configurations when they connect to GP or hitting differnet policies. If everyone is falling under the same policies and they aren't hitting different policies then I would really open a TAC case so they can review the logs and hopefully explain the difference in performance.
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!