Sophos Firewall Upstream Proxy einrichten und testen

Ein Upstream Proxy, auch Parent Proxy genannt, ist die nächste Proxyinstanz hinter der Sophos Firewall. Interne Clients senden ihre Web Requests zuerst an den Web Proxy der Firewall. Die Firewall prüft den Traffic und leitet ihn danach an den übergeordneten Proxy weiter. Erst dieser baut die Verbindung zum Internet auf.

Sophos Firewall unterstützt genau einen Upstream Proxy. Die DPI Engine kann diesen Pfad nicht verwenden. Deshalb müssen die betroffenen Webregeln im Proxy-Modus mit Use web proxy instead of DPI engine arbeiten.

⚠️ Der Parent Proxy ist eine globale Abhängigkeit für Web Requests im Proxy-Modus. Vor dem Aktivieren ein aktuelles Backup, eine unabhängige Adminverbindung, die bestehenden Proxy-Regeln, den ursprünglichen NAT-Pfad und einen getesteten Rückweg dokumentieren. Sophos Firewall bietet keinen zweiten Parent-Proxy-Eintrag als eingebautes Failoverziel.

Dieser Ablauf behandelt weitergeleitete HTTP- und HTTPS-Requests aus internen Netzen. Er behauptet nicht, dass Systemtraffic der Firewall, Firmwareupdates oder Lizenzverbindungen denselben Parent-Proxy-Pfad verwenden.

Upstream Proxy in zehn Schritten

1. Einen verwalteten Pilotclient, einen erlaubten und einen blockierten Web Request festlegen.
2. Entscheiden, ob der Parent Proxy im WAN oder in LAN beziehungsweise DMZ steht.
3. Proxy-IP, Port, optionales Servicekonto, Routing und Rückweg dokumentieren.
4. Den Proxy als IP Host anlegen und seine Erreichbarkeit von der Firewall aus prüfen.
5. Unter Routing > Upstream proxy den Modus Parent proxy auswählen und Adresse, Port sowie optionale Zugangsdaten eintragen.
6. Die Client-Webregel auf Use web proxy instead of DPI engine stellen und Logging aktivieren.
7. Für einen Proxy im WAN eine enge Client-zu-Proxy-Regel erstellen und die wirksame SNAT-Regel prüfen.
8. Für einen Proxy in LAN oder DMZ zusätzlich den Clientpfad per MASQ übersetzen und eine eigene Proxy-zu-WAN-Regel ohne Web Policy und Malware-Scan erstellen.
9. Erlaubten, blockierten und direkten Proxyzugriff mit Firewall Rule ID, NAT Rule ID, Web- und Proxylogs abnehmen.
10. Proxy-Ausfall, HA-Failover und Rollback im Wartungsfenster testen, bevor weitere Netze aufgenommen werden.

Zwei Verbindungen und zwei Topologien verstehen

Der Datenfluss besteht aus zwei getrennten Verbindungen:

1. Der Client sendet einen HTTP- oder HTTPS-Request an beziehungsweise durch den Web Proxy der Sophos Firewall.
2. Die Sophos Firewall erzeugt daraus die Verbindung zum Parent Proxy. Dieser sendet den Request weiter ins Internet.

Ein Browser muss deshalb nicht direkt auf den Parent Proxy zeigen. Bei einem expliziten Direct Web Proxy mit PAC-Datei bleibt die Sophos Firewall das Proxyziel des Clients. Der Parent Proxy ist der nächste Hop hinter der Firewall.

Parent Proxy im WAN

Steht der Parent Proxy im WAN, braucht der Datenpfad neben der Web-Proxy-Regel eine Firewallregel von den internen Clientnetzen zum konkreten Proxyhost und Proxyport. Private Quelladressen werden normalerweise durch die bestehende Default SNAT IPv4-Regel maskiert. Eine eigene SNAT-Regel ist nur nötig, wenn dieser Pfad eine andere Source Translation erhalten soll.

Parent Proxy in LAN oder DMZ

Steht der Parent Proxy in LAN oder DMZ, bleibt sein Internetpfad hinter der Sophos Firewall. Dann sind drei zusätzliche Bausteine nötig:

• eine Client-zu-Proxy-Firewallregel,
• eine enge MASQ-SNAT-Regel für genau diesen Pfad,
• eine Proxy-zu-WAN-Regel ohne Web Policy und ohne erneuten Malware- oder Content-Scan.

