En tant qu'auteur de NetGuard, j'ai une expérience de première main dans ce domaine.
Un inconvénient d'un pare-feu basé sur un VPN local est que tous les types de trafic ne peuvent pas être gérés, parce que le noyau Linux (Android) ne permet pas de transférer tous les types de trafic sur une connexion basée sur une socket. Un exemple est IPsec, qui est utilisé pour les appels IP par certains fabricants. Une solution partielle (pas pour IPsec) à ce problème serait d'utiliser un serveur VPN à distance pour transférer le trafic, mais cela n'est pas acceptable pour beaucoup de gens en termes de vie privée et s'accompagnerait d'une complexité supplémentaire et probablement aussi d'une utilisation accrue de la batterie. En pratique, la gestion du trafic TCP et UDP semble être suffisante pour 99,9% des utilisateurs de NetGuard. Depuis Android 5, il est possible d'exclure des applications de l'acheminement vers le VPN (l'application mettant en œuvre le VPN décide si cela est obligatoire ou facultatif), ce qui peut être utilisé pour résoudre les problèmes liés à l'impossibilité de transférer tout le trafic. Une autre option est d'exclure des adresses (plages), que NetGuard utilise pour "réparer" les appels IP pour certains fabricants.
Un autre inconvénient est que le transfert du trafic augmente l'utilisation de la batterie des appareils mobiles, car il implique un certain traitement, les paquets devant être inspectés et transférés. L'utilisation d'iptables, qui est intégrée au noyau Linux, est plus efficace et donc plus respectueuse de la batterie.
En général, il s'est avéré qu'Android achemine tout le trafic vers le VPN, même le trafic des applications et des composants du système, mais un fabricant pourrait décider d'exclure certains types de trafic, réduisant ainsi la sécurité qui peut être obtenue par un pare-feu basé sur le VPN.
NetGuard n'analyse pas les données elles-mêmes, à l'exception des requêtes DNS pour assurer le blocage des publicités, mais s'il le faisait, cela pourrait soulever un problème de confidentialité. Néanmoins, d'un point de vue technique, c'est un avantage d'un pare-feu basé sur un VPN (si vous voulez toujours l'appeler ainsi), car il permettrait une inspection complète des flux de données au-delà de ce qui est possible avec iptables. Cela se ferait probablement au détriment de l'utilisation de la batterie, en raison du traitement nécessaire. Notez que cela nécessiterait une attaque MiT locale pour inspecter les flux SSL.
Un autre inconvénient est qu'Android ne permet pas le chaînage de VPN, donc l'utilisation d'un VPN local pour mettre en œuvre un pare-feu empêchera l'utilisation d'un véritable service VPN, à moins que le pare-feu ne fournisse un tel service lui-même ou un mécanisme de redirection ou de proxy vers une autre application VPN.
Enfin, un pare-feu basé sur un VPN dépend de l'application fournissant le service VPN du pare-feu qui doit être en cours d'exécution. Cela semble trivial, mais ne l'est pas, car certaines versions/variantes d'Android sont trop agressives et tuent les processus dans des conditions de mémoire faible (à mon avis, c'est un bug si Android tue les applications fournissant un service VPN).
Enfin, l'enracinement des appareils Android devient de plus en plus difficile, ce qui laisse un pare-feu basé sur un VPN comme seul choix pour de nombreuses personnes. Je ne m'attends pas à ce que Google ajoute de sitôt un pare-feu basé sur le système, car cela pourrait affecter de manière significative ses revenus publicitaires. iOS dispose d'un pare-feu basé sur le système.
Faites-moi savoir s'il y a des questions et j'essaierai d'y répondre.