Aller au contenu
Avanet

Sophos Firewall : configurer Direct Web Proxy avec un fichier PAC

Sophos Firewall

Avec Direct Web Proxy, les navigateurs et les applications compatibles avec un proxy envoient volontairement leurs connexions HTTP et HTTPS à Sophos Firewall. Ce fonctionnement diffère du proxy web transparent et de DPI Engine : le client connaît la cible proxy et se connecte normalement au port TCP 3128.

Direct Web Proxy convient lorsque le trafic web doit être piloté de manière centralisée par un fichier PAC, authentifié par utilisateur ou traité par des fonctions qui nécessitent le proxy web. Il ne constitue toutefois pas un chemin Internet général pour toutes les applications. Seul le trafic qui utilise réellement la configuration proxy suit ce chemin.

⚠️ Un client autorisé à utiliser le proxy web peut atteindre par ce chemin les services HTTP et HTTPS locaux du pare-feu, même si WebAdmin, User Portal ou VPN Portal ne sont pas activés pour sa zone sous Device access. Le proxy est donc d’abord ouvert pour un seul client pilote, et ces cibles d’administration sont expressément testées négativement.

Cette procédure concerne un client pilote IPv4 administré. Pour les clients IPv6-only, configurer NAT64 avec Direct Web Proxy explique la règle IPv6 séparée vers le proxy et la règle IPv4 vers la destination A-only.

Direct Web Proxy en dix étapes

  1. Définir un client pilote administré, son IP fixe et les destinations web nécessaires.
  2. Documenter le FQDN du proxy, le DNS, le port d’écoute et les dépendances proxy existantes.
  3. Sous Web > General settings, vérifier Web proxy listening port et les ports de destination autorisés.
  4. Sous Administration > Device access, autoriser le service Web proxy uniquement pour le pilote et l’adresse prévue du pare-feu.
  5. Créer une règle de pare-feu dédiée et journalisée avec le pilote comme source, WAN comme destination, le service TCP 3128 et la Web Policy souhaitée.
  6. Préparer un fichier PAC avec des destinations internes DIRECT délibérées et sans fallback Internet contournant le proxy.
  7. Déployer l’URL PAC uniquement sur le client pilote et vérifier la configuration proxy effectivement chargée.
  8. Tester une requête HTTP/HTTPS autorisée et une requête bloquée, puis vérifier la Firewall Rule ID attendue.
  9. Tester négativement les portails locaux du pare-feu, le déchiffrement TLS, les applications sans prise en charge du proxy et une panne du proxy.
  10. Ajouter d’autres clients administrés seulement après ces tests, puis documenter le retour arrière, le responsable et la date de révision.

Direct Web Proxy, proxy transparent ou DPI ?

Ces trois termes décrivent des chemins de trafic différents :

  • Direct Web Proxy : Le client est explicitement configuré pour le pare-feu et son port proxy. Le navigateur, le système d’exploitation ou l’application envoie la requête à fw01.corp.example:3128.
  • Proxy web transparent : Le client ignore l’existence du proxy. Lorsque le service est actif pour sa zone, le pare-feu intercepte de manière transparente HTTP sur le port 80 et HTTPS sur le port 443.
  • DPI Engine : Le pare-feu traite le trafic routé sans imposer un proxy web classique et peut inspecter HTTP ou TLS sur d’autres ports en fonction des règles de pare-feu et de SSL/TLS inspection.

L’option Use web proxy instead of DPI engine d’une règle de pare-feu n’est pas nécessaire pour qu’un client explicitement configuré utilise Direct Web Proxy. Le chemin du client est créé par la configuration proxy. L’option détermine si la règle utilise le proxy web à la place de DPI Engine pour filtrer le trafic web normal sur les ports habituels.

Le choix complet du mode, y compris les fonctions propres au proxy, la configuration TLS et la migration contrôlée des règles, est détaillé dans Bien choisir entre DPI Engine et Web Proxy.

Sophos mentionne toujours certaines fonctions qui nécessitent Proxy Mode, notamment SafeSearch, YouTube Restrictions, les restrictions de domaine Google Workspace, Pharming Protection, Web Cache ou un Parent Proxy. Web Protection sur Sophos Firewall explique le choix de la stratégie et de la protection.

