Sophos Firewall Direct Web Proxy mit PAC-Datei einrichten

Beim Direct Web Proxy senden Browser und proxyfähige Anwendungen ihre HTTP- und HTTPS-Verbindungen bewusst an die Sophos Firewall. Das unterscheidet ihn vom transparenten Web Proxy und vom DPI Engine: Der Client kennt das Proxyziel und verbindet sich normalerweise mit TCP-Port 3128.

Der Direct Web Proxy ist hilfreich, wenn Webtraffic zentral über eine PAC-Datei gesteuert, benutzerbezogen authentifiziert oder mit Funktionen verarbeitet werden soll, die den Web Proxy benötigen. Er ist aber kein allgemeiner Internetpfad für jede Anwendung. Nur Traffic, der die Proxykonfiguration tatsächlich verwendet, läuft über diesen Weg.

⚠️ Ein Client mit Zugriff auf den Web Proxy kann über diesen Pfad lokale HTTP- und HTTPS-Dienste der Firewall erreichen, auch wenn WebAdmin, User Portal oder VPN Portal in seiner Zone unter Device access nicht aktiviert sind. Deshalb den Proxy zuerst nur für einen Pilotclient öffnen und diese Managementziele ausdrücklich negativ testen.

Dieser Ablauf behandelt einen verwalteten IPv4-Pilotclient. Für IPv6-only-Clients führt NAT64 mit Direct Web Proxy einrichten durch die getrennte IPv6-Regel zum Proxy und die IPv4-Regel zum A-only-Ziel.

Direct Web Proxy in zehn Schritten

1. Einen verwalteten Pilotclient, dessen feste IP und die benötigten Webziele festlegen.
2. Proxy-FQDN, DNS, Listener-Port und bestehende Proxyabhängigkeiten dokumentieren.
3. Unter Web > General settings den Web proxy listening port und die erlaubten Zielports prüfen.
4. Unter Administration > Device access den Service Web proxy nur für den Piloten und die vorgesehene Firewall-Adresse erlauben.
5. Eine eigene, geloggte Firewallregel mit Source Pilot, Destination WAN, Service TCP 3128 und der gewünschten Web Policy erstellen.
6. Eine PAC-Datei mit bewussten internen DIRECT-Zielen und ohne Internet-Fallback am Proxy vorbei vorbereiten.
7. Die PAC-URL nur an den Pilotclient verteilen und die tatsächlich geladene Proxykonfiguration prüfen.
8. Einen erlaubten und einen blockierten HTTP-/HTTPS-Aufruf testen und die erwartete Firewall Rule ID kontrollieren.
9. Lokale Firewall-Portale, TLS-Decryption, Anwendungen ohne Proxyunterstützung und einen Proxy-Ausfall negativ testen.
10. Erst danach weitere verwaltete Clients aufnehmen und Rollback, Owner sowie Review-Datum dokumentieren.

Direct Web Proxy, transparenter Proxy oder DPI?

Die drei Begriffe beschreiben unterschiedliche Datenpfade:

• Direct Web Proxy: Der Client ist ausdrücklich auf die Firewall und deren Proxyport konfiguriert. Browser, Betriebssystem oder Anwendung senden den Request an fw01.corp.example:3128.
• Transparenter Web Proxy: Der Client kennt keinen Proxy. Wenn der Service für seine Zone aktiv ist, fängt die Firewall HTTP auf Port 80 und HTTPS auf Port 443 transparent ab.
• DPI Engine: Die Firewall verarbeitet gerouteten Traffic ohne klassischen Web-Proxy-Zwang und kann HTTP beziehungsweise TLS auf weiteren Ports anhand der Firewall- und SSL/TLS-Inspection-Regeln prüfen.

Der Schalter Use web proxy instead of DPI engine in einer Firewallregel ist nicht die Voraussetzung dafür, dass ein ausdrücklich konfigurierter Client den Direct Web Proxy verwendet. Der Clientpfad entsteht durch die Proxykonfiguration. Der Schalter entscheidet, ob die Regel für normalen Webtraffic den Web Proxy statt der DPI Engine zur Filterung auf den üblichen Ports verwendet.

Die vollständige Moduswahl samt Proxy-only-Funktionen, TLS-Konfiguration und kontrollierter Regelmigration erklärt DPI Engine oder Web Proxy richtig wählen.

