Cannot Connect to GlobalProtect from hotspot

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.

Cannot Connect to GlobalProtect from hotspot

L1 Bithead

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  ? 

1 accepted solution

Accepted Solutions

L0 Member

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". 

View solution in original post

13 REPLIES 13

Cyber Elite
Cyber Elite

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,

No issue accessing things that don't require VPN but I cannot access work-related resources.

Screenshot 2024-01-22 at 6.58.15 PM.pngScreenshot 2024-01-22 at 6.58.21 PM.png

Cyber Elite
Cyber Elite

Hello,

I would guess that something is blocking the VPN connection? Check the PAN logs and see if the traffic is making it.

Regards,

L1 Bithead

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.

L0 Member

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

 

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.

GP not installed on the iPhone, so not sure if that applies 

That didn't help in my case

L0 Member

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". 

that's my issue. Thanks for providing a workaround 

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?

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.

When are they expected to be shipped?

  • 1 accepted solution
  • 5539 Views
  • 13 replies
  • 1 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!