Lorsque Sophos Firewall doit envoyer des Web Requests à une autre instance proxy, configurer un upstream proxy dans WAN ou LAN/DMZ explique le chemin distinct des règles, du NAT et de la validation.

Direct Web Proxy modifie également la visibilité du trafic. Le client se connecte d’abord au pare-feu, puis celui-ci établit la connexion vers la destination. Sophos documente donc deux limites importantes :

  • Une IPS Policy s’applique entre le proxy et le WAN, pas entre l’utilisateur et le proxy.
  • Une Traffic Shaping Policy ne s’applique pas au trafic Direct Proxy.

Si une application ne peut pas utiliser de proxy explicite, il ne faut pas s’attendre à ce qu’un fichier PAC capture ses connexions. Cette application nécessite toujours un chemin DPI, de pare-feu ou de proxy distinct et normalement routé.

Exemple et valeurs à remplacer

Cet article utilise un petit pilote :

  • Client pilote : CLIENT-PROXY-01
  • IP fixe du client : 10.20.30.50
  • zone du client : LAN
  • FQDN du pare-feu et cible proxy : fw01.corp.example
  • port Direct Web Proxy : 3128
  • URL PAC : https://config.corp.example/proxy.pac
  • zone DNS interne : .corp.example
  • règle de pare-feu : LAN_DirectProxy_Pilot
  • Web Policy : Web_Standard_Pilot

Remplacer 10.20.30.50 par l’IP fixe que le pare-feu voit réellement comme source du pilote. DHCP doit fournir une réservation pour cette adresse. Aucun NAT ne doit dissimuler d’autres appareils derrière cette adresse.

fw01.corp.example et config.corp.example sont des noms de documentation. Ils sont remplacés par des FQDN résolus en interne et couverts par les certificats appropriés. Le FQDN du proxy pointe vers l’adresse LAN ou d’administration prévue du pare-feu. L’URL PAC pointe vers un serveur web interne contrôlé ou vers un chemin existant de gestion des terminaux, et non vers un emplacement public arbitraire.

Le port 3128 est la valeur par défaut de Direct Web Proxy. Si un autre Web proxy listening port est utilisé, Device Access, la règle de pare-feu, le fichier PAC, le navigateur, la SD-WAN Route et les tests doivent tous contenir le même port. Le nom de la règle ou de la stratégie est libre, mais il doit indiquer clairement son objectif, sa source et son statut de pilote.

Préparer l’accès proxy et la règle de protection

Définir le listener et les ports de destination autorisés

Vérifier les paramètres de base du proxy sous Web > General settings > Web proxy configuration :

  1. Web proxy listening port : 3128 dans cet exemple.
  2. Allowed destination ports : uniquement les ports auxquels les clients doivent réellement se connecter via le proxy.
  3. Minimum TLS version : version minimale commune au proxy web et à Captive Portal ; une modification affecte les deux fonctions.

Les ports de destination autorisés ne correspondent pas au listener. Le client se connecte au port 3128 du pare-feu, mais peut utiliser HTTP CONNECT pour demander, par exemple, une destination externe sur le port 443. Ajouter des ports de destination non standard uniquement après un test concret de l’application. Une liste étendue transforme inutilement le proxy en tunnel générique.

Avant de modifier le port, rechercher les fichiers PAC, GPO, stratégies de navigateur, hôtes RDS, SD-WAN Routes et systèmes de supervision existants. Le listener est un paramètre partagé, pas une valeur à modifier pour un seul pilote.

Limiter Device Access au pilote

Le service Web proxy est activé par défaut pour LAN et Wi-Fi. Une exception Accept supplémentaire ne limite pas une autorisation de zone étendue déjà active. Pour obtenir un véritable accès pilote, l’autorisation étendue doit donc rester désactivée ou être d’abord remplacée de manière contrôlée par des exceptions plus restreintes.

Sous Administration > Device access > Local service ACL exception rule > Add :

  1. Rule name : Allow_DirectProxy_Pilot
  2. Rule position : au-dessus d’une exception Drop correspondante
  3. IP version : IPv4
  4. Source zone : LAN
  5. Source Network / Host : CLIENT-PROXY-01 avec 10.20.30.50
  6. Destination host : adresse précise du pare-feu vers laquelle fw01.corp.example est résolu
  7. Services : Web proxy
  8. Action : Accept

