Proxybetrieb an nur einer Schnittstelle möglich?

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Proxybetrieb an nur einer Schnittstelle möglich?

Beitrag von isential gmbh »

Wie ich gestern bereits unter eth2 für Testnetzwerk parallel zu eth1 verwenden beschrieb, betreibe an eth2 ein logisch und physikalisch von meinem Firmennetz getrenntes Netzwerk zu Testzwecken.

Unser Firmennetzwerk hängt an eth1 und der gesamte Datenverkehr wird über den HTTP-Proxy (Port 8080) erzwungen (KEIN transparenter Modus). Authentifizierungsmethode ist dabei NTLM (Active-Directory). Wir haben umfangreiche Authentifizierungsausnahmen, Webseiten-Whitelisten (für den Virenscanner) und Regelsätze für den Webfilter eingerichtet. Damit funktioniert alles, was wir brauchen (Windows-, Visual-Studio-, Office- und Virenscanner-Updates, Downloads usw.).

Damit niemand auf die Idee kommt, den Proxy zu umgehen, habe ich Portregeln erstellt, die http und https blocken, wenn diese nicht vorher vom Proxy blockiert wurden. Das sieht man im nächsten Bild im grünen Teil:

Bild mit Portregeln

Das gelbe Teil zeigt die dafür notwendigen Portregeln. Diese gelten für eth1 und die Zone internal.

Das grüne Teil gilt für eth2 und die Zone internal-eth2.

Anmerkung 1:
Analog zu den von eth1 verwendeten Zonen habe ich für eth2 Zonen erstellt und verwendet. Diese haben alle den Suffix "-eth2".

Frage 1:
Nun ist es mir nicht gelungen, eth2 ohne Proxy zu verwenden. Wie es aussieht, gilt der Proxy systemweit – ist das richtig?

Ich musste deswegen im grünen Teil die erste Zeile mit dem Proxy einfügen, damit das an eth2 hängende Netz ins Internet kann. Ich hätte es für diese Schnittstelle aber gerne ganz ohne Proxy.

Anmerkung 2:
Wie weiter oben erwähnt, habe ich alle Einstellungen für eth2 von eth1 dupliziert und entsprechend adaptiert (z. B. bei den neuen Zonen eth2 anstelle von eth1 verwendet). Ich habe penibel darauf geschaut, alle möglichen Einstellungen in der Firewall so zu treffen, dass diese den für eth1 entsprechen. Hier ein Beispiel aus der Netzwerkkonfiguration:

eth1:
internal
firewall-internal
internal_v6
firewall-internal_v6

eth2:
internal-eth2
firewall-internal-eth2
internal-eth2-v6
firewall-internal-eth2-v6

eth0:
external
firewall-external
external_v6
firewall-external_v6
external-eth2
firewall-external-eth2
external-eth2-v6
firewall-external-eth2-v6

Auch die Netzwerkobjekte für eth2 habe ich entsprechend angelegt und verwendet – alles von eth1 quasi  gespiegelt.

Nun kann ich vom am eth2 angeschlossenen Netz das Internet erreichen, allerdings stelle ich fest, dass einige Sachen bisher nicht gehen. DNS-Auflösung funktioniert, das Surfen funktioniert, aber ein ping/tracert auf ins Internet geht nicht. Die MIcrosoft-Updates finden z. B. Updates, diese werden aber nicht heruntergeladen – im Ereignisprotokoll finde ich folgende Einträge:

Code: Alles auswählen

Protokollname: Application
Quelle:        Windows Error Reporting
Datum:         06.12.2017 10:06:39
Ereignis-ID:   1001
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      SRV-VHOST.test.local
Beschreibung:
Fehlerbucket , Typ 0
Ereignisname: ScriptedDiagFailure
Antwort: Nicht verfügbar
CAB-Datei-ID: 0

Problemsignatur:
P1: Microsoft Windows.NetworkDiagnostics.4.0
P2: 3558064791
P3: 1.0.0.0
P4: Default
P5: 
P6: 
P7: 
P8: 
P9: 
P10:
und

