Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 5 subscribers
  • Views 1551 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Systemweite Netzwerkdefinitionen wie bei der SG

F Neumann

Hallo Zusammen,

mir fällt an mehreren Stellen noch der Wechsel von der SG auf die XG schwer.
Grade einige der folgenden von der SG gewohnten und geschätzten "Basics" scheinen in der XG nicht vorhanden zu sein, oder irre ich:

  1. Automatische verknüpfte Netzwerkdefinitionen für Interface-Adressen
    Auf der SG gab es mit dem Interface verknüpfte Definitionen pro Interface ("XXX (Address)", "XXX (Network)", "XXX (Broadcast)".
    In der XG finde ich nur "#Port1", was lediglich der Interface-Address entspricht und nichtmal den Anzeigenamen des Interfaces anstelle des Ports wiedergibt?! Muss ich daher die Netzwerkdefinitionen passenden manuell anlegen (und vor allem pflegen, bei Interface-Änderungen?) = doppelte Definitionen, evtl. veraltet, Fehleranfällig, erhöhter Pflegeaufwand ...?
    Muss ich zudem für eine bessere Nachvollziehbarkeit selbst die Definition "#Port1" noch einmal selbst zusätzlich mit eigenem Namen anlegen?
    Es erschließt sich mir nur bedingt, warum wir auf der einen Seite versuchen uns mit Themen wie SD-WAN von Hardware und bestimmten Interfaces zu lösen, auf der anderen Seite jedoch ein angelegtes Interface derat fest an einen Hardware-Port binden, dass sogar die zugehörige Interface-Netzwerkdefinition "#Port1" heißt. Ist das nicht inkonsequent?

  2. Volltextsuche bei Auswahl von Netzwerk- oder Dienstdefinitionen in z.B. Firewallregeln
    Kann die XG in der Suche wirklich nur nach dem Anfang eines Objektnamens suchen?

  3. QoS-Policy
    Warum muss ich in einer QoS-Policy Definition die Association zu einem bestimmten Bereich festlegen, wenn die verschiedenen Bereiche gar keine abweichenden Einstellungen benötigen/erlauben?
    Sprich: Ich möchte eine 10.000KB/s Policy erstellen und diese in allen 4 Modulen nutzen können. Scheint jedoch nicht zu gehen, sondern ich muss eine 10.000KB/s Policy für jeweils User, Firewall, Web und Application anlegen? 4 mal die genau gleiche Definition?!

Bin ich hier zu sehr im SG-Gedanken noch gefangen oder vermisst außer mir noch jemand derartige Basics?



This thread was automatically locked due to age.
  • 0

    Zu Punkt1: Die Firewall ist eine Zonen basierte Firewall. Jedes Interface muss immer in einer Zone sein, daher benötigt man kein Network/Broadcast Objekt mehr. Du kannst einfach sagen "LAN" soll freigegeben werden in einer Firewall Regel. LAN beinhaltet alles, was von dem Interface kommt, egal welche Interfaces da drin sind. Man kann nun sagen, ich mache pro Interface (VLAN bspw.) eine eigene Zone (Printer, IoT, Server etc.) und definiert es daran, dann kann man das auch schön lesbar in den Firewall Regeln bauen. 
    In NAT arbeitet man in der Regel mit Interfaces. Einzig die SD-WAN PBR Regeln vermissen zur Zeit noch das Zonen Konzept, daher ist es dort essentiell, mit Objekten zu arbeiten. Das wird aber noch nachgepflegt. 
    #Ports können umbenannt werden. Wenn du Port1 in Network - Interfaces umbenennst, wird das Objekt für das Interface selbst auch umbenannt. 

    Punkt2: Das ist etwas, was auf der Agenda für das nächste Major Firmware Update steht. 

    Punkt3: QoS kann immer gebunden werden und hier entfaltet sich die Granularität. Ein QoS kann anhand von Usern definiert werden, das wird dann automatisch in der User Basierten Firewall Regel genutzt, wenn vorhanden. Rules QoS sind Network basierte QoS Regeln. Web/App werden zusätzlich optional in einer Firewall Regel geladen. Du kannst hier pro Stufe des Traffic das definieren. Während Web / App sehr granular sind, kannst du auch einfach an User/Network die QoS hängen. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Vielen Dank, @LuCar!
    Das sind schonmal ein paar gute Punkte!

    Zu Punkt 1: Am Beispiel VPN / SSL-VPN, Stichwort "Permitted network resources", kann ich keine Zonen, sondern ausschließlich Netzwerke/Netzwerkdefinitionen auswählen - oder unsinnig, standardmäßig nur die Port-Addresses "#Port1-X".
    Fehlt hier dann auch noch das Zonenkonzept oder hab ich auch hier einen Gedankenfehler?

  • 0 in reply to F Neumann

    Ich nutze nahezu nie #Port außer für NAT Szenarien (DNAT?). Bei VPN nimmst du einfach die VPN Zone. Damit inkludierst du VPN. Aber auch Site to Site (IPsec). Wenn du das nicht möchtest, musst du doch mit einem Object arbeiten. Also abhängig davon, was du definieren möchtest. Außerdem kannst du bei SSLVPN auch einfach mit User Basierten Regeln arbeiten (UserA darf SSH auf Server B). Da brauchst du keine Permitted Networks. Du sagst einfach: VPN User A to ServerZone (ServerB) SSH Allowed. Den Rest macht die Firewall für dich. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    "#Port1" Definitionen kann ich zudem nicht umbenennen. Ich kann das Interface zwar benennen, die zugehörige Netzwerkadressendefiniton bleibt jedoch unverändert.

    Beispiel benannter Interfaces:

    Automatische Portnamen "'#Port1"-X bleiben unverändert - Zusammenhang ist nur bedingt nachvollziehbar und muss erst wieder nachgeschlagen werden:

  • 0 in reply to LuCar Toni

    Hallo @LuCar, ich glaube du bist hier schon einen Schritt weiter. Ich bin nicht beim NAT/Firewallregelwerk, sondern bei der Anlage eines SSL VPN (remote access) Profils. Hier muss ich ja IPs oder Netzwerke angeben (keine Zonen auswählbar), die dem Client kommuniziert werden.

    Ich kann/sollte die "Permitted network resources" im Beispielsweise SSL VPN Remote Access leer lassen und die Zuweisung via User Firewall Policys machen?
    Ist das so überhaupt möglich? Welche Routen werden beim Split tunneling dann an den Client kommuniziert?

  • 0 in reply to F Neumann

    Achso, Permitted Networks sollte Netzwerk Elemente sein. Das stimmt. Hatte ich etwas übersehen, dass dort ja Netzwerk Objekte genutzt werden. Also grundsätzlich (theoretisch) könnte man hier auch mit ANY arbeiten. Oder eben mit Internen IP Adressen. Und die Granularität kommt später über die Firewall Richtlinien. 

    Alternativ muss man hier neue Netzwerk Objekte erstellen. Abhängig davon, was man verteilen möchte. 

    __________________________________________________________________________________________________________________

  • 0 in reply to F Neumann

    Wie gesagt, das #Port Objekt wird dir nicht viel helfen. Das ist nur das Interface als IP. Also die 10.0.0.254/32 (Address in UTM Bereich).

    Du musst hier bei SSLVPN tatsächlich Netzwerk Objekte anlegen. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Okay, sprich: Any wäre unsinnig und gibt es als Objekt hier ebenfalls nicht (ohne es anzulegen). Sonst könnte ich auch gleich "Use as default gateway" anhaken - das wäre identisch. Sprich ich muss mindestens hier einmal die benötigten Netzwerkdefinitionen quasi doppelt zu den eigentlich bereits in den Interfaces gepflegten Daten anlegen.

  • 0 in reply to F Neumann

    Das wäre korrekt. Oder Alternativ ein großes /16 oder /8 von deinem Internen Subnetz. Viele Kunden nutzen gleiche IP Adressen im internen Netzwerk. Daher kann man hier auch mit einem großen Objekt arbeiten. Danach definiert man granular, wer was darf über Firewall regeln. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Gibt es hier Pläne, dass so etwas analog zu SG nochmal wieder kommt und künftig automatisch verknüpft mit den jeweiligen Interfaces erstellt und gepflegt wird? Wäre sinnvoll. Ändere ich das Interface einmal, müsste ich ggf. sämtliche Definitionen manuell finden und anpassen. Bisher konnte ich mich auf der SG darauf verlassen, dass dies durch die verknüpfung mit dem Interface geschieht.

    Die drei Standarddefinition pro Interface waren immer sehr sinnvoll:

Cookie Information Banner