Avant de désactiver une autorisation de zone étendue, vérifier si d’autres clients ou services utilisent déjà le proxy direct ou transparent. Le guide Device Access et Local Service ACL explique en détail l’ordre des règles, la matrice des zones et les règles d’exception.

Relier la Web Policy à la règle de pare-feu

Préparer la Web Policy sous Web > Policies. Elle contient les catégories, URL Groups, règles d’utilisateur ou de groupe et actions souhaitées. Pour le pilote, définir au moins une destination volontairement autorisée et une autre volontairement bloquée.

Créer ensuite une règle IPv4 dédiée sous Rules and policies > Firewall rules :

  • Rule name : LAN_DirectProxy_Pilot
  • Action : Accept
  • Log firewall traffic : activé
  • Source zones : LAN
  • Source networks and devices : CLIENT-PROXY-01
  • Destination zones : WAN
  • Destination networks : Any ou un groupe de destinations planifié de façon plus restrictive
  • Services : service TCP dédié pour 3128
  • Match known users : activer uniquement si le chemin d’authentification choisi a déjà réussi un test positif
  • Web filtering > Web policy : Web_Standard_Pilot
  • Block QUIC protocol : activer si le trafic web ne doit pas contourner parallèlement l’inspection proxy via UDP 443 ; Contrôler QUIC sur Sophos Firewall explique le contexte
  • Scan HTTP and decrypted HTTPS : uniquement avec la licence appropriée et un modèle d’analyse délibéré

Selon Sophos, Any est également possible comme service pour Direct Proxy, mais il est plus large que nécessaire. Un service TCP dédié au listener réel rend le pilote plus compréhensible. Après avoir sélectionné une Web Policy et d’autres fonctions de protection, vérifier à nouveau toute la règle. Les principes des règles de pare-feu expliquent l’ordre, la journalisation, la correspondance des utilisateurs et les champs de protection.

Un Linked NAT n’est pas automatiquement nécessaire pour ce pilote. Le chemin Internet créé par le pare-feu nécessite toutefois une passerelle WAN adaptée et la traduction de source valable dans l’environnement. Le routage et le NAT sont vérifiés séparément.

Créer et déployer le fichier PAC

Un exemple PAC volontairement restrictif

Un fichier PAC est du JavaScript avec la fonction FindProxyForURL. Cet exemple laisse passer directement uniquement les noms internes courts, la zone DNS interne et les réseaux privés indiqués. Toutes les autres destinations doivent utiliser le proxy :

function FindProxyForURL(url, host) {
  if (isPlainHostName(host) || dnsDomainIs(host, ".corp.example")) {
    return "DIRECT";
  }

  var isIPv4Literal = /^\d{1,3}(\.\d{1,3}){3}$/.test(host);
  if (isIPv4Literal && (
      isInNet(host, "10.0.0.0", "255.0.0.0") ||
      isInNet(host, "172.16.0.0", "255.240.0.0") ||
      isInNet(host, "192.168.0.0", "255.255.0.0"))) {
    return "DIRECT";
  }

  return "PROXY fw01.corp.example:3128";
}

Adapter .corp.example, les réseaux privés et le FQDN du proxy à l’environnement. Tous les réseaux RFC1918 ne doivent pas nécessairement être accessibles en interne. Il est plus propre d’établir la liste des domaines et réseaux internes réellement nécessaires.

L’exemple n’appelle volontairement pas dnsResolve() pour les noms d’hôte publics. Ces fonctions PAC déclenchent des résolutions DNS supplémentaires sur le client et peuvent ralentir le traitement ; ici, le proxy résout les noms externes. Les noms internes sont classés par les règles de domaine ou, lorsque la requête contient directement une adresse IPv4, par isInNet(). Si un environnement nécessite des exceptions plus complexes dépendantes du DNS, les planifier individuellement et les tester avec les navigateurs utilisés.

L’exemple ne contient volontairement aucun DIRECT après l’instruction proxy. Une valeur de retour comme PROXY fw01.corp.example:3128; DIRECT permet au trafic Internet de continuer directement si le proxy tombe en panne. Cette solution améliore la disponibilité, mais contourne alors la Web Policy, l’authentification proxy et la journalisation proxy. Nous déconseillons ce fallback fail-open pour un chemin de sécurité obligatoire.

