Nicht vorhandene Regeln werden angewandt

So, du weißt wie du automatisch vom system gesetzte FW Regeln anzeigen lassen kannst?:

Zurück zum Webfilter:

Fehler: failed to resolve passthrough6.fw-notify.net

Du/ihr habt wahrscheinlich einen internen Windows DNS-Server, hier musst du noch einen statischen DNS Eintrag setzen:

Ansonsten musst du dann auch noch im Webfilter Ausnahmen für das Quellnetzwerk  als auch für das Zielnetzwerk setzen, damit jene nicht gewünschte Netzwerke ausgeschlossen werden.

Gruß, Jonas

Hi Jonas,

Ja, das ist mir klar, aber wie gesagt, die regeln stimmen nicht überein. Oder existieren erst gar nicht.

Dein Screenshot bezieht sich auf das Enduserportal, mit welchen wir keine Probleme haben. Wir betreiben den Proxy auch vorerst nur mit URL-Filtering, also kein Webproxy Zertifikat.

Zum Webfilter:

Wir haben keinen internen Windows DNS-Server. Wir haben ein Forwarding für die Domain zum DC am Hauptstandort.

Bzgl. der Ausnahme: Was meinst du genau mit Ausnahme im Webfilter?

Wir haben entsprechende Exceptions für die Windows Server erstellt. Es läuft auch "angeblich" alles durch laut dem Web Proxy (wenn er gerade nicht ständig Neustart).

Grüße,

Mocho

Naja, ob ihr das Enduserportal nutzt oder nicht, laut Webfilterprotokoll wird ja (durch andere Sophos Dienste?) versucht, fw-notify aufzurufen. "failed to resolve passthrough6.fw-notify.net".  Auf jeden Fall nicht falsch, wenn man dies schon mal konfiguriert, spart man sich auch die zukünftige Arbeit wenn man auf SSL-Entschlüsselung umstellt (was ich euch auch dringend empfehle da https heutzutage standard ist und man nur so gefährliche Inhalte sperren kann).

Ihr nutzt ja den transparenten Webproxy, deswegen müsst ihr auch am Client keinen Proxy oder WPAD konfigurieren.

Du musst prüfen, bei welchem Umstand der Client an den Webproxy erfasst wird. Am besten mit einem Einzelclient testen. Eventuell sogar mit einem neuen Netzwerk an einer neuen Sophos NIC und dann dieses Netzwerk auswerten.

Der DC am Hauptstandort fungiert aber als DNS-Server auch für die Zweigstelle?

Wie wärs, wenn die Zweigstelle einen eigenen DNS-Server hat oder einen eigenen WAN Breakout, nur DNS-Domänenanfragen von den DNS-Anfragen werden durchs IPSEC an den Haupt-DC-DNS Server im Headquarter geschleust (DNS-Anfrageroute).

Also,

Wir haben mit Absicht KEIN SSL-Scan aktiv. Da wir hier ja troubleshooten ;)

Wenn der Wbproxy melden "failed to resolve passthrough6.fw-notify.net" heißt das für mich, das genau dieser, die Meldung nicht aufrufen kann (nicht die Clients). 

Ich denke eher das in der Resolv.conf vom Linux ein Problem besteht.

Webproxy ist wie oben beschrieben auch nicht konfiguriert.

Der Webproxy wird Immer verwendet (zumindest wenn wir surfen) alle Logs der aufgerufenen Seiten werden angezeigt.

Da die Firewall nicht in unmittelbarer nähe steht, ist das nicht möglich. (wäre für mich auch zu aufwändig, da ist neuaufsetzen schneller getan). 

Ich vermute hier eher wie gesagt ein Problem beim Linux drunter oder der Datenbank.

Die Ausnahmen greifen nicht.

Der DNS am Hauptstandort dient NUR zur Auflösung der domain bezogenen Geräte:

Domain.local -> DNS-Haupstandort.

Für das auflösen von öfftl. Adressen ist die Sophos zuständig mit einer weiterleitung an die 2 bekannten Google DNS Server 8.8.8.8 und 8.8.4.4.  Aber wir haben hier gar kein DNs Problem.