Sophos nennt weiterhin einzelne Funktionen, für die Proxy Mode erforderlich ist, etwa SafeSearch, YouTube Restrictions, Google-Workspace-Domainbeschränkungen, Pharming Protection, Web Cache oder einen Parent Proxy. Die Policy- und Schutzentscheidung erklärt Web Protection auf Sophos Firewall.

Wenn die Sophos Firewall Web Requests an eine weitere Proxyinstanz senden soll, erklärt Upstream Proxy im WAN oder LAN/DMZ einrichten den getrennten Regel-, NAT- und Testpfad.

Der Direct Web Proxy ändert auch die Sicht auf den Traffic. Der Client verbindet sich zuerst mit der Firewall; die Firewall erzeugt danach die Verbindung zum Ziel. Sophos dokumentiert deshalb zwei wichtige Grenzen:

• Eine IPS Policy greift zwischen Proxy und WAN, nicht zwischen Benutzer und Proxy.
• Eine Traffic Shaping Policy gilt nicht für Direct-Proxy-Traffic.

Wenn eine Anwendung nicht mit einem expliziten Proxy arbeiten kann, darf man nicht erwarten, dass ihre Verbindungen durch eine PAC-Datei erfasst werden. Für diese Anwendung bleibt ein normaler gerouteter DPI-, Firewall- oder eigener Proxyweg nötig.

Beispiel und austauschbare Werte

Der Artikel verwendet einen kleinen Pilot:

• Pilotclient: CLIENT-PROXY-01
• feste Client-IP: 10.20.30.50
• Clientzone: LAN
• Firewall-FQDN und Proxyziel: fw01.corp.example
• Direct-Web-Proxy-Port: 3128
• PAC-URL: https://config.corp.example/proxy.pac
• interne DNS-Zone: .corp.example
• Firewallregel: LAN_DirectProxy_Pilot
• Web Policy: Web_Standard_Pilot

10.20.30.50 wird durch die feste IP des Piloten ersetzt, welche die Firewall tatsächlich als Source sieht. DHCP sollte dafür eine Reservation liefern. Hinter der Adresse darf sich kein NAT befinden, das weitere Geräte verdeckt.

fw01.corp.example und config.corp.example sind Dokumentationsnamen. Sie werden durch intern auflösbare, zertifikatsseitig passende FQDNs ersetzt. Der Proxy-FQDN zeigt auf die vorgesehene LAN- oder Managementadresse der Firewall. Die PAC-URL zeigt auf einen kontrollierten internen Webserver oder einen bestehenden Endpoint-Management-Pfad, nicht auf eine zufällige öffentliche Ablage.

Port 3128 ist der Standard des Direct Web Proxy. Wird ein anderer Web proxy listening port verwendet, müssen Device Access, Firewallregel, PAC-Datei, Browser, SD-WAN Route und Tests denselben Port enthalten. Ein individueller Name für Regel oder Policy ist frei wählbar; er sollte Zweck, Source und Pilotstatus erkennen lassen.

Proxyzugang und Schutzregel vorbereiten

Listener und erlaubte Zielports festlegen

Unter Web > General settings > Web proxy configuration werden die Proxygrundlagen geprüft:

1. Web proxy listening port: für dieses Beispiel 3128.
2. Allowed destination ports: nur Ports, zu denen Clients über den Proxy wirklich Verbindungen aufbauen müssen.
3. Minimum TLS version: gemeinsame Mindestversion für Web Proxy und Captive Portal; eine Änderung betrifft beide Funktionen.

Die erlaubten Zielports sind nicht der Listener. Der Client verbindet sich mit 3128 zur Firewall, kann über HTTP CONNECT aber beispielsweise ein externes Ziel auf Port 443 anfordern. Nicht standardmässige Zielports werden nur nach einem konkreten Anwendungstest ergänzt. Eine breite Portliste macht den Proxy unnötig zu einem generischen Tunnel.

Vor einer Portänderung bestehende PAC-Dateien, GPOs, Browserrichtlinien, RDS-Hosts, SD-WAN Routes und Monitoring durchsuchen. Der Listener ist eine gemeinsame Einstellung und kein Wert, den man nur für einen einzelnen Piloten ändert.

Device Access auf den Piloten begrenzen

