GlobalProtect not allowing internet access when Parallels or Docker are running

[colebrand]

MacOS installed: macOS Sonoma 14.5 latest

GlobalProtect client installed: 6.0.7-372

Parallels Desktop: 18.2.0 (53488)

As the post title says, when Parallels or Docker are running, our GP isn't allowing network access (myself and others are having similar issues, I don't run Docker locally personally, so I didn't put a version number, but including because I suspect it's going to tip off someone) until we close both of those apps. Once those are out of process, the VPN will connect fine, every internet connected app is fine, and then we can start the apps back and everything is functioning correctly.

To be very clear, GlobalProtect establishes and shows connected, but then nothing will respond to DNS events, so no network based app can make connectivity. 

I've checked /etc/resolver, that's showing the expected value in any scenario. I don't understand enough about the macOS routing tables to understand what I'm looking at for which route should take precedence (skills issue, I can't really even find this with google/bing searches, but I'm sure it's a common enough problem). We do use a full tunnel route, and the neteng can see that I'm establishing correct connections, so this is clearly something happening on the local end.

Dig and nslookup (when in the faulted state) can't resolve anything, even with a sighup on mdnsresponder and dnscacheresponder, but in the non-faulted state work as expected.

This has worked for a long time, and we recently had some changes to move to a new endpoint, but the neteng team is sure they've mirrored the prior configuration, so clearly something is being overlooked, but I just don't know enough about this to pinpoint things. I did do a full uninstall and reinstall of the GP client using the latest version from our PA endpoint after this occurred.

To recap: VPN works for a long time. Precipitating event occurs. Full reinstall of client. When Parallels (or Docker) are running, no DNS over tunnel.

What are we overlooking? What should I be checking in either configs or in macOS configs (I'm open to running whatever on the terminal, I just don't know the right skills for this particular debugging event)

[BPry]

@colebrand,

Have your network engineers looked at the route table output (netstat -rn) when they've been troubleshooting this issue? It certainly sounds like it's a routing issue; just to confirm is the issue only present if you connect to the VPN while Docker/Parrelels is active prior to the VPN connection?

[colebrand]

They have, but nothing jumps out at them as to what would be the culprit. Any advice on how to interpret those results cleanly to figure out the offending route, or to devalue it so it's not prioritized?

I suspect this issue lies with Parallels support, but I don't expect them to be as knowledgeable as actual network engineers to tell me what to change, since I can't find anything (thanks SEO) for my issue from their end either. I suspect this is a new development, something has changed _recently_ but none of us are sure what.