Die Proxy-zu-WAN-Regel steht oberhalb überlappender Regeln im Web-Proxy-Modus. Sonst kann der vom Parent Proxy erzeugte Traffic erneut in den Proxyweg geraten oder anders als geplant geprüft werden.

Beispiel und austauschbare Werte

Der Artikel verwendet zwei Alternativen:

• Pilotclient: CLIENT-WEB-01
• feste Client-IP: 10.20.30.50
• Clientnetz: 10.20.30.0/24
• Clientzone: LAN
• Webregel: LAN_Web_ParentProxy_Pilot
• Parent-Proxy-Port: 3128
• WAN-Proxy: PARENT-WAN_192.0.2.80
• WAN-Proxy-IP: 192.0.2.80
• DMZ-Proxy: PARENT-DMZ_10.20.40.20
• DMZ-Proxy-IP: 10.20.40.20
• DMZ-Zone: DMZ
• optionales Proxykonto: svc_sfos_parent_proxy

192.0.2.80 ist eine Dokumentationsadresse und wird durch die echte öffentliche oder providerseitige IP des Upstream Proxys ersetzt. 10.20.40.20 steht für einen internen Proxy in einer eigenen DMZ. Die gewählte Adresse muss aus Sicht der Sophos Firewall über den vorgesehenen Pfad erreichbar sein.

Sophos erlaubt eine IPv4-Adresse, IPv6-Adresse oder einen Domainnamen. Für einen kontrollierbaren Datenpfad wird die IP-Adresse bevorzugt: Sophos empfiehlt sie, damit Clients den Web Proxy der Firewall nicht einfach durch direkten Zugriff auf den Upstream Proxy umgehen. Ein Domainname ist kein belegter zweiter Proxy- oder Failovermechanismus.

Port 3128 ist ein häufig verwendeter Proxyport, aber kein unveränderlicher Produktwert. Wenn der Parent Proxy einen anderen Listener nutzt, müssen Host-/Serviceobjekt, Firewallregeln, Packet Capture, Monitoring und Tests denselben Port verwenden.

Das optionale Konto wird nur eingesetzt, wenn der Parent Proxy Authentisierung verlangt. Dafür ein dediziertes, möglichst eingeschränktes Servicekonto verwenden, Passwortrotation und Owner dokumentieren und keine persönlichen Adminkonten hinterlegen.

Parent Proxy global eintragen

Vor der Änderung muss die Firewall den Proxy über Routing und Firewallpfad erreichen können. Ein TCP-Porttest allein beweist noch keine funktionierende Proxy-Authentisierung oder HTTP-Weiterleitung.

1. Unter Hosts and services > IP host den konkreten Proxyhost anlegen.
2. Unter Routing > Upstream proxy Parent proxy auswählen.
3. IP-Adresse oder Domainname des Parent Proxys eintragen. Für diesen Ablauf die bestätigte IP verwenden.
4. Den tatsächlichen Proxyport eintragen, im Beispiel 3128.
5. Benutzername und Passwort nur bei erforderlicher Proxy-Authentisierung hinterlegen.
6. Mit Apply speichern.

Diese Einstellung wirkt nicht wie eine einzelne Firewallregel nur für den Piloten. Der Pilot wird über enge Regeln und deren Reihenfolge begrenzt. Vor dem Speichern deshalb alle bestehenden Regeln erfassen, die bereits Use web proxy instead of DPI engine verwenden.

Webregel in den Proxy-Modus setzen

Die Webregel vom internen Netz zum WAN bindet Web Policy und Scanning an den ersten Teil des Datenflusses. Die allgemeine Regelmechanik erklärt Firewallregeln auf Sophos Firewall.

Für den Piloten wird eine eigene Regel erstellt oder eine vorhandene Pilotregel eng angepasst:

• Source zones: LAN
• Source networks and devices: CLIENT-WEB-01 oder das bestätigte Pilotnetz
• Destination zones: WAN
• Destination networks: nur die vorgesehenen Webziele oder bewusst Any
• Services: die benötigten HTTP-/HTTPS-Dienste
• Web policy: die vorbereitete Pilotpolicy
• Scan HTTP and decrypted HTTPS: nur wenn der geplante Schutz dies verlangt
• Use web proxy instead of DPI engine: aktiviert
• Log firewall traffic: aktiviert