Les exceptions internes DIRECT sont également des contournements. Les ajouter uniquement lorsque la destination doit réellement être atteinte directement et qu’un autre chemin de contrôle existe. Les domaines SaaS sensibles, les fournisseurs d’identité ou les jokers généraux ne doivent pas être ajoutés par précaution à la liste de contournement.

Déployer le fichier PAC de manière contrôlée

  1. Héberger le fichier PAC sur un endpoint HTTPS interne doté d’un certificat approuvé.
  2. S’assurer que https://config.corp.example/proxy.pac peut être récupéré sans proxy déjà fonctionnel.
  3. Affecter l’URL PAC uniquement au pilote par GPO, MDM ou stratégie de navigateur administrée.
  4. Documenter au préalable toute configuration proxy manuelle existante et les autres paramètres PAC ou WPAD.
  5. Redémarrer complètement le navigateur et les applications concernées.
  6. Vérifier quelle URL PAC a réellement été chargée dans la stratégie du navigateur ou du système d’exploitation.
  7. Bloquer de manière contrôlée l’accès direct à Internet en dehors du chemin proxy pour le pilote, ou au minimum le tester comme contournement.

La détection automatique WPAD n’est pas nécessaire pour cette procédure. Une URL PAC explicite et administrée est plus facile à identifier et à restaurer. Dans ce modèle, SFOS fournit le listener ; le déploiement, l’hébergement et le versionnage du fichier PAC restent des tâches de l’administration des clients et du serveur web.

Tester Direct Web Proxy

Vérifier le listener et l’application du PAC

Ces contrôles en lecture seule sont utiles sur un client pilote Windows :

Resolve-DnsName fw01.corp.example
Test-NetConnection fw01.corp.example -Port 3128

Le DNS doit renvoyer l’adresse prévue du pare-feu et le test TCP doit atteindre le listener. Un test de port réussi ne valide pas encore la Web Policy, l’authentification, le déchiffrement TLS ou la connexion Internet.

Vérifier ensuite dans le navigateur la stratégie proxy ou PAC réellement appliquée. Un ancien paramètre local, un deuxième profil de gestion ou un contenu PAC en cache peut remplacer la configuration attendue.

Valider le trafic autorisé et bloqué

  1. Ouvrir une nouvelle fenêtre de navigation privée.
  2. Ouvrir une destination HTTP ou HTTPS volontairement autorisée.
  3. Ouvrir une destination volontairement bloquée par Web_Standard_Pilot.
  4. Dans Log viewer, vérifier l’heure, la source, l’utilisateur, la Web Policy, l’action et la Firewall Rule ID.
  5. Pour HTTPS, consigner si la connexion a été déchiffrée ou volontairement laissée chiffrée.
  6. Sous Diagnostics > Packet capture, limiter si nécessaire la capture à la source 10.20.30.50, au port proxy et à la destination.
  7. Tester une application sans prise en charge du proxy et confirmer qu’elle n’est pas considérée à tort comme du trafic proxy.
  8. Affecter temporairement au client pilote une copie PAC de test avec un port proxy volontairement inutilisé et vérifier que le trafic Internet échoue comme prévu au lieu de contourner le proxy. Restaurer ensuite la version PAC de production.

La réussite ne signifie pas simplement qu’un site web se charge. La requête doit utiliser la Rule ID et la Web Policy attendues, le test de blocage doit réellement bloquer et une panne du proxy doit correspondre au modèle fail-closed choisi.

Vérifier que les services d’administration ne sont pas exposés

Depuis le client pilote, tester les adresses HTTP et HTTPS connues du pare-feu, en particulier :

  • WebAdmin
  • User Portal
  • VPN Portal
  • Captive Portal
  • les autres services HTTP/HTTPS locaux sur l’adresse du pare-feu utilisée

Il ne s’agit pas de forcer une connexion réussie. Le test détermine si le service devient accessible via le proxy. Si un service local non autorisé par le modèle de sécurité est visible, arrêter le déploiement. Device Access ne peut pas bloquer ensuite, par portail de destination, ces requêtes HTTP/HTTPS générées en interne par le proxy.

Distinguer l’authentification, TLS, SD-WAN et HA

L’identité utilisateur est un composant distinct

Direct Web Proxy peut être utilisé avec ou sans identité utilisateur. Selon l’environnement, les clients normaux peuvent utiliser AD SSO, STAS, Captive Portal ou une autre méthode prise en charge. La configuration proxy seule n’authentifie personne.