Code: Alles auswählen

Protokollname: Application
Quelle:        Windows Error Reporting
Datum:         06.12.2017 10:09:06
Ereignis-ID:   1001
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      SRV-VHOST.test.local
Beschreibung:
Fehlerbucket , Typ 0
Ereignisname: WindowsUpdateFailure3
Antwort: Nicht verfügbar
CAB-Datei-ID: 0

Problemsignatur:
P1: 10.0.14393.1914
P2: 80240438
P3: 00000000-0000-0000-0000-000000000000
P4: Scan
P5: 0
P6: 0
P7: 0
P8: Windows Defender (77BDAF73-B396-481F-9042-AD358843EC24)
P9: {9482F4B4-E343-43B6-B170-9A65BC822C77}
P10: 0
Ich habe für jede Portregel das Logging eingeschaltet, das Firewall-Protokoll zeigt jedoch keinerlei Merkwürdigkeiten an – keine Drops, kein Access denied, kein rein gar nichts. Hängt das Netz direkt am Internet (ohne UTM-Firewall) funktioniert alles prima.

Frage 2:
Woran kann das liegen? Wie kann ich den Verursacher finden, wenn das Protokoll nichts auffälliges zeigt?

Im Voraus herzlichen dank für die Hilfe!

Liebe Grüße

René

Petasch
Beiträge: 449
Registriert: Di 22.05.2007, 13:17

Beitrag von Petasch »

also prinzipiell ist ihr Vorhaben natürlich kein Problem (und denke ich auch gängig, Gastnetzwerke usw. lass ich nie durch den Proxy laufen)....

Also erstmal,
wofür haben Sie diese Zonen eingerichtet:
external-eth2
firewall-external-eth2
external-eth2-v6
firewall-external-eth2-v6
??

Desweiteren kann natürlich die Proxy Regel für internal-network-eth2 raus.
Überhaupt haben sie ganz viele merkwürdige Regeln bei sich.

dmz1-interface auf dmz1-interface - administration?!?!?!
all-internal auf all-internal - any ???
all-internal-eth2 auf all-internal-eth2 - any ???

was verbirgt sich hinter diesen all-internal objekten? 
Vermutlich wäre es erstmal sinnvoll eines Screenshots von der NEtzwerkkonfiguration und den entsprechenden Zonen

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Dank dem Support funktioniert das jetzt. Die vielen Regeln im oberen Teil sind OK, da wir im Netz http und https nur und ausschließlich über den Proxy mit Authentifizierung erlauben wollen. Die Ausnahmen sind für Dienste, die ohne Authentifizierung trotzdem über http oder https raus müssen (Windows-Updates, Visual-Studio-Updates usw.).

Die Zonen hatte ich analog zu den von eth1 angelegt und eingerichtet. Viel Arbeit, da dies ziemlich viele Bereiche betrifft und hier habe ich irgendwo etwas falsch gemacht oder übersehen. Nun hat der Support sich per TeamViewer alles angeschaut und radikal vereinfacht. Die eth2-Zonen wurden entfernt und dafür die Standardzonen für dmz verwendet. Im gleichen Zuge hat man alles rausgeschmissen, was nicht verwendet wurde und nur "auf Verdacht" eingerichtet war (z. B. ipv6-Unterstützung). Ich habe auch durch Gruppierung einige Portregeln vereinfacht und nun sieht das vernünftiger aus und vor allem, es funktioniert zu 100% :D:

Bild mit neuen Bildregeln

An dieser Stelle möchte ich mich beim Support erneut bedanken!

Ein Schönes Wochenende!

René

Petasch
Beiträge: 449
Registriert: Di 22.05.2007, 13:17

Beitrag von Petasch »

Naja kein Hexenwerk ,
Die Regeln die ich agesprochen hatte, die keinen Sinn gemacht haben können, wurden ja scheinbar auch entfernt. Wie auch immer , schön wenn es jetzt funktioniert . Lg

Antworten