03-14-2023 07:38 PM
Hi, I am having a problem where random global protect clients are connecting and are able to send traffic through the tunnel to the Data Center when traffic is initiated in the client workstation. However if we try to RDP or send any traffic to the connected VPN client initiated from the Data Center side, we are seeing in the capture that traffic is forwarded by the firewall but there is no reply from the global protect client PC. The only solution we have found so far to fix the broken clients is to change the preferred IPv4 in the windows registry so that the client gets a different VPN pool address then the problem is resolved. I would appreciate if somebody has had the problem and has figured out the root cause. So far support has not been able to provide me with a solution or root cause. I checked the firewall forwarding table and there are routes installed for the clients. The windows route table seems normal too. I am not sure why changing the IPv4 preferred address is resolving the problem
03-15-2023 08:38 AM
I dont have much experience with global protect and cleint VPNs on the Palo Alto. I have had similar problems with Anyconnect and an ASA.
For the users that you are having issues connecting to, what is the subnet of their local network? Does it overlap with one of the networks that should be tunneled through global protect? If there is an overlap, your server will know how to get to the user device, but the user device will then try to respond on the local network. When you change the prefered ip, the user device then sends traffic over the vpn. Once you do this, does the user device loose access to other devices on thier local network. In a command prompt on the user device you can run "route print" to show you what routes are on the computer and the gateway for each route.
I have seen this happen with users that connect directly to a comcast router. They get a 10.0.0.0/24 address. We used to use 10.0.0.0/16 for devices on our network. They would have issues getting to those first 254 addresses.
03-15-2023 08:52 AM
Thank you for replying. At the beginning I suspected that was the problem because we do use Class A of 10.0.0.0 for our Corporate network and we do have users from Comcast having the problem where their private addresses were 10.0.0.0/24 but then we also found the issue with people using a Class C of the 192.168 subnet. We also cannot get to the user from any subnet in the Class A regardless of being /24. The only thing that fixes the problem is that the computer gets a new leased address by us forcing it from the registry. We are going to try and use wireshark now in the user computer that is broken to see if the client is getting the packets and just not replying correctly through the tunnel.
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!