Since upgrading our fleet of Macs to the v1.3.3484.2 client, we have discovered an issue that rolling back the client to v1.3.3373.6 seems to resolve. Almost every system connecting with 1.3.3484.2 are seeing constant “Lost DNS” and “Restore DNS” lines in logs that correspond to DNS lookup failures. Sure enough, watching DNS you can see it default back to the DHCP nameservers for a second before Pritunl re-engages. The client is replacing the DNS but I am at a loss as to what is causing the DNS to change in the first place once Pritunl is connected. I have seen this on Ventura 13.0.1, 13.3, and 13.3.1 all with rolling the client back being the only method I’ve found to stop the DNS from bouncing. Unfortunately rolling back leaves the client with the upgrade prompt on each launch which, although ignorable, would be nice to be able to suppress in a situation like this but that is secondary to the DNS issue. I’ve replicated the behavior on a freshly provisioned test system as well as existing systems that have been upgraded.
Anyone else having similar issues with the v1.3.3484.2 client on macOS?
You can disable DNS watch in the advanced settings under the top right menu. After a change occurs run sudo scutil --dns to check what the DNS settings were changed to. It is likely other software changing the DNS. When DNS issues occur on macOS both ping and curl should used to test the DNS. In macOS Ventura some applications use a newer DNS system which may have different settings.
Alternatively the Force DNS configuration option can be enabled in the profile settings. This should be enabled before connecting. The option will statically assign the DNS server with networksetup to the network interfaces while connected instead of using only scutil.
The Debugging Client documentation has more information on debugging DNS issues.
Thanks @zach. After some extended testing in various scenarios, we have a tentative fix deployed to all of our systems that appears to quell the constant 30-90 second bouncing of DNS we were seeing pretty widespread. The fix ended up being disabling IPv6 on all network services. We don’t use it internally but some ISP gateways\hotspots are offering IPv6 for internal networks which appears to trigger the chaos.
Pritunl overriding the DNS on these systems triggered macOS to continually try to reset the DNS to include the IPv6 server(s) which caused the loop we were seeing. Disabling IPv6 hasn’t eliminated the Lost DNS messages in the log entirely on all systems but the systems that had hundreds of bounces yesterday, have none or a very low amount that can be explained. I am still monitoring telemetry data from these systems so there is a chance I am speaking too soon but it appears flipping off IPv6 has stabilized the connection across the board here.