En effet il y a de sérieux problèmes de compréhension.
le job d'un firewall est de filtrer des flux IP en fonction de règles selon les protocoles et les sources et destination,
on peut ajouter la gestion de vpn, la gestion de "traffic shaping" (de façon brute sur un protocole), …
bien sur, le firewall doit suivre les "sessions" (au sens IP).
un proxy (sous-entendu pour le protocole http) va travailler DANS la session http et filtrer à l'intérieur du protocole,
de plus le proxy établit la session réelle avec le serveur à la place du client,
et le proxy ajoute une fonction "cache"
là où le firewall travaille sur l'entête des paquets IP (et doit répondre dans les temps correspondants), un proxy http travaille sur la session (et a "du temps" pour traiter).
là où le firewall doit disposer de mémoire pour suivre les sessions IP, un proxy doit disposer d'une mémoire folle pour reconstruire les requêtes http, les index de blacklists avec au moins 1 millions d'url
Le discours marketing des firewall UTM consiste à ne surtout pas parler de ces différences essentielles entre les 2 jobs.
Avec une charge faible, cela peut fonctionner (p.e. pour une pme jqa 50 pers.), mais dès que la charge augmente, il y a conflit évident entre les fonctions.
Sans compter qu'il est facile de comprendre qu'avec une seule fonction bien définie, un serveur dédié peut mieux accomplir sa tache : proxy http, relay smtp, ...
Ah votre firewall UTM n'avance pas, quelle surprise ...