Having to reboot Mac to access VPN

[Ian_bell]

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.

[angel.cox]

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

[mholland]

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

[SuperMario]

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.

[Brandon_Wertz]

---

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