Hallo,
wir haben zwei RC300 UTM im Clusterverbund. (UTM v11.7.8 )
In der Zone "internal" ist normalerweise ja der Zugriff auf die Adminoberfläche mit https und Port 11115 immer erlaubt.
"Leider" ist diese Zone unsere ganz normale Bürowelt und nicht unser Admin VLAN.
Bevor ich irgendwie versuche den Zugang im Büro LAN zu blocken wollte ich erstmal nachsehen ob ich aus dem Admin VLAN auf die Schnittstellen komme. Und da setzt meine Frage an:
Im Clusterbetrieb ist es so aufgebaut:
192.168.200.1 = Default gateway = Betriebmachenede Firewall
192.168.200.2 = "Echte" IP Adresse der Firewall Nr 1 die Betrieb macht
192.168.200.3 = "Echte" IP Adresse der Firewall Nr 2 die Standby ist.
Ich habe eine Policy, die aus dem ADMIN LAN (192.168.200.0/24) den Zugriff auf das Interface mit den entsprechenden Ports (11115 und 4430) erlaubt.
Die IP 192.168.200.1 kann ich aufrufen.
Die IP 192.168.200.2 auch (es ist ja die gleiche Firewall die zur Zeit als 192.168.200.1 arbeitet)
Die IP 192.168.200.3 kann ich nicht aufrufen.
(Ich bin kein Securepoint Experte daher kann es sein dass ich manche Begriffe nicht 100%ig richtig gewählt habe. HSRP und VRRP sind mir grundsätzlich aber bekannt.)
Die Clusterkonfig ist synchronisiert sodass beide den gleiche Stand haben.
Wenn ich eine Policy mache mit dem Firewall-Interface als Ziel, bezieht sich dass dann nur die auf "betriebmachende" IP ? Dann dürfte die 192.168.200.2 allerdings nicht aufrufbar sein finde ich.
Wie müssen die Portfiilter richtig ausehen um den Zugriff auf alle Interfaces der Firewalls aus dem einen Netz zu erlauben?
Zwei RC300 im Cluster: Admin Zugang (https:11115) auf "interface" erlauben auf beide Firewalls
Moderator: Securepoint
Hallo,
Netzwerk -> Servereinstellungen -> Administration -> Hinzufügen -> 192.168.x.x/24 -> Speichern -> Profit
Danach aus dem 192.168.x.x Netz auf die Firewalls zugreifen und können dann die Zonen umschwenken.
Gruß
Netzwerk -> Servereinstellungen -> Administration -> Hinzufügen -> 192.168.x.x/24 -> Speichern -> Profit
Danach aus dem 192.168.x.x Netz auf die Firewalls zugreifen und können dann die Zonen umschwenken.
Gruß
Das ist ja interessant. Bzw auch ein bisschen kompliziert.
Also die Zone "internal" hat automatisch Zugriff und in den Servereinstellungen kann ich noch unabhängig von der Zone einen Adressbereich eingeben?
Mit diesem Adressbereich ist es dann also egal aus welcher Zone und damit von welcher Schnittstelle (eth0-eth...) man kommt?
Und "Problem" dabei ist, dass wir Geräte (wie zB Switche, die Firewall oÄ) zum Konfigurieren zwar im besagten ADMIN VLAN haben, unsere Computer mit denen wir damit arbeiten aber im anderen Netz sind und das ganze deswegen mit einer Firewall Policy geregelt werden sollte.(die UTM dient also auch als Router um die Verbindung herzustellen)
Ich habe entsprechende Netzwerkobjekte erstellt mit den PCs der Leute die Adminzugänge haben sollen (aus dem lokalen Netz und auch via VPN). Die habe ich alle in eine Objektgruppe gepackt und dann damit Portfilter gemacht um den Zugriff zu gewähren. Jezt diese ganzen IP Adressen der Objekte da an dieser Stelle noch mal einzutragen kommt mir komisch vor.
Wenn ich die Zonen "tausche", reicht es sie entsprechend umzubenennen? Muss ich überhaupt den Namen "internal" verwenden? Wenn ich mit der Einstellung eh einen Adressbereich bestimmte kann ich die Zonen nicht benennen wie ich möchte?
Evtl habe ich die Securepoint Philisophie noch nicht ganz verinnerlicht aber die Namen der Zonen mit "dmz..." finde ich nicht hilfreich, ich habe da lieber die Schnittstelle "eth..." oder evtl andere Informationen (Vlan name oÄ) im Namen um nicht noch mehr neue Zählweisen anzufangen.
Also die Zone "internal" hat automatisch Zugriff und in den Servereinstellungen kann ich noch unabhängig von der Zone einen Adressbereich eingeben?
Mit diesem Adressbereich ist es dann also egal aus welcher Zone und damit von welcher Schnittstelle (eth0-eth...) man kommt?
Und "Problem" dabei ist, dass wir Geräte (wie zB Switche, die Firewall oÄ) zum Konfigurieren zwar im besagten ADMIN VLAN haben, unsere Computer mit denen wir damit arbeiten aber im anderen Netz sind und das ganze deswegen mit einer Firewall Policy geregelt werden sollte.(die UTM dient also auch als Router um die Verbindung herzustellen)
Ich habe entsprechende Netzwerkobjekte erstellt mit den PCs der Leute die Adminzugänge haben sollen (aus dem lokalen Netz und auch via VPN). Die habe ich alle in eine Objektgruppe gepackt und dann damit Portfilter gemacht um den Zugriff zu gewähren. Jezt diese ganzen IP Adressen der Objekte da an dieser Stelle noch mal einzutragen kommt mir komisch vor.
Wenn ich die Zonen "tausche", reicht es sie entsprechend umzubenennen? Muss ich überhaupt den Namen "internal" verwenden? Wenn ich mit der Einstellung eh einen Adressbereich bestimmte kann ich die Zonen nicht benennen wie ich möchte?
Evtl habe ich die Securepoint Philisophie noch nicht ganz verinnerlicht aber die Namen der Zonen mit "dmz..." finde ich nicht hilfreich, ich habe da lieber die Schnittstelle "eth..." oder evtl andere Informationen (Vlan name oÄ) im Namen um nicht noch mehr neue Zählweisen anzufangen.
Hallo,
zum ersten Teil: Kurzum, Ja
Generell sind Zonen Namen nur Bezeichnungen (Ausnahme ist hier die internal Zone).
Sie können umbenennen wie Sie mögen und wie Sie es für sinnvoll halten. (external-telekom, vlan-produktion)
Wenn Sie eine neue Zone anlegen müssen Sie nur darauf achten bei Zonen, die eine IP auf der Firewall bezeichnen das Flag "Interface" zu setzen.
Zur internal Zone: Ich meine diese Implied Rule "du darfst administrieren" ist abhängig vom Namen. Wenn man Sie umbenennt, geht diese Regel verloren. (Da bin ich mir aber gerade nicht zu 100% sicher, ansonsten VM aufsetzen und kurz testen).
Gruß
zum ersten Teil: Kurzum, Ja
Generell sind Zonen Namen nur Bezeichnungen (Ausnahme ist hier die internal Zone).
Sie können umbenennen wie Sie mögen und wie Sie es für sinnvoll halten. (external-telekom, vlan-produktion)
Wenn Sie eine neue Zone anlegen müssen Sie nur darauf achten bei Zonen, die eine IP auf der Firewall bezeichnen das Flag "Interface" zu setzen.
Zur internal Zone: Ich meine diese Implied Rule "du darfst administrieren" ist abhängig vom Namen. Wenn man Sie umbenennt, geht diese Regel verloren. (Da bin ich mir aber gerade nicht zu 100% sicher, ansonsten VM aufsetzen und kurz testen).
Gruß
Es wäre ja gar nicht schlimm wenn diese "automatische Policy" durch den Zonennamen "internal" nicht mehr gilt. Ich möchte den Adminzugang sowieso wie oben beschrieben (habe eben nochmal meinen Text editiert) selber festlegen. Wenn der Zugriff pauschal aus dem gesamte ADMIN LAN zugänglich ist, ist das ja ok, aber ich möchte/muss trotzdem auch aus anderen Netzen zumindest einzelnen Geräten ja den Zugriff erlauben können. (Wo man quasi wieder bei der urspungsfrage ist :P)
Nicht als meckern verstehen, manches ist mir ja auch ebn erst bewusst geworden;) Sie haben mir jetzt schon ein bisschen weitergeholfen mit den Informationen!
Nicht als meckern verstehen, manches ist mir ja auch ebn erst bewusst geworden;) Sie haben mir jetzt schon ein bisschen weitergeholfen mit den Informationen!
Sie können mehrere Administrative Einträge hinterlegen:
Beispiel:
192.168.0.x/24 -> Admin Netz
192.168.1.250/32 -> Admin PC im Vertrieb
192.168.2.250/32 -> Admin PC in der Produktion
usw.
Beispiel:
192.168.0.x/24 -> Admin Netz
192.168.1.250/32 -> Admin PC im Vertrieb
192.168.2.250/32 -> Admin PC in der Produktion
usw.
Ist es nicht möglich diese Zugänge anstatt in den Servereinstellungen bei den Portfiltern mit einzutragen?
Sorry für die erneut "doofe" Nachfrage, aber ich bin etwas erstaunt darüber
Ich habe bei den Portfiltern eine Gruppe mit den verschiedenen Admin PCs (quasi wie in Ihrem Beispiel, Admin Vertrieb, Admin Pdotuktion)
Hier die Portfilter:
http://www.bilder-upload.eu/show.php?file=cb9704-1524815445.png
(ich weiß nicht wie ich vernünftig hier Fotos darstellen kann)
Die unterste Regel (Nr 267) sollte eigentlich bewirken, dass die Gruppe "Administratoren" auch auf das Firewall Interface hat. Man kann jedoch nicht die Standby Firewall des Clusters erreichen sondern nur die aktive Firewall.(wie ganz oben beschrieben)
Sorry für die erneut "doofe" Nachfrage, aber ich bin etwas erstaunt darüber
Ich habe bei den Portfiltern eine Gruppe mit den verschiedenen Admin PCs (quasi wie in Ihrem Beispiel, Admin Vertrieb, Admin Pdotuktion)
Hier die Portfilter:
http://www.bilder-upload.eu/show.php?file=cb9704-1524815445.png
(ich weiß nicht wie ich vernünftig hier Fotos darstellen kann)
Die unterste Regel (Nr 267) sollte eigentlich bewirken, dass die Gruppe "Administratoren" auch auf das Firewall Interface hat. Man kann jedoch nicht die Standby Firewall des Clusters erreichen sondern nur die aktive Firewall.(wie ganz oben beschrieben)
Sie können das auch via Regeln im Portfilter erreichen.
Was steht denn im Netzwerkobject eth5-interface-admin als Wert?
Steht dort eine IP oder "Schnittstelle"?
Wenn dort Schnittstelle steht, verwendet die UTM immer nur die primäre IP des Interfaces für das Objekt. (Cluster IPs werden sekundär geflagged)
Das heißt Sie benötigen mindestens zwei Objekte und eine Gruppe:
Objekt1: IP der Master
Objekt 2: IP der Spare
Objekt 3: Cluster IP (optional)
Eine Netzwerkgruppe wo diese zwei (oder drei) Objekte Mitglied sind und müssen damit dann die Regel anlegen.
Genau das macht zb die Adminstration unter Netzwerk -> Servereinstellungen automatisch. Sie schreiben alle Regeln manuell (dadurch der mehr Aufwand)
Was steht denn im Netzwerkobject eth5-interface-admin als Wert?
Steht dort eine IP oder "Schnittstelle"?
Wenn dort Schnittstelle steht, verwendet die UTM immer nur die primäre IP des Interfaces für das Objekt. (Cluster IPs werden sekundär geflagged)
Das heißt Sie benötigen mindestens zwei Objekte und eine Gruppe:
Objekt1: IP der Master
Objekt 2: IP der Spare
Objekt 3: Cluster IP (optional)
Eine Netzwerkgruppe wo diese zwei (oder drei) Objekte Mitglied sind und müssen damit dann die Regel anlegen.
Genau das macht zb die Adminstration unter Netzwerk -> Servereinstellungen automatisch. Sie schreiben alle Regeln manuell (dadurch der mehr Aufwand)
Es steht dort die Schnittstelle "eth5" als Adresse. Das erklärt jetzt wieso die Spare-Firewall nicht erreichbar ist!
Dann macht es doch wieder Sinn dass man die Administratorzugänge exra einträgt.
Jetzt kann ich nachvollziehen wieso es aufwändiger ist das ganze mit Portfiltern zu realisieren.
Trotzdem interessehalber: wenn ich mit einem Portfilter den Zugang zum Interface der Spare-Firewall ermöglichen will, muss ich also anstatt der Schnitstelle die IP (also jetzt die 192.168.200.3) angeben?
Ist somit doch nachvollziehbar.
Update:
Leider irgendwie doch nicht
Ich habe jetzt zuerst meine Rechner IP bei Adminstration unter Netzwerk -> Servereinstellungen eingetragen, und auch die Clusterkonfig synchronisiert (natürlich entscheidend hierbei!)
Leider trotzdem kein Zugriff auf die Spare-Firewall.
Dann noch einen Portfilter angelegt die den Zugriff erlaubt auf neues Objekt: 192.168.200.3/32 in der Zone firewall-eth5 (also die Zone fürs Interface).
Trotzdem noch kein Zugriff möglich
Dann macht es doch wieder Sinn dass man die Administratorzugänge exra einträgt.
Jetzt kann ich nachvollziehen wieso es aufwändiger ist das ganze mit Portfiltern zu realisieren.
Trotzdem interessehalber: wenn ich mit einem Portfilter den Zugang zum Interface der Spare-Firewall ermöglichen will, muss ich also anstatt der Schnitstelle die IP (also jetzt die 192.168.200.3) angeben?
Ist somit doch nachvollziehbar.
Update:
Leider irgendwie doch nicht
Ich habe jetzt zuerst meine Rechner IP bei Adminstration unter Netzwerk -> Servereinstellungen eingetragen, und auch die Clusterkonfig synchronisiert (natürlich entscheidend hierbei!)
Leider trotzdem kein Zugriff auf die Spare-Firewall.
Dann noch einen Portfilter angelegt die den Zugriff erlaubt auf neues Objekt: 192.168.200.3/32 in der Zone firewall-eth5 (also die Zone fürs Interface).
Trotzdem noch kein Zugriff möglich
Ändert man den Namen kann man nicht mehr von dort aus administrativ auf die 11115/TCP und die 22/TCP zugreifen (zumindest nicht ohne explizite Regeln oder einen Eintrag unter Administration)Zur internal Zone: Ich meine diese Implied Rule "du darfst administrieren" ist abhängig vom Namen. Wenn man Sie umbenennt, geht diese Regel verloren. (Da bin ich mir aber gerade nicht zu 100% sicher, ansonsten VM aufsetzen und kurz testen).
Danke für die klare Aussage.Svenja hat geschrieben:Ändert man den Namen kann man nicht mehr von dort aus administrativ auf die 11115/TCP und die 22/TCP zugreifen (zumindest nicht ohne explizite Regeln oder einen Eintrag unter Administration)
Leider funktioniert der Zugriff (auf die Spare Firewall) weder durch eine entsprechende Portfilterregel, noch durch den Eintrag einer IP-Adresse in den Servereinstellungen->Administration.
https://ibb.co/hcxmEH
https://ibb.co/cq6hMx
Die verwendete Dienstgruppe in der Regel enthält den Port 11115 und 4430.
Glücklicherweise komme ich in der Zone "internal" noch auf die Spare Firewall, ansonsten allerdings nicht.
mhm ohne die Maschine und die genaue Konfiguration zu kennen, wird das schwierig. So von der Schilderung klingt alles korrekt.
Am besten dazu doch mal im Support melden.
Am besten dazu doch mal im Support melden.
Ich glaube ich komme der Problemursache ein Stück näher.
Das "Problem" ist, dass beim Zugriff auf die Spare Firewall ich ja erstmal über die Main Firewall gehe (mein aktives defalt gateway)
Wegen dem Clusteraufbau hängen alle zusammengehörigen HA Schnittstellen der Firewalls ja im gleichen VLAN.
Beim Aufruf der Spare Firewall verläuft die Route von meinem PC aus also erst zum Default Gateway vom "normalen" Büronetz, also die Main Firewall. Sie kontrolliert ob ich autorisiert dafür bin. (Ich komme ja aus der Zone internal mit fester IP).
Sie sieht, es passt alles zu meinen Portfiltern und routet das Paket weiter, und zwar direkt ins ADMIN VLAN.
Jetzt kommt an der eth5 Schnittstelle der Spare-Firewall mein TCP Paket an. Auf der Spare Firewall ist das gleiche Netzwerkobjekt meines PCs (feste IP und Zone internal) hinterlegt mit entsprechendem Portfilter. Allerdings passt die Schnittstelle eth5 nicht zur Zone internal.
Ich hab es imernoch nicht geschafft passende Portfilter zu bauen aber ich glaube dass ich auf der richtigen Spur bin.
Weil das ganze aber so kompliziert ist glaube ich nicht dass das best practice ist ...
Aber irgendwie muss es doch auch möglich sein um zB auch via VPN den Zugriff zu erlauben...
Das "Problem" ist, dass beim Zugriff auf die Spare Firewall ich ja erstmal über die Main Firewall gehe (mein aktives defalt gateway)
Wegen dem Clusteraufbau hängen alle zusammengehörigen HA Schnittstellen der Firewalls ja im gleichen VLAN.
Beim Aufruf der Spare Firewall verläuft die Route von meinem PC aus also erst zum Default Gateway vom "normalen" Büronetz, also die Main Firewall. Sie kontrolliert ob ich autorisiert dafür bin. (Ich komme ja aus der Zone internal mit fester IP).
Sie sieht, es passt alles zu meinen Portfiltern und routet das Paket weiter, und zwar direkt ins ADMIN VLAN.
Jetzt kommt an der eth5 Schnittstelle der Spare-Firewall mein TCP Paket an. Auf der Spare Firewall ist das gleiche Netzwerkobjekt meines PCs (feste IP und Zone internal) hinterlegt mit entsprechendem Portfilter. Allerdings passt die Schnittstelle eth5 nicht zur Zone internal.
Ich hab es imernoch nicht geschafft passende Portfilter zu bauen aber ich glaube dass ich auf der richtigen Spur bin.
Weil das ganze aber so kompliziert ist glaube ich nicht dass das best practice ist ...
Aber irgendwie muss es doch auch möglich sein um zB auch via VPN den Zugriff zu erlauben...Heute nochmal frisch an die Sache rangegangen. Ich habe es jetzt geschafft entsprechende Portfilter einzurichten.
Auf der Main Firewall muss es die Regel geben dass mein PC aus der Zone internal ins ADMIN Netz mit dem Port 11115 darf.
Auf der Spare Firewall muss es eine Regel geben dass mein PC aus der Zone ADMIN auf das Interface darf.
Jetzt kann ich die Weboberfläche aufrufen.
Wenn mal die andere Firewall Betrieb macht muss man entsprechend umgekehrt solche Regeln anlegen.
Es ist auch hilfreich sich die Log Eintröge von beiden Firewalls einzeln nebeneinander anzusehen, dann kann man erkennen wo es gerade hängt.
Also im Endeffekt doch ganz simpel nachzuvollziehen.
Ich habe noch weitergetüftelt, besser ist es NAT zu verwenden.
Ich kann es nicht mehr ganz nachvollziehen wie ich es vorhin hatte aber hatte eben das Problem, dass die Rückroute von der Spare-Firewall zu meinem PC nicht über die Main Firewall verlief sondern halt direkt ins Netz (weil ja direct connected) dadurch gab es dann im Log der Main Firewall Eintröge "NewStateWithoutSyn".
Schon alles sehr interessant, ich werde jetzt mal weiter überlegen und testen. Mit den Einträgen unter "Serverienstellungen-> Administration" in Verbindung mit NAT kann man vielleicht eine saubere Lösung zaubern.
Auf der Main Firewall muss es die Regel geben dass mein PC aus der Zone internal ins ADMIN Netz mit dem Port 11115 darf.
Auf der Spare Firewall muss es eine Regel geben dass mein PC aus der Zone ADMIN auf das Interface darf.
Jetzt kann ich die Weboberfläche aufrufen.
Wenn mal die andere Firewall Betrieb macht muss man entsprechend umgekehrt solche Regeln anlegen.
Es ist auch hilfreich sich die Log Eintröge von beiden Firewalls einzeln nebeneinander anzusehen, dann kann man erkennen wo es gerade hängt.
Also im Endeffekt doch ganz simpel nachzuvollziehen.
Ich habe noch weitergetüftelt, besser ist es NAT zu verwenden.
Ich kann es nicht mehr ganz nachvollziehen wie ich es vorhin hatte aber hatte eben das Problem, dass die Rückroute von der Spare-Firewall zu meinem PC nicht über die Main Firewall verlief sondern halt direkt ins Netz (weil ja direct connected) dadurch gab es dann im Log der Main Firewall Eintröge "NewStateWithoutSyn".
Schon alles sehr interessant, ich werde jetzt mal weiter überlegen und testen. Mit den Einträgen unter "Serverienstellungen-> Administration" in Verbindung mit NAT kann man vielleicht eine saubere Lösung zaubern.
Ich habe jetzt eine "saubere" Lösung mit den Portfiltern gefunden:
https://ibb.co/dUfMM7
Die Regel Nr 267 ist für für den "direkten" Zugriff auf die Firewall die man auch gerade als Gateway nimmt (also die betriebmachende Main Firewall)
Die Regel Nr 304 ist für den Zugriff auf die Spare Firewall, und zwar wird hierbei SourceNAT angewendet sodass auf der Spare-Firewall die Pakete mit der Absender IP des Ausgangsinterfaces der Main-Firewall ankommen.
(Die Regel Nr 304 könnte man auch aufsplitten auf 2 Regeln mit den beiden IP Adressen der Firewalls, so ist das gesamte Subnetz möglich)
Die Regeln 305 und 306 sind dann enssprechend für diesen Fall,damit in beiden Fällen (also auch wenn mal die Rollen Main/Spare getauscht werden) der Zugriff erlaubt ist.
Mit dem Objekt "eth5 Interface" sieht jede Firewall sich selbst als das Interface. Es ist hierbei egal, dass sie sich im Clusterverbund befinden. Beide systeme arbeiten trotzdem eigenständig und die Regeln werden von beiden auch für sich selbst interpretiert. Diese Tatsache habe ich am Anfang außer Acht gelassen.
Testen kann man beide Richtungen indem man sich einfach am PC als Gateway beide Firewalls mal einstellt und dann überprüft ob die Weboberfläche noch erreichbar ist.
Interessant ist hierbei gleich die nächste logische Konsequenz: Der Zugriff auf Geräte in anderen Subnetzen funktioniert dann nicht mehr richtig, weil die Geräte ja die Main Firewall als Gateway verwenden (ich jedoch die Spare Firewall). Die Rückroute verläuft also dann anders. Rein vom Routing her sind asymmetrische Routen ja kein Problem, aber die Firewalls blocken dann die TCP Connection weil die Sync Pakete an unerwarteter Stelle auftreten.
Ich brauchte durch das NAT jetzt keine weiteren Objekte anlegen mit den Admin IPs in der anderen (ADMIN) Zone. So kann ich alles "Zentral" und einfach in meiner Gruppe "Administratoren" verwalten und mit diesen Portfiltern wird dann der Zugriff ermöglicht.
Schön wenn man sich ein Rätsel endlich erklären kann
Besser ist es natürlich die Zone internal gleich richtig zu verwenden aber so kann ich auch aus anderen Netzen wie zB VPN den Zugriff ermöglichen
https://ibb.co/dUfMM7
Die Regel Nr 267 ist für für den "direkten" Zugriff auf die Firewall die man auch gerade als Gateway nimmt (also die betriebmachende Main Firewall)
Die Regel Nr 304 ist für den Zugriff auf die Spare Firewall, und zwar wird hierbei SourceNAT angewendet sodass auf der Spare-Firewall die Pakete mit der Absender IP des Ausgangsinterfaces der Main-Firewall ankommen.
(Die Regel Nr 304 könnte man auch aufsplitten auf 2 Regeln mit den beiden IP Adressen der Firewalls, so ist das gesamte Subnetz möglich)
Die Regeln 305 und 306 sind dann enssprechend für diesen Fall,damit in beiden Fällen (also auch wenn mal die Rollen Main/Spare getauscht werden) der Zugriff erlaubt ist.
Mit dem Objekt "eth5 Interface" sieht jede Firewall sich selbst als das Interface. Es ist hierbei egal, dass sie sich im Clusterverbund befinden. Beide systeme arbeiten trotzdem eigenständig und die Regeln werden von beiden auch für sich selbst interpretiert. Diese Tatsache habe ich am Anfang außer Acht gelassen.
Testen kann man beide Richtungen indem man sich einfach am PC als Gateway beide Firewalls mal einstellt und dann überprüft ob die Weboberfläche noch erreichbar ist.
Interessant ist hierbei gleich die nächste logische Konsequenz: Der Zugriff auf Geräte in anderen Subnetzen funktioniert dann nicht mehr richtig, weil die Geräte ja die Main Firewall als Gateway verwenden (ich jedoch die Spare Firewall). Die Rückroute verläuft also dann anders. Rein vom Routing her sind asymmetrische Routen ja kein Problem, aber die Firewalls blocken dann die TCP Connection weil die Sync Pakete an unerwarteter Stelle auftreten.
Ich brauchte durch das NAT jetzt keine weiteren Objekte anlegen mit den Admin IPs in der anderen (ADMIN) Zone. So kann ich alles "Zentral" und einfach in meiner Gruppe "Administratoren" verwalten und mit diesen Portfiltern wird dann der Zugriff ermöglicht.
Schön wenn man sich ein Rätsel endlich erklären kann
Besser ist es natürlich die Zone internal gleich richtig zu verwenden aber so kann ich auch aus anderen Netzen wie zB VPN den Zugriff ermöglichen