Wie Kategorien, Ausnahmen und echte erlaubte sowie blockierte Ziele abgenommen werden, erklärt Web Protection auf Sophos Firewall.

Der Parent Proxy funktioniert nicht mit der DPI Engine. Ein grüner Regelstatus beweist den tatsächlichen Pfad nicht. Nach dem Speichern muss der Testrequest die erwartete Firewall Rule ID und Web Policy zeigen.

HTTPS-Decryption ist eine eigene Entscheidung. Wenn sowohl Sophos Firewall als auch Parent Proxy TLS entschlüsseln, muss klar sein, welche Instanz welches Zertifikat ausstellt und wo ein Fehler entsteht. Der kontrollierte TLS-Inspection-Rollout bleibt dafür der Detailablauf.

Parent Proxy im WAN anbinden

Für einen Proxy im WAN wird zusätzlich eine Regel erstellt, die den Proxyhop ausdrücklich erlaubt:

• Name: LAN_to_PARENT-WAN_3128
• Source zones: LAN
• Source networks and devices: 10.20.30.0/24 oder enger der Pilot
• Destination zones: WAN
• Destination networks: PARENT-WAN_192.0.2.80
• Services: eigener TCP-Service für 3128
• Log firewall traffic: aktiviert

Die Regel darf nicht als breite allgemeine LAN-zu-WAN-Freigabe enden. Proxyhost und Proxyport bleiben konkret. Nach dem Test wird anhand der Firewall Rule ID geprüft, dass genau diese Regel trifft.

Private Clientadressen werden in einer Standardkonfiguration häufig durch Default SNAT IPv4 maskiert. Im Log Viewer und Packet Capture muss dennoch die wirksame NAT Rule ID kontrolliert werden. Eine neue SNAT-Regel ist nur sinnvoll, wenn der Providerproxy eine bestimmte Quelladresse verlangt oder der vorhandene NAT-Pfad nicht passt. Die Grundlogik erklärt NAT auf Sophos Firewall.

Parent Proxy in LAN oder DMZ anbinden

Bei einem Proxy in LAN oder DMZ muss sein eigener Internetverkehr vom Client-zu-Proxy-Pfad getrennt bleiben.

Client-zu-Proxy-Regel erstellen

Die erste Regel erlaubt nur den bestätigten Clientpfad:

• Name: LAN_to_PARENT-DMZ_3128
• Source zones: LAN
• Source networks and devices: 10.20.30.0/24 oder enger der Pilot
• Destination zones: DMZ
• Destination networks: PARENT-DMZ_10.20.40.20
• Services: eigener TCP-Service für 3128
• Log firewall traffic: aktiviert

Steht der Proxy in LAN, wird dessen tatsächliche Zone verwendet. Any ist für den produktiven Avanet-Ablauf weder als Source noch als Destination nötig.

SNAT nur für diesen Pfad erstellen

Unter Rules and policies > NAT rules wird eine enge Source-NAT-Regel angelegt:

• Original source: 10.20.30.0/24 oder enger der Pilot
• Translated source (SNAT): MASQ
• Original destination: PARENT-DMZ_10.20.40.20
• Translated destination (DNAT): Original
• Original service: TCP 3128
• Inbound interface: das bestätigte Clientinterface oder bewusst Any
• Outbound interface: das Interface zum Proxy oder bewusst Any

Interfacefelder werden nur gesetzt, wenn der reale Pfad stabil ist. Ein falsches Interface verhindert den Match. Die Regel wird über die erwartete NAT Rule ID abgenommen und nicht allein anhand ihrer Position.

Proxy-zu-WAN-Regel ohne erneute Webprüfung erstellen

Der Parent Proxy braucht eine eigene Regel für seine Internetverbindungen:

• Name: PARENT-DMZ_to_WAN
• Source zones: DMZ
• Source networks and devices: PARENT-DMZ_10.20.40.20
• Destination zones: WAN
• Destination networks: die benötigten Ziele oder bewusst Any
• Web policy: None
• Malware and content scanning: deaktiviert
• Log firewall traffic: aktiviert

Diese Regel wird oberhalb anderer Regeln platziert, die mit derselben Source-/Destination-Kombination im Web-Proxy-Modus treffen könnten. Eine IPS Policy kann bewusst eingesetzt werden, wenn der Betrieb sie für den Proxy-zu-WAN-Pfad verlangt. Web Policy und Malwareprüfung werden hier nicht ein zweites Mal angewendet.