Der Service Web proxy ist in der Werkseinstellung für LAN und Wi-Fi aktiviert. Eine zusätzliche Accept-Exception verengt eine bereits aktive breite Zonenfreigabe nicht. Für einen echten Pilotzugang muss die breite Freigabe deshalb aus bleiben oder zuerst kontrolliert durch engere Ausnahmen ersetzt werden.

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

1. Rule name: Allow_DirectProxy_Pilot
2. Rule position: oberhalb einer passenden Drop-Exception
3. IP version: IPv4
4. Source zone: LAN
5. Source Network / Host: CLIENT-PROXY-01 mit 10.20.30.50
6. Destination host: konkrete Firewall-Adresse, welche fw01.corp.example auflöst
7. Services: Web proxy
8. Action: Accept

Vor dem Deaktivieren einer breiten Zonenfreigabe prüfen, ob bereits andere Clients oder Dienste den Direct beziehungsweise transparenten Proxy verwenden. Die Device-Access- und Local-Service-ACL-Anleitung erklärt Regelreihenfolge, Zonenmatrix und Exception Rules im Detail.

Web Policy und Firewallregel verbinden

Die Web Policy wird unter Web > Policies vorbereitet. Sie enthält die gewünschten Kategorien, URL Groups, Benutzer- oder Gruppenregeln und Aktionen. Für den Pilot sollte mindestens ein erlaubtes und ein bewusst blockiertes Ziel feststehen.

Danach unter Rules and policies > Firewall rules eine eigene IPv4-Regel erstellen:

• Rule name: LAN_DirectProxy_Pilot
• Action: Accept
• Log firewall traffic: aktiv
• Source zones: LAN
• Source networks and devices: CLIENT-PROXY-01
• Destination zones: WAN
• Destination networks: Any oder eine enger geplante Zielgruppe
• Services: eigener TCP-Service für 3128
• Match known users: nur aktivieren, wenn der gewählte Authentifizierungspfad bereits positiv getestet ist
• Web filtering > Web policy: Web_Standard_Pilot
• Block QUIC protocol: aktiv, wenn der Webtraffic nicht parallel über UDP 443 an der Proxyprüfung vorbeilaufen darf; die Hintergründe erklärt QUIC auf Sophos Firewall kontrollieren
• Scan HTTP and decrypted HTTPS: nur mit passender Lizenz und bewusstem Scan-Design

Any als Service ist laut Sophos für Direct Proxy ebenfalls möglich, aber breiter als nötig. Der eigene TCP-Service für den tatsächlichen Listener macht den Pilot nachvollziehbarer. Nach Auswahl einer Web Policy und weiterer Schutzfunktionen die komplette Regel nochmals prüfen; die Firewall-Regel-Grundlagen erklären Reihenfolge, Logging, Benutzerbezug und Schutzfelder.

Ein Linked NAT ist für diesen Pilot nicht automatisch nötig. Der von der Firewall erzeugte Internetpfad benötigt aber ein passendes WAN-Gateway und die für die Umgebung gültige Source-Translation. Routing und NAT werden getrennt geprüft.

PAC-Datei erstellen und verteilen

Ein bewusst enges PAC-Beispiel

Eine PAC-Datei ist JavaScript mit der Funktion FindProxyForURL. Dieses Beispiel lässt nur kurze interne Namen, die interne DNS-Zone und die aufgeführten privaten Netze direkt laufen. Alle anderen Ziele müssen den Proxy verwenden:

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";
}

.corp.example, die privaten Netze und der Proxy-FQDN werden an die eigene Umgebung angepasst. Nicht jedes RFC1918-Netz muss intern erreichbar sein. Sauberer ist eine Liste der tatsächlich benötigten internen Domains und Netze.

Das Beispiel ruft für öffentliche Hostnamen bewusst kein dnsResolve() auf. Solche PAC-Funktionen lösen DNS zusätzlich auf dem Client aus und können die Verarbeitung verzögern; für externe Ziele übernimmt hier der Proxy die Namensauflösung. Interne Namen werden über die Domainregeln oder, bei einer direkten IPv4-Adresse im Request, über isInNet() eingeordnet. Benötigt eine Umgebung komplexere DNS-abhängige Ausnahmen, werden sie einzeln geplant und mit den verwendeten Browsern getestet.

