My testing was not a comprehensive assessment of macOS-compatible VPN services and my selection was biased towards breadth of implementations disregarding all other criteria. It would be inappropriate for me to recommend any of them as I did not assess for quality of app, support, billing, or privacy.
If it adds a default route to your routing table when you connect, it's fine. If it offers fancy per-app traffic rules, it's probably not fine.
In summary, for each VPN app, I connected to the VPN and then wiretapped my computer to see if it originated unencrypted network traffic to any Internet destination other than the VPN while operating a variety of core macOS services on the exclusion list, such as Software Update and App Store.
In each case, I was able to witness Apple traffic on the VPN network interface but not on the Ethernet interface below it.
For anyone testing Mullvad, please keep in mind that they make use of the macOS packet firewall layer in addition to the usual VPN network interface, which may complicate my testing procedure if followed stringently as there might not be Apple traffic on any interface, VPN or not, in that scenario. Mullvad context is in another post: https://news.ycombinator.com/item?id=25116863
APPENDIX: Note that, as far as I can determine, existing TCP connections were not reset onto the VPN when it was connected. Since I was inspecting all traffic, not just Apple traffic, I ended up having to restart Slack a couple of times just to get it to switch over to the VPNs. I would imagine this should be studied more closely, since it was a surprise to me.