Für den WAN-Hop des Parent Proxys gilt wieder die tatsächlich treffende SNAT-Regel. Die Default SNAT IPv4 kann ausreichen; die NAT Rule ID entscheidet.

Datenpfad kontrolliert abnehmen

Ein erfolgreicher Test bestätigt nicht nur, dass irgendeine Webseite öffnet. Er verbindet Client, Regel, NAT, Web Policy und Parent Proxy zu einer gemeinsamen Zeitlinie.

1. Zeitpunkt mit Zeitzone, Pilot-IP, Ziel-URL und erwartete Aktion notieren.
2. Eine erlaubte HTTP- oder HTTPS-Seite öffnen.
3. Eine Kategorie oder Test-URL öffnen, welche die Pilot-Web-Policy blockieren soll.
4. Im Log Viewer die erwartete Firewall Rule ID, NAT Rule ID, Web Policy, Aktion sowie Source und Destination prüfen.
5. Im Logging oder Monitoring des Parent Proxys bestätigen, dass beide Requests von der erwarteten Sophos-/NAT-Source eintreffen.
6. Im Built-in Packet Capture mit host 192.0.2.80 and port 3128 beziehungsweise der echten Proxy-IP den Hin- und Rückweg prüfen.
7. Vom Pilotclient einen direkten Zugriff auf Proxy-IP und Proxyport testen. Bei einer als IP eingetragenen Parent-Proxy-Adresse muss die Sophos-Policy auch für diesen Weg greifen; ein ungeprüfter Bypass ist eine Stop-Bedingung.
8. Parent Proxy kontrolliert unerreichbar machen oder den Testport im Wartungsfenster sperren. Das beobachtete Fehlerverhalten und die Alarmierung dokumentieren, ohne einen automatischen zweiten Proxy anzunehmen.

Der Test gilt erst als bestanden, wenn erlaubter und blockierter Request korrekt sind, der Parent Proxy beide sieht und der direkte Zugriff die Sicherheitsvorgabe nicht umgeht. Firewallregel systematisch testen erklärt die Rule-ID- und Packet-Capture-Abnahme im Detail.

HA getrennt prüfen

In Active-Active kann Sophos Parent-Proxy-TCP-Traffic zwischen den Nodes verteilen. Jeder Node speichert jedoch nur die Logs für den Traffic, den er verarbeitet hat. Deshalb bei der Fehlersuche beide Nodes beziehungsweise den zum Ereigniszeitpunkt verarbeitenden Node berücksichtigen.

Ein kontrollierter Failover wird mit einer neuen Browserverbindung wiederholt. Danach Firewall Rule ID, NAT Rule ID, Parent-Proxy-Log und erlaubte sowie blockierte Aktion erneut prüfen. Keine unterbrechungsfreie Fortsetzung einer bereits laufenden Proxyverbindung voraussetzen.

Fehler systematisch eingrenzen

Webseiten öffnen direkt, aber nicht über den Parent Proxy

• Prüfen, ob die Client-Webregel Use web proxy instead of DPI engine verwendet.
• Die tatsächliche Firewall Rule ID und Regelreihenfolge kontrollieren.
• Route, Proxy-IP, Port, NAT Rule ID und Rückweg prüfen.
• Bei Authentisierung Benutzername, Passwort, Sperrstatus und das Protokoll des Parent Proxys abgleichen.
• Ein offener TCP-Port beweist weder einen erfolgreichen Proxyrequest noch eine gültige Authentisierung.

Der Parent Proxy antwortet mit 407 oder einer Authentisierungsfehlermeldung

Zugangsdaten und Kontostatus am Parent Proxy prüfen. Persönliche Adminzugänge nicht als schnelle Umgehung hinterlegen. Nach einer Passwortänderung den globalen Eintrag kontrolliert aktualisieren, eine neue Verbindung testen und den alten Secretzugriff entziehen.

Ein Proxy in LAN oder DMZ erreicht das Internet nicht

