- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-21-2024 11:06 AM
I have T-mobile as my phone carrier and when I connect my work laptop (Macbook pro) to my personal phone hotspot GP is not able to connect.
I did some search and found that people in past changed MTU value but tired and didn't work.
I find this is as miss from GP because sometime there's power outages in my area and I have to use hotspot or sometimes there's ISP maintaince.
Any idea if there's a workaround or this is expected and if so is there plan to handle hotspots ?
02-15-2024 02:05 PM
There's a bug in the GP client code that's encountered when connecting via an iPhone hotspot that's using an IPv6 only cell carrier where NAT64/CLAT are used. Under these conditions PanGPS segfaults and crashes while it's processing gateway's from what appears to be a null pointer dereference. The bugged logic seems to occur from the 192.0.0.2/32 your WiFi interface is receiving from the iPhones DHCP. Apple must have made a change here in one of the recent IOS updates.
As a workaround, change your WiFi interface to a static IP with a netmask that isn't /32:
Something like:
> networksetup -setmanual Wi-Fi 172.20.10.3 255.255.255.240 172.20.10.1
And when you disconnect from your hotspot and reconnect to regular wifi you would need to revert with:
> networksetup -setdhcp Wi-Fi
You can verify if you're encountering the same bug by checking the crash log (.ips extension) in the GP troubleshooting logs.
You'll see:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020
Exception Codes: 0x0000000000000001, 0x0000000000000020
The segfault always occurs in the pan_connect_socket() function (3140 bytes in on ARM64; 3408 bytes in on x86), usually in the 'CaptivePortalDetectionThread' thread, but sometimes on other threads such as the "NetworkDiscoverThread".
01-22-2024 12:40 PM
Hello,
Are you able to perform any web browsing at all? Could be a DNS resolution issue? Once on the hotspot, exit out of GP and relaunch it.
Regards,
01-22-2024 07:49 PM
No issue accessing things that don't require VPN but I cannot access work-related resources.
01-23-2024 07:40 AM
Hello,
I would guess that something is blocking the VPN connection? Check the PAN logs and see if the traffic is making it.
Regards,
01-25-2024 11:50 AM
If you are having MTU issues on Global Protect on TMobile the issue commonly presents as "gateway appears connected, but actual data will not pass through the created tunnel." So web sites will not work, outlook will not connect, etc even though the gateway appears connected in the Global Protect. If the problem is MTU, switching to SSL (though note it will not automatically fail over to SSL for this issue) will get connections flowing. Also as you have noted lowing the MTU helps as well. As far as I have seen MTU on Tmobile is 1420-ish. Thus as I understand, you would want the GP MTU setting to be Tmobile's MTU minus the IPSEC header size which will vary based on what encryption parameters you are using. Though I have been only working on this problem for a few days so most of my info is coming from what I learned over on /r/TmobileISP and from Tmobile's support forums.
01-26-2024 05:29 AM
I have same problem.
I think this issue was occurred IPhone' IOS 17.2 later.
Temporarily, I changed IP Setting from dhcp to static on Macbook.
Ex : 172.20.10.5/24
Gateway : 172.20.10.1
01-29-2024 02:40 AM
From Iphone there is option you can select the certificate which used for the GP and Enable trust this will work tried in one customer firewall.
01-29-2024 09:37 AM
GP not installed on the iPhone, so not sure if that applies
01-31-2024 10:27 PM
That didn't help in my case
02-15-2024 02:05 PM
There's a bug in the GP client code that's encountered when connecting via an iPhone hotspot that's using an IPv6 only cell carrier where NAT64/CLAT are used. Under these conditions PanGPS segfaults and crashes while it's processing gateway's from what appears to be a null pointer dereference. The bugged logic seems to occur from the 192.0.0.2/32 your WiFi interface is receiving from the iPhones DHCP. Apple must have made a change here in one of the recent IOS updates.
As a workaround, change your WiFi interface to a static IP with a netmask that isn't /32:
Something like:
> networksetup -setmanual Wi-Fi 172.20.10.3 255.255.255.240 172.20.10.1
And when you disconnect from your hotspot and reconnect to regular wifi you would need to revert with:
> networksetup -setdhcp Wi-Fi
You can verify if you're encountering the same bug by checking the crash log (.ips extension) in the GP troubleshooting logs.
You'll see:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020
Exception Codes: 0x0000000000000001, 0x0000000000000020
The segfault always occurs in the pan_connect_socket() function (3140 bytes in on ARM64; 3408 bytes in on x86), usually in the 'CaptivePortalDetectionThread' thread, but sometimes on other threads such as the "NetworkDiscoverThread".
02-19-2024 12:00 PM
that's my issue. Thanks for providing a workaround
02-29-2024 01:24 PM
Given this is a known issue, I would assume PaloAlto will provide a fix eventually.
Is anybody aware of an internal ticket that this is being worked on?
03-13-2024 02:58 PM - edited 03-13-2024 02:59 PM
Per PAN TAC, this is a known issue and the fix will be in 6.3 (when released), 6.1.5, 6.2.3, and 6.0.10, when they ship.
My case number is 02936908.
04-26-2024 03:55 PM
When are they expected to be shipped?
04-27-2024 07:47 AM
As a major palo alto customer, I just switched back to a company ATT iphone. A hassle, but otherwise we wait for Palo to patch, and our FW team to vet and implement. Still not working. Was an unpleasant surprise when remote and oncall, and couldn’t connect.
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!