Das Beispiel enthält bewusst kein DIRECT hinter der Proxyanweisung. Ein Rückgabewert wie PROXY fw01.corp.example:3128; DIRECT lässt Internettraffic bei einem Proxyfehler direkt weiterlaufen. Das erhöht Verfügbarkeit, umgeht dann aber Web Policy, Proxy-Authentifizierung und Proxy-Logging. Für einen verbindlichen Sicherheitsweg empfehlen wir diesen Fail-open-Fallback nicht.

Auch interne DIRECT-Ausnahmen sind Bypässe. Sie werden nur aufgenommen, wenn das Ziel wirklich direkt erreichbar sein soll und ein anderer Kontrollpfad besteht. Sensible SaaS-Domains, Identity Provider oder allgemeine Wildcards gehören nicht vorsorglich in die Bypass-Liste.

PAC-Datei kontrolliert ausrollen

1. PAC-Datei auf einem internen HTTPS-Endpunkt mit vertrauenswürdigem Zertifikat bereitstellen.
2. Abruf von https://config.corp.example/proxy.pac ohne bereits funktionierenden Proxy sicherstellen.
3. PAC-URL per GPO, MDM oder verwalteter Browserrichtlinie nur dem Piloten zuweisen.
4. Eine vorhandene manuelle Proxykonfiguration und andere PAC-/WPAD-Vorgaben vorher dokumentieren.
5. Browser und betroffene Anwendungen vollständig neu starten.
6. In der Browser- oder Betriebssystemrichtlinie prüfen, welche PAC-URL effektiv geladen wurde.
7. Direkten Internetzugriff ausserhalb des Proxywegs für den Piloten kontrolliert sperren oder zumindest als Bypass testen.

WPAD-Autodiscovery ist für diesen Ablauf nicht nötig. Eine explizite verwaltete PAC-URL ist leichter zuzuordnen und zurückzunehmen. SFOS stellt in diesem Ablauf den Listener bereit; Verteilung, Hosting und Versionierung der PAC-Datei bleiben eine Aufgabe der Client- und Webserververwaltung.

Direct Web Proxy testen

Listener und PAC-Übernahme prüfen

Auf einem Windows-Pilotclient sind diese lesenden Prüfungen hilfreich:

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

DNS muss die vorgesehene Firewall-Adresse liefern, und der TCP-Test muss den Listener erreichen. Ein erfolgreicher Porttest beweist noch keine Web Policy, Authentifizierung, TLS-Decryption oder Internetverbindung.

Danach im Browser die tatsächlich angewendete Proxy- oder PAC-Richtlinie kontrollieren. Eine alte lokale Einstellung, ein zweites Managementprofil oder ein gecachter PAC-Inhalt kann die erwartete Konfiguration übersteuern.

Erlaubten und blockierten Traffic abnehmen

1. Einen neuen privaten Browser öffnen.
2. Ein bewusst erlaubtes HTTP- oder HTTPS-Ziel aufrufen.
3. Ein durch Web_Standard_Pilot bewusst blockiertes Ziel aufrufen.
4. Im Log viewer Zeit, Source, Benutzer, Web Policy, Action und Firewall Rule ID prüfen.
5. Bei HTTPS festhalten, ob die Verbindung entschlüsselt oder bewusst nicht entschlüsselt wurde.
6. Unter Diagnostics > Packet capture bei Bedarf Source 10.20.30.50, Proxyport und Ziel eingrenzen.
7. Eine Anwendung ohne Proxyunterstützung testen und bestätigen, dass sie nicht fälschlich als Proxytraffic bewertet wird.
8. Dem Pilotclient vorübergehend eine PAC-Testkopie mit einem bewusst nicht belegten Proxyport zuweisen und prüfen, ob Internettraffic wie geplant fehlschlägt statt direkt auszuweichen. Danach die produktive PAC-Version wiederherstellen.

Erfolg bedeutet nicht nur, dass eine Website lädt. Der Request muss die erwartete Rule ID und Web Policy verwenden, der Blocktest muss wirklich blockieren, und ein Proxyfehler muss dem gewählten Fail-closed-Design entsprechen.

Managementdienst-Exposition negativ testen

Vom Pilotclient aus die bekannten HTTP-/HTTPS-Adressen der Firewall prüfen, insbesondere:

• WebAdmin
• User Portal
• VPN Portal
• Captive Portal
• weitere lokale HTTP-/HTTPS-Dienste auf der verwendeten Firewall-Adresse

