topic Re: Having to reboot Mac to access VPN in Prisma Access Discussions

Having to reboot Mac to access VPN

Ian_bell — Tue, 10 Aug 2021 12:58:39 GMT

We are seeing a rash of Macs users that have to reboot their machines to get Global Protect to function after it just stops working. in the logs I am seeing lots of repeating messages such as this

65): getaddrinfo of [inet_ntoa error] failed with error 8, nodename nor servname provided, or not known

P1918-T15883 08/09/2021 17:50:08:105 Dump ( 977): Connect to [inet_ntoa error]:443 Failed

P1918-T15883 08/09/2021 17:50:08:105 Debug( 793): do_tcp_connect() failed

P1918-T15883 08/09/2021 17:50:08:105 Debug(3156): ConnectSSL: Failed to connect to ‘xxx.xxx.xxx.:443'. Disconnect ssl.

P1918-T15883 08/09/2021 17:50:08:105 Debug(5965): Set perfer ipv6 to false for [inet_ntoa error]

P1918-T15883 08/09/2021 17:50:08:105 Debug(3180): Try use ipv6 false for gateway xxx.xxx.xxx.xxx. New cutoff time 2

P1918-T15883 08/09/2021 17:50:08:105 Dump ( 177): pan_get_full_path(): full path in multibyte char is /Library/Application Support/PaloAltoNetworks/GlobalProtect/tca.cer

P1918-T15883 08/09/2021 17:50:08:105 Dump (1496): File /Library/Application Support/PaloAltoNetworks/GlobalProtect/tca.cer exists.

P1918-T15883 08/09/2021 17:50:08:105 Dump (1022): set trusted root ca file /Library/Application Support/PaloAltoNetworks/GlobalProtect/tca.cer

P1918-T15883 08/09/2021 17:50:08:105 Dump ( 177): pan_get_full_path(): full path in multibyte char is /Library/Application Support/PaloAltoNetworks/GlobalProtect/cc.pfx

P1918-T15883 08/09/2021 17:50:08:105 Dump (1500): File /Library/Application Support/PaloAltoNetworks/GlobalProtect/cc.pfx does not exist.

P1918-T15883 08/09/2021 17:50:08:105 Dump (3133): connect ssl.

P1918-T15883 08/09/2021 17:50:08:105 Debug( 788): SSL connecting to [inet_ntoa error]

P1918-T15883 08/09/2021 17:50:08:105 Dump ( 804): [inet_ntoa error] is ipv6

P1918-T15883 08/09/2021 17:50:08:105 Dump ( 400): inet_pton returns 0

P1918-T15883 08/09/2021 17:50:08:105 Dump ( 469): Receive timeout is 1

P1918-T15883 08/09/2021 17:50:08:105 Dump ( 516): Connect timeout is 5

and this

ConnectSSL: Failed to connect to 'xx.xxx.xxx.xxx:443'. Disconnect ssl.
P1933-T22843 08/09/2021 13:43:29:572 Debug(5965): Set perfer ipv6 to false for [inet_ntoa error)™)‡ÿÿ
P1933-T22843 08/09/2021 13:43:29:572 Debug(3180): Try use ipv6 false for gateway xxx.xxx.xxx.xxx.com. New cutoff time 2
P1933-T22843 08/09/2021 13:43:29:573 Debug( 788): SSL connecting to [inet_ntoa error)™)‡ÿÿ
P1933-T22843 08/09/2021 13:43:29:575 Debug( 565): getaddrinfo of [inet_ntoa error)™)‡ÿÿ failed with error 8, nodename nor servname provided, or not known
P1933-T22843 08/09/2021 13:43:29:575 Debug( 793): do_tcp_connect() failed

re starting the network connection does not relieve the issue and neither does refresh connection or a killall GlobalProtect.

Re: Having to reboot Mac to access VPN

angel.cox — Fri, 12 Nov 2021 15:06:44 GMT

found the same issue, while a restart does resolve the issue - this effectively restarts the PanGPS process, if you kill this process (pid 1933 in the original post), the process will re-spawn and negotiate the gateway connection. Even for the gateway that was in the prior error state. Verified this will a log capture of PanGPS.log for killing process ID 23047

p.s. Prior attempts for resolution involved turning off IPv6 for the "Wi Fi" (e.g. whatever you're using as eth0), but since that change of configuration does not exist the loop condition for the PanGPS process, a restart was also used - it is unclear if this remediated the issue moving forward.

P29584-T23047 11/12/2021 08:45:32:206 Debug(3183): Try use ipv6 false for gateway gp gateway fqdn. New cutoff time 4
P29584-T23047 11/12/2021 08:45:32:207 Debug( 788): SSL connecting to [inet_ntoa error]
P29584-T23047 11/12/2021 08:45:32:209 Debug( 565): getaddrinfo of [inet_ntoa error] failed with error 8, nodename nor servname provided, or not known
P29584-T23047 11/12/2021 08:45:32:209 Debug( 793): do_tcp_connect() failed
P29584-T23047 11/12/2021 08:45:32:209 Debug(3159): ConnectSSL: Failed to connect to 'gp gateway fqdn:443'. Disconnect ssl.
P29584-T23047 11/12/2021 08:45:32:209 Debug(5995): Set perfer ipv6 to false for [inet_ntoa error]
P29584-T23047 11/12/2021 08:45:32:209 Debug(3183): Try use ipv6 false for gateway gp gateway fqdn. New cutoff time 4
P29584-T23047 11/12/2021 08:45:32:209 Debug( 788): SSL connecting to [inet_ntoa error]
P29584-T23047 11/12/2021 08:45:32:212 Debug( 565): getaddrinfo of [inet_ntoa error] failed with error 8, nodename nor servname provided, or not known
P29584-T23047 11/12/2021 08:45:32:212 Debug( 793): do_tcp_connect() failed
P29584-T23047 11/12/2021 08:45:32:212 Debug(3159): ConnectSSL: Failed to connect to 'gp gateway fqdn:443'. Disconnect ssl.
P29584-T23047 11/12/2021 08:45:32:212 Debug(5995): Set perfer ipv6 to false for [inet_ntoa error]
P29584-T23047 11/12/2021 08:45:32:212 Debug(3183): Try use ipv6 false for gateway gp gateway fqdn. New cutoff time 4

Re: Having to reboot Mac to access VPN

mholland — Wed, 26 Jun 2024 17:51:44 GMT

Has anybody been able to resolve this issue? Experiencing the same.

Re: Having to reboot Mac to access VPN

SuperMario — Wed, 26 Jun 2024 18:08:56 GMT

I experienced a similar issues in two scenarios
1) while using GP 6.1.x. 6.2.2 has been very stable.
2) When a proxy intercepts the connection. You might need to check if there is a proxy and the proxy logs or take a pcap to check if something is intercepting your traffic.
If none of the above, the pcap and gp logs should help TAC to figure out what is going on.

Re: Having to reboot Mac to access VPN

Brandon_Wertz — Thu, 18 Jul 2024 16:54:24 GMT

@SuperMario wrote:

I experienced a similar issues in two scenarios
1) while using GP 6.1.x. 6.2.2 has been very stable.
2) When a proxy intercepts the connection. You might need to check if there is a proxy and the proxy logs or take a pcap to check if something is intercepting your traffic.
If none of the above, the pcap and gp logs should help TAC to figure out what is going on.

For your 6.1.X code were you using 6.1.5? We have some Mac users that were on 6.1.1 that experienced issues, but pushing them to 6.1.5 has been stable for our Mac users.