• Client-zu-Proxy-Regel und deren Rule ID prüfen.
• Die enge MASQ-Regel und NAT Rule ID kontrollieren.
• Proxy-zu-WAN-Regel, Position und tatsächliche Proxy-Source prüfen.
• Sicherstellen, dass Web policy auf None steht und Malware-/Content-Scanning nicht erneut aktiviert ist.
• Route und SNAT für den WAN-Hop des Parent Proxys getrennt prüfen.

Die Web Policy trifft doppelt oder der Datenfluss läuft im Kreis

Die Proxy-zu-WAN-Regel muss vor überlappenden Regeln im Web-Proxy-Modus stehen. Source, Destination, Service und Rule ID jedes Hops vergleichen. In awarrenhttp.log, fwlog.log, firewall_rule.log und nat_rule.log nach derselben Zeit, Client-IP, Proxy-IP und Zieladresse suchen. Die Zuordnung der Dateien erklärt Sophos Firewall Service-Logs.

Keine Proxydienste neu starten und keine Debugausgabe dauerhaft aktivieren. Zuerst Log Viewer, Packet Capture und die vorhandenen Logdateien sichern. awarrenhttp_access.log enthält detaillierte Einzelrequests nur bei aktiviertem Debug und ist deshalb kein Standardbeweis für jeden Incident.

HTTPS zeigt unerwartete Zertifikate oder Zertifikatsfehler

Feststellen, ob Sophos Firewall, Parent Proxy oder beide TLS entschlüsseln. Das Ausstellerzertifikat im Browser, die treffende Web Policy, SSL/TLS-Inspection-Regel und das Upstream-Proxy-Log vergleichen. Nicht gleichzeitig CA-Verteilung, Decryption und Parent-Proxy-Regeln auf Verdacht ändern.

Nur einzelne Anwendungen umgehen den Proxy

Nicht jede Anwendung verwendet Browser- oder Betriebssystem-Proxyeinstellungen. Der Parent Proxy ist kein allgemeiner Tunnel für beliebigen TCP-/UDP-Traffic. Für die betroffene Anwendung den tatsächlichen Datenpfad und die treffende Firewallregel erfassen, statt aus einem erfolgreichen Browsertest auf alle Programme zu schliessen.

Betrieb und Rollback

Der einzelne Parent Proxy ist eine dokumentierte Abhängigkeit. Monitoring sollte nicht nur den TCP-Port prüfen, sondern einen echten HTTP-/HTTPS-Request, Authentisierung, Latenz und die erwartete Upstream-Antwort. Owner, Wartungsfenster, Secretablauf und Wiederherstellungsweg gehören in die Betriebsdokumentation.

Für einen Rollback:

1. Zeit, Konfiguration, Rule IDs und NAT Rule IDs vor der Änderung sichern.
2. Unter Routing > Upstream proxy den dokumentierten Vorzustand wiederherstellen.
3. Die Client-Webregel auf ihren vorherigen DPI- oder Proxy-Modus zurücksetzen.
4. Temporäre Client-zu-Proxy-, Proxy-zu-WAN- und SNAT-Regeln erst nach bestätigtem Ersatzpfad deaktivieren.
5. Eine neue Browser-/Anwendungsverbindung öffnen und erlaubten sowie blockierten Request erneut testen.
6. In HA den Test für den aktuellen verarbeitenden Node und nach einem geplanten Failover wiederholen.
7. Nicht mehr benötigte Proxyzugänge und Secrets erst nach erfolgreicher Abnahme entfernen.

Checkliste

• Ein aktuelles Backup, unabhängige Adminverbindung und der Vorzustand sind dokumentiert.
• Proxyposition WAN, LAN oder DMZ, IP, Port, Routing und Rückweg sind bestätigt.
• Der Parent Proxy ist als IP eingetragen oder die FQDN-Entscheidung ist begründet.
• Die Client-Webregel verwendet Use web proxy instead of DPI engine.
• Client-zu-Proxy-Regel, Firewall Rule ID und Proxyport stimmen.
• Für LAN/DMZ sind enge MASQ-SNAT- und Proxy-zu-WAN-Regeln vorhanden.
• Die Proxy-zu-WAN-Regel hat Web Policy None und keine erneute Malwareprüfung.
• Erlaubter, blockierter und direkter Proxyzugriff wurden geprüft.
• Parent-Proxy-Ausfall, Alarmierung, HA-Failover und Rollback wurden getestet.
• Owner, Secretrotation, Monitoring und Review-Datum sind dokumentiert.

Häufige Fragen