Dabei geht es nicht darum, einen erfolgreichen Login zu erzwingen. Es wird geprüft, ob der Dienst über den Proxy überhaupt erreichbar wird. Ist ein im Sicherheitsdesign unzulässiger lokaler Dienst sichtbar, den Rollout stoppen. Device Access kann diese vom Proxy intern erzeugten HTTP-/HTTPS-Requests nicht nachträglich pro Zielportal blockieren.

Authentifizierung, TLS, SD-WAN und HA abgrenzen

Benutzeridentität ist ein eigener Baustein

Der Direct Web Proxy kann mit oder ohne Benutzeridentität eingesetzt werden. Für normale Clients kommen je nach Umgebung AD SSO, STAS, Captive Portal oder andere unterstützte Verfahren infrage. Die Proxykonfiguration allein authentifiziert niemanden.

Für RDS- oder andere Multi-User-Hosts, auf denen mehrere Personen dieselbe Source-IP teilen, ist Per-Connection AD SSO der passende Spezialablauf. Dabei wird jede HTTP-/HTTPS-Proxyverbindung separat authentifiziert; Non-Proxy-Traffic bleibt ohne diese Benutzeridentität.

HTTPS-Decryption benötigt eine vertraute CA

Scan HTTP and decrypted HTTPS aktiviert keine Entschlüsselung. Im Web-Proxy-Modus wird dafür zusätzlich Decrypt HTTPS during web proxy filtering verwendet. Die auf Clients verteilte CA muss exakt zur unter Web > General settings > HTTPS decryption and scanning gewählten CA passen.

Der sichere Rollout steht unter TLS Inspection richtig einführen. Die Verteilung und Prüfung der Re-Signing-CA erklärt Sophos Firewall CA-Zertifikat verteilen. Certificate Pinning, eigene Trust Stores und Anwendungen mit ungewöhnlichem TLS-Verhalten benötigen gezielte Tests statt einer breiten Ausnahme.

SD-WAN und HA separat testen

Eine SD-WAN Route mit Services HTTP und HTTPS matcht Direct-Proxy-Traffic auf 3128 nicht. Man verwendet den tatsächlichen Proxyport oder bewusst Any. Für Reply Packets matchen Source Network und Incoming Interface in diesem Sonderfall nicht. Zusätzlich braucht der Proxy-Rückweg mindestens ein WAN-Gateway oder eine passende statische Route. Die vollständige Einordnung steht unter SD-WAN Routes einrichten und testen.

In HA sollte man keine unterbrechungsfreie Fortsetzung bestehender Proxy- oder Authentifizierungssitzungen versprechen. Nach einem kontrollierten Failover eine neue Browserverbindung erzeugen, PAC, Rule ID, Policy und Decryption erneut prüfen. Jeder Node speichert die Logs des Traffics, den er selbst verarbeitet hat; bei der Analyse zählt deshalb der zum Ereigniszeitpunkt verarbeitende Node.

Fehler systematisch eingrenzen

Proxyport ist nicht erreichbar

DNS-Antwort, Firewall-Adresse, Listener, Clientzone und Web proxy unter Device Access prüfen. Bei einer ACL Exception müssen Source, Destination host, Service, Action und Position passen. Ein erfolgreicher Ping beweist den TCP-Listener nicht; Test-NetConnection liefert den engeren Vorcheck.

Browser geht direkt ins Internet

Effektive PAC-URL, Inhalt der geladenen Datei, lokale Browserausnahmen und weitere GPO-/MDM-Profile kontrollieren. Ein DIRECT-Fallback nach PROXY erzeugt absichtlich einen Bypass, wenn der Proxy nicht erreichbar ist. Auch Anwendungen mit eigenem Netzwerkstack können System-Proxyvorgaben ignorieren.

Proxy liefert Fehler 407 oder eine Anmeldeabfrage

Das ist ein Authentifizierungsproblem, kein Listenerfehler. Verwendetes Authentifizierungsverfahren, Benutzererkennung, Gruppenimport, Browserunterstützung und gegebenenfalls FQDN/SPN prüfen. Die Regel darf nicht vorsorglich auf Any erweitert werden, nur um die Anmeldeabfrage zu umgehen.

Website lädt, aber die Web Policy greift nicht