Und wie oben beschrieben, das die zweigstelle einen eigenen brakeout! 

Und vielleicht nochmal zur Info, ich habe bereits über 10 Jahre Erfahrung mit der SG. Wir betreuen ja auch mehr als 80 SGs.

Es handelt sich hier nicht um ein 0815 konfig Problem ;)

Lg

wenn du einen Fehler in einer Linuxdatei oder DB vermutest, mach ein Backup und installiere die FW dann neu.

Spiele das Backup wieder ein und wenn es läuft, hast du Recht gehabt mit einer defekten Linuxdatei, wenn nicht, liegt doch ein Konfigurationsfehler vor ;-)

Gruß, Jonas

Ich habs vermutet

ich hatte gehofft das schonmal jemand diesen Fehler hatte und ich nicht extra zum Kunden fliegen muss umd den hobel neu aufzusetzen :/

Mir kommt es so vor, als wären noch einige NAT und FW Regeln aktiv, welche aber in der Gui nicht angezeigt werden (würde auch mit meinem Wireshark mitschnitt übereinstimmen). Im log werden diese dann erst sichtbar, wenn ich eine Regel mit der gleichen Regel-Nr. erstelle.

Ich werde das Backup bei Zeiten einmal auf eine appliance bei uns einspielen und mit Wireshark prüfen wie hier die Pakete verlaufen.

Lg

Ich habs vermutet

ich hatte gehofft das schonmal jemand diesen Fehler hatte und ich nicht extra zum Kunden fliegen muss umd den hobel neu aufzusetzen :/

Mir kommt es so vor, als wären noch einige NAT und FW Regeln aktiv, welche aber in der Gui nicht angezeigt werden (würde auch mit meinem Wireshark mitschnitt übereinstimmen). Im log werden diese dann erst sichtbar, wenn ich eine Regel mit der gleichen Regel-Nr. erstelle.

Ich werde das Backup bei Zeiten einmal auf eine appliance bei uns einspielen und mit Wireshark prüfen wie hier die Pakete verlaufen.

Lg

würde weiterhin auf die Konfiguration den Schwerpunkt setzen. Dass zb. die Proxys Regeln oder dergleichen "überlagern" können, ist dir ja bestimmt bekannt. Wie schauts denn auf den Clients aus, dort draufschalten und eine Fehleranalyse machen? 

Du schreibst weiterhin:

"Webproxy ist wie oben beschrieben auch nicht konfiguriert."

vs

"Der Webproxy wird Immer verwendet (zumindest wenn wir surfen)"

was denn jetzt, konfiguriert oder nicht?

Stimmt das habe ich etwas missverständlich formuliert.

Auf den Clients ist kein Proxy konfiguriert.

Im log der SG [Web Protection) sehe ich alle anfragen der Clients. Selbst dann  wenn das Netzwerk nicht unter den zugelassenen Netzwerken gelistet ist und eine Http/s FW Regel hat.

okay, schauen wir uns die Webprotection näher an:

Was sagt der Richtlinientest? Bitte eine Webseite angeben und dann die IP eines betroffenen Clients.

Was wird dir ausgegeben, bzw. wird dir ein Filterprofil (das vom Vorgänger "angefasste Baseprofil" ?) in diesem Test angezeigt?

Bei dem Rcihtlinientest ist alles Grün und der Client langet in der richtigen Policy (sowohl im Rcihtlinientest, als auch im Log)

dann nimm den Client mal raus als Netzwerkausnahme unter erweitert bei beiden webfiltern (beide fws), dann schritt für Schritt weiterarbeiten damit wir erstmal einen Stand haben, welcher Webfilter sich den client greift.

Bereits erledigt, der Client landet dennoch in der policy. Als ob er nicht in der Ausnahme wäre...

bitte einmal ein Screenshot von Transparenzmodus-Ausnahmen machen, da wo der Client drin ist als Ausnahme.

Dann, nutzt ihr "nur" den Webfilter oder auch Webfilterprofile?

Wir nutzen nur den Webfilter

Mach mal den Haken weg bei -->  HTTP-Verkehr für aufgeführte Hosts/Netze zulassen ;-)

Keine änderung