Pour les hôtes RDS ou les autres hôtes multi-utilisateurs sur lesquels plusieurs personnes partagent la même IP source, Per-Connection AD SSO est la procédure spécialisée appropriée. Chaque connexion proxy HTTP/HTTPS est authentifiée séparément ; le trafic hors proxy ne reçoit pas cette identité utilisateur.

Le déchiffrement HTTPS nécessite une CA approuvée

Scan HTTP and decrypted HTTPS n’active pas le déchiffrement. En mode proxy web, il faut également utiliser Decrypt HTTPS during web proxy filtering. La CA déployée sur les clients doit correspondre exactement à celle sélectionnée sous Web > General settings > HTTPS decryption and scanning.

Le déploiement sécurisé est décrit dans Introduire correctement TLS Inspection. Déployer le certificat CA Sophos Firewall explique le déploiement et la vérification de la CA de resignature. Le Certificate Pinning, les magasins de confiance distincts et les applications au comportement TLS inhabituel nécessitent des tests ciblés plutôt qu’une exception étendue.

Tester séparément SD-WAN et HA

Une SD-WAN Route avec les services HTTP et HTTPS ne correspond pas au trafic Direct Proxy sur 3128. Utiliser le port proxy réel ou délibérément Any. Source Network et Incoming Interface ne correspondent pas aux reply packets dans ce cas particulier. Le chemin retour du proxy nécessite également au moins une passerelle WAN ou une route statique adaptée. Configurer et tester les SD-WAN Routes fournit l’explication complète.

En HA, ne pas promettre la poursuite sans interruption des sessions proxy ou d’authentification existantes. Après un failover contrôlé, créer une nouvelle connexion de navigateur et vérifier à nouveau le fichier PAC, la Rule ID, la stratégie et le déchiffrement. Chaque nœud conserve les journaux du trafic qu’il a traité ; l’analyse doit donc porter sur le nœud qui traitait le trafic au moment de l’événement.

Dépannage systématique

Le port proxy n’est pas accessible

Vérifier la réponse DNS, l’adresse du pare-feu, le listener, la zone du client et Web proxy sous Device Access. Pour une exception ACL, la source, le Destination host, le service, l’action et la position doivent correspondre. Un ping réussi ne valide pas le listener TCP ; Test-NetConnection fournit un contrôle préliminaire plus précis.

Le navigateur accède directement à Internet

Vérifier l’URL PAC effective, le contenu du fichier chargé, les exceptions locales du navigateur et les autres profils GPO ou MDM. Un fallback DIRECT après PROXY crée volontairement un contournement lorsque le proxy est inaccessible. Les applications dotées de leur propre pile réseau peuvent également ignorer les paramètres proxy du système.

Le proxy renvoie l’erreur 407 ou demande des identifiants

Il s’agit d’un problème d’authentification, pas d’une panne du listener. Vérifier la méthode d’authentification, l’identification des utilisateurs, l’importation des groupes, la prise en charge par le navigateur et, si nécessaire, le FQDN/SPN. Ne pas élargir la règle à Any uniquement pour supprimer la demande d’identifiants.

Le site web se charge, mais la Web Policy ne s’applique pas

Vérifier ensemble la règle de pare-feu, son ordre, la source, le service 3128, la Web Policy sélectionnée et la Rule ID. Une requête proxy réussie peut avoir correspondu à une autre règle ou à une règle plus large. Le test contrôlé des règles combine Policy Test, Log Viewer et Packet Capture.

HTTPS affiche des erreurs de certificat

Vérifier si le déchiffrement est actif, quelle CA le proxy web utilise et si cette CA exacte se trouve dans le magasin de confiance du client. Si seules certaines applications échouent, examiner le Certificate Pinning, un magasin de confiance distinct, la version TLS et une exception aussi restreinte que possible.

Une application ou un port de destination particulier ne fonctionne pas

Déterminer d’abord si l’application prend en charge un proxy explicite. Vérifier ensuite Allowed destination ports, les contournements PAC, le DNS et le comportement TLS. Ajouter un port de destination non standard uniquement pour l’application concernée et le valider par une requête réelle.

La SD-WAN Route ou le chemin WAN est inattendu

Vérifier la correspondance du service avec le port proxy, la Rule ID, la passerelle WAN, la route statique et Route Precedence. Source Network et Incoming Interface ne constituent pas des critères de correspondance fiables pour les reply packets du proxy. Ne pas modifier globalement Route Precedence comme première mesure.

