Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 5 subscribers
  • Views 1540 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.
Parents
  • 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

    "#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 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. 

    __________________________________________________________________________________________________________________

Reply
  • 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. 

    __________________________________________________________________________________________________________________

Children
  • 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:

  • +1 in reply to F Neumann

    Die Frage ist immer, wie oft ändert man interne IP Adressen? Also am Ende sollte das keine Änderung von internen Netzwerk Objekten nicht tag täglich machen. In der Regel hat man nicht so viele Objekte wie auf der UTM. 

    Aber ja, die Lösung wäre besser über Zonen zu lösen. Objekte wie auf der UTM anzulegen ist in der Regel nicht die beste Lösung. Das sollte lieber über Zonen passieren. Dafür gibt es Änderungskonzepte für die Zukunft. 

    __________________________________________________________________________________________________________________

Cookie Information Banner