Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Dynamisches Routen mit IPv6

    Scheduled Pinned Locked Moved Deutsch
    4 Posts 2 Posters 1.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • I
      infler
      last edited by

      Hallo Zusammen
      Wir haben in unserem Netzwerk verschiedene Zonen (Web, Mail, ASP, usw.). Jede Zone verfügt über eine pfSense Firewall als Router. Auf diesen Routern sind statische Routen hinterlegt, damit jeder weiss, welcher Gateway für welche Zone zuständig ist. So funktioniert alles mit IPv6 (rein und raus, Mail und Web). Nun existiert noch eine weitere Zone welche etwas spezieller ist, dies ist die ASP Zone. Auch die ASP Zone verfügt über eine pfSense als Gateway. Hinter dieser Firewall befindet sich nun aber pro ASP Kunde eine pfSense Firewall, hinter welcher dann die Server liegen. Da IPv6 nicht mehr genattet wird, kann ich zwar mit der IPv6 Adresse des Servers raus pingen, jedoch findet das Paket den Weg zurück nicht mehr. Auf unseren äussersten Routern sind statische Routings hinterlegt, die genau wissen welches V6 Netz zu welchem Gateway muss. So wird das eingehende Paket also zur ASP Firewall gesendet. Bei der ASP Firewall angekommen bleibt das Paket jedoch hängen, da die Firewall nicht mehr weiss an welchen Hop sie das Paket weiterleiten muss. Natürlich könnte man ein statisches Routing für jeden einzelnen Kunden auf der ASP Firewall einrichten, was aber ziemlich fehleranfällig und unübersichtlich gelöst wäre. Es gäbe allerdings auch noch die Option OSPF zu verwenden um die ganze Sache dynamisch zu managen. Aus meiner Sicht sollte es jedoch noch eine andere Möglichkeit geben, um das Statische Routen zu vermeiden, ev. mit dem Router Advertisement auf dem WAN Interface der Kunden Firewall?

      pfsense_forum.jpg
      pfsense_forum.jpg_thumb

      1 Reply Last reply Reply Quote 0
      • JeGrJ
        JeGr LAYER 8 Moderator
        last edited by

        Hi,

        erst einmal: UFF. Das sieht mir an dieser Stelle - ohne den Rest des Netzes zu kennen - einfach überkomplex aus. Natürlich ist es schön, wenn jeder Kunde eine eigene Firewall hat, aber benötigt er die wirklich? Warum nicht die Regel des Kunden auf einer Firewall (ASP) zentral zusammenbringen und die Netze dort auflegen? (ich kann mir schon min. 1 Grund denken warum, aber trotzdem die Frage)

        Ansonsten ist es richtig was du schreibst. So ich das sehe nehmt ihr 2ac0:a342:a::/48 als Prefix für ASP. Also kann dieses Prefix auch komplett am Core Richtung ASP abgegeben werden. Soweit sauber.
        Danach wirds aber seltsam für mich. Dein Beispiel Kunde A hat als Uplink zur ASP Firewall dann 2ac0:a342:a:52::1/64 -> das verstehe ich nicht. Laut deiner Logik stehen im Netzbereich DMZ (ASP) -> WAN (Kunden) ja eigentlich nur Firewalls und ich bezweifle jetzt mal dass ihr mehr als ein /64er Netz Firewalls da reinstellt :D Ergo könntest du hier völlig simpel das erste Netz des /48er das du zur ASP Firewall routest als Transfernetz nehmen: -> 2ac0:a342:a::/64
        Dein DMZ Interface ist hoffentlich auch mit /64 konfiguriert und nicht wie es die Zeichnung zeigt mit /48 ? :)

        Wenn du 2ac0:a342:a::/64 als DMZ nimmst und der ASP dann die 2ac0:a342:a::1/64, bekommen nach deiner Vergabelogik die Kundenfirewalls 2ac0:a342:a::52:1/64 und nicht /48. Damit hast du den Uplink Part eingetütet. Die Kundennetze selbst sollten dann sinnvollerweise 2ac0:a342:a:52::/64 bekommen mit der Kundenfirewall auf der 2ac0:a342:a:52::1/64.

        Das Einzige was dann noch fehlt ist das Routing 2ac0:a342:a:52::/64 auf 2ac0:a342:a::52:1/64 (also route Kundennetz 52 auf Firewall mit EndIP6 52:1). Das MUSS dann auf der ASP Firewall in die Routing Tabelle rein, andernfalls wüsste die ASP nicht wohin das Netz soll und würde es ggf. sonst wieder zum Core schicken. Wichtig ist da nur, dass du im ASP->Kundenfirewall Segment NICHT /48 anliegen hast, denn sonst wäre für die pfSensen dort alle IP6 aus dem Segment lokal, was sie natürlich nicht sein sollen, denn die Kunden /64 sollen ja nachgelagert auf der Kundenfirewall ankommen.

        Grüße
        Jens

        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

        1 Reply Last reply Reply Quote 0
        • I
          infler
          last edited by

          Hallo JeGr
          Danke für deine ausführliche Antwort. Ja, das Netzwerk ist ziemlich komplex  :-X
          Wenn wir nur eine Firewall für alle Kunden in dieser Zone nehmen würden, so hätten wir eine riesen Firewall, auf die wir regelmässig zugreifen müssten um Änderungen vorzunehmen, was viel zu riskant wäre. Ausserdem sähe ich da noch ein Problem mit den verschiedenen VPN Tunneln und Zugängen. So ist es viel übersichtlicher für jeden Kunden eine eigene Firewall aufzusetzen.

          Momentan besitzt das ASP-DMZ Netz noch ein /48er Subnetz, was ich allerdings dank dir erkannt habe und nun beheben kann.  ;)

          Soweit so gut, leider besteht aber nun immer noch das Problem, dass ich für jedes Kundennetz eine Route auf dem ASP Router Eintragen muss. Bietet IPv6 oder pfSense keine Möglichkeit die Route dynamisch bekannt zu geben ohne dafür ein Packet nach zu installieren. Wie ein Router Advertisement, nur auf der WAN Seite der Kundenfirewall.
          So würde dann jede Kundenfirewall der ASP Ihr Kundendmz bekannt geben und sich als Gateway in das Kundendmz anbieten.

          LG
          Infler

          1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator
            last edited by

            Hmm muss ich nochmal kurz grübeln. RA und PD sind dafür zuständig, aber ob die pfSense so bereitstellen kann, dass sie dir da helfen ist wiederum das andere… nachdenk

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.