Les journaux sont absents ou trop pauvres

Vérifier Log firewall traffic dans la règle ainsi que les destinations locales, Central ou Syslog sous System services > Log settings. awarrenhttp.log concerne le proxy web et access_server.log l’authentification. Services et fichiers journaux de Sophos Firewall explique leur classement et leur collecte sûre.

Retour arrière et exploitation

Préparer le retour arrière avant le pilote :

  1. Documenter le paramètre proxy, PAC, GPO ou MDM précédent.
  2. Attribuer des noms explicites à la règle pilote et à l’exception Local Service ACL.
  3. Tester le chemin direct DPI ou de pare-feu précédent comme solution de repli.
  4. Supprimer l’affectation PAC du client pilote ou restaurer la version précédente.
  5. Redémarrer complètement le navigateur et les applications.
  6. Désactiver la règle pilote et tester un flux web direct réel par le chemin de repli.
  7. Supprimer l’exception ACL du pilote et rétablir les autorisations temporaires étendues de zone Web proxy à leur état précédent.
  8. Contrôler les données en direct et les journaux, puis documenter l’heure à partir de laquelle aucun trafic proxy n’est plus attendu.

En exploitation, le fichier PAC possède un historique des versions, un responsable et une date de révision. Chaque nouvelle exception DIRECT est une exception de stratégie et doit être justifiée, testée et réexaminée comme une exception de pare-feu ou web. Le listener, les ports de destination autorisés et les autorisations étendues de zone font également partie des contrôles périodiques.

Liste de contrôle

  • Direct Proxy est le modèle adapté aux navigateurs et applications concernés.
  • Le client pilote IPv4 et l’IP source fixe sont documentés.
  • Le FQDN du proxy, l’URL PAC et les certificats sont correctement résolus.
  • Le listener et les ports de destination autorisés sont aussi restrictifs que possible.
  • L’autorisation étendue de zone du proxy web a été contrôlée et remplacée si nécessaire.
  • L’exception Local Service ACL limite la source et l’adresse de destination du pare-feu.
  • La règle de pare-feu utilise le port proxy, la journalisation et la Web Policy attendue.
  • Le fichier PAC contient uniquement des exceptions internes DIRECT justifiées.
  • Aucun fallback Internet contournant le proxy n’est actif à l’insu de l’administrateur.
  • Le trafic réel autorisé et bloqué correspond à la Rule ID attendue.
  • Les services HTTP/HTTPS locaux du pare-feu ont été testés négativement.
  • L’authentification, le déchiffrement TLS, QUIC et les applications hors proxy ont été évalués séparément.
  • Le comportement de SD-WAN et HA a été testé lorsque ces fonctions sont utilisées.
  • Le retour arrière, le responsable, le versionnage et la date de révision sont documentés.

Questions fréquentes

Faut-il activer Use web proxy instead of DPI engine pour Direct Web Proxy ?

Non. Un client explicitement configuré utilise Direct Web Proxy par le listener défini même sans cette option. L’option détermine si une règle de pare-feu filtre le trafic web normal sur les ports habituels avec le proxy web au lieu de DPI Engine.

Le fichier PAC doit-il utiliser DIRECT comme fallback en cas de panne du proxy ?

Normalement pas pour un chemin de sécurité obligatoire. PROXY ...; DIRECT maintient l’accès à Internet, mais contourne la Web Policy, l’authentification proxy et la journalisation proxy en cas de panne. Les destinations internes peuvent rester directement accessibles de manière délibérée ; un fallback Internet nécessite une décision de risque documentée.

Pourquoi faut-il une exception Local Service ACL en plus de la règle de pare-feu ?

Le listener proxy est un service local du pare-feu et se contrôle avec Device Access ou Local Service ACL. La règle de pare-feu définit ensuite le flux autorisé et la Web Policy. Ces deux niveaux répondent à des tâches différentes.

Direct Web Proxy peut-il contrôler toutes les applications ?

Non. Il capture uniquement les connexions HTTP et HTTPS des clients et applications qui utilisent le proxy explicite. DNS, UDP, RDP, SMB et les applications dotées de leur propre pile réseau ou incompatibles avec un proxy nécessitent un autre chemin contrôlé.