Firewallregel, Reihenfolge, Source, Service 3128, ausgewählte Web Policy und Rule ID gemeinsam prüfen. Ein erfolgreicher Proxyrequest kann eine andere oder breitere Regel getroffen haben. Der kontrollierte Regeltest verbindet Policy Test, Log Viewer und Packet Capture.

HTTPS zeigt Zertifikatsfehler

Prüfen, ob Decryption aktiv ist, welche CA der Web Proxy verwendet und ob genau diese CA im Trust Store des Clients liegt. Wenn nur einzelne Anwendungen scheitern, Certificate Pinning, eigenen Trust Store, TLS-Version und eine möglichst enge Ausnahme untersuchen.

Einzelne Anwendung oder Zielport funktioniert nicht

Zuerst klären, ob die Anwendung einen expliziten Proxy unterstützt. Danach Allowed destination ports, PAC-Bypass, DNS und TLS-Verhalten prüfen. Einen nicht standardmässigen Zielport nur für die konkrete Anwendung hinzufügen und mit einem realen Request abnehmen.

SD-WAN Route oder WAN-Pfad ist unerwartet

Service-Match auf den Proxyport, Rule ID, WAN-Gateway, statische Route und Route Precedence prüfen. Source Network und Incoming Interface sind bei Proxy-Reply-Packets keine verlässlichen Match-Kriterien. Kein globales Route-Precedence-Change als Erstlösung durchführen.

Logs fehlen oder zeigen zu wenig

Log firewall traffic in der Regel sowie die lokalen, Central- oder Syslog-Ziele unter System services > Log settings prüfen. Für den Web Proxy ist awarrenhttp.log relevant, für Authentifizierung access_server.log. Die Einordnung und sichere Logsammlung steht in Sophos Firewall Services und Logdateien.

Rollback und Betrieb

Rollback wird vor dem Pilot vorbereitet:

1. Vorherige Proxy-, PAC-, GPO- oder MDM-Einstellung dokumentieren.
2. Pilotregel und Local Service ACL Exception eindeutig benennen.
3. Vorherigen direkten DPI-/Firewallpfad als Rückweg testen.
4. PAC-Zuweisung am Pilotclient entfernen oder auf die vorherige Version setzen.
5. Browser und Anwendungen vollständig neu starten.
6. Pilotregel deaktivieren und einen echten direkten Webfluss über den Rückweg prüfen.
7. Pilot-ACL-Exception entfernen und temporäre breite Web proxy-Zonenfreigaben auf den Vorzustand setzen.
8. Live- und Logdaten kontrollieren und dokumentieren, ab welchem Zeitpunkt kein Proxytraffic mehr erwartet wird.

Im Betrieb erhält die PAC-Datei eine Versionshistorie, einen Owner und ein Review-Datum. Jede neue DIRECT-Ausnahme ist eine Policy-Ausnahme und sollte wie eine Firewall- oder Web-Exception begründet, getestet und später erneut geprüft werden. Listener, erlaubte Zielports und breite Zonenfreigaben gehören ebenfalls in den regelmässigen Review.

Checkliste

• Direct Proxy ist für die betroffenen Browser und Anwendungen das passende Modell.
• IPv4-Pilotclient und feste Source-IP sind dokumentiert.
• Proxy-FQDN, PAC-URL und Zertifikate lösen korrekt auf.
• Listener und erlaubte Zielports sind so eng wie möglich.
• Breite Web-Proxy-Zonenfreigabe wurde geprüft und bei Bedarf ersetzt.
• Local Service ACL Exception begrenzt Source und Firewall-Zieladresse.
• Firewallregel verwendet Proxyport, Logging und die erwartete Web Policy.
• PAC enthält nur begründete interne DIRECT-Ausnahmen.
• Internet-Fallback am Proxy vorbei ist nicht unbemerkt aktiv.
• Erlaubter und blockierter Echttraffic treffen die erwartete Rule ID.
• Lokale HTTP-/HTTPS-Dienste der Firewall wurden negativ getestet.
• Authentication, TLS-Decryption, QUIC und Non-Proxy-Anwendungen wurden getrennt bewertet.
• SD-WAN- und HA-Verhalten sind bei Einsatz dieser Funktionen getestet.
• Rollback, Owner, Versionierung und Review-Datum sind dokumentiert.

Häufige Fragen