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

    Zweite PFSense parallel

    Scheduled Pinned Locked Moved Deutsch
    12 Posts 5 Posters 1.3k 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.
    • V
      viragomann @it_ib
      last edited by

      @it_ib said in Zweite PFSense parallel:

      Das Routing für VPNs ist soweit ich das sehe dynamisch, ich habe keine Möglichkeit der FW2 eine Route zu hinterlegen, z.B. dass das Netz 172.16.0.0/12 über das Interface IPSec zu erreichen ist

      Das sollte die Firewall selbst wissen. Eine Route ist dafür nicht nötig.

      Ich habe meinem Rechner bereits mal manuell eine Route eingetragen

      route add 172.16.0.0 MASK 255.240.0.0 FW2
      

      Das sollte allerdings schon zum Erfolg führen.

      Wie hängt die FW2 im Netz? Einfach mit dem LAN verbunden?

      Ist der Zugriff am eingehenden Interface auf das VPN-Netz erlaubt?

      Lassen sich die Clients von der pfSense pingen?
      Auch, wenn du die Source auf das LAN änderst?

      Daran würde ich erst mal arbeiten. Allerdings funktioniert das Routing nicht, wenn die FW2 einfach auch mit im LAN hängt und du darauf die Routen setzt. Das hätte ein asymmetrisches Routing zur Folge.
      Du müsstest sie in ein separates Transit-Netz bringen und mit der FW1 verbinden und dann auf beiden die Routen entsprechend konfigurieren.

      I 1 Reply Last reply Reply Quote 0
      • I
        it_ib @viragomann
        last edited by

        @viragomann
        Die FW2 hängt mit dem Interface LAN ganz normal im Netz, gleiches Subnetz wie FW1.
        Die Clients lassen sich von FW2 LAN-If pingen.
        Auf der LAN-Seite der FW2 gibt es nur eine any-any Regel.
        Kein Log-Eintrag im FW-Log, kein Block.
        Ich habe auf der FW1 eine Route hinzugefügt
        für Netz 172.16.0.0/12 und ein Gateway mit der IP der FW2

        Also Du meinst ich soll der FW1 ein zusätzliches Interface verbinden, und mit dem LAN-If der FW2 verbinden und hier ein Transfernetz verwenden, welches sich außerhalb unserer anderen Netze befindet (also z.B. ein 192.168er)?
        Das ist jetzt bissl knifflig, da ich ja schon mindestens 100 User im VPN auf der FW2 habe...

        V JeGrJ 2 Replies Last reply Reply Quote 0
        • V
          viragomann @it_ib
          last edited by

          @it_ib said in Zweite PFSense parallel:

          Die Clients lassen sich von FW2 LAN-If pingen.

          Ja, ist bekannt. Aber auch, wenn du als Quelle LAN IP setzt?

          Ich habe auf der FW1 eine Route hinzugefügt
          für Netz 172.16.0.0/12 und ein Gateway mit der IP der FW2

          Wie gesagt, sieh erst mal zu, dass der Zugriff von einem LAN Rechner funktioniert, auf dem du händisch die Route setzt. Überprüfe den Erfolg dessen zur Sicherheit auch in der Routen-Tabelle.

          Also Du meinst ich soll der FW1 ein zusätzliches Interface verbinden, und mit dem LAN-If der FW2 verbinden und hier ein Transfernetz verwenden, welches sich außerhalb unserer anderen Netze befindet (also z.B. ein 192.168er)?
          Das ist jetzt bissl knifflig, da ich ja schon mindestens 100 User im VPN auf der FW2 habe...

          Genau.
          Nein, das ist gar nicht knifflig. Du kannst einfach im aktuellen Zustand das zusätzliche Netzwerk hinzufügen. Das kann auch ein VLAN auf dem aktuellen LAN sein, wenn keine Ports mehr frei sind.
          Das kannst du dann auf beiden pfSesne konfigurieren und die Routen einrichten. Auf FW1 braucht es eine Route zum VPN-Netz, die auf die IP der FW2 zeigt und auf der FW2 benötigst du eine Route für das LAN auf FW1, jeweils auf die IPs im Transitnetz.
          Anschließend auf der FW2 mal das LAN Interface deaktivieren und die Verbindung zu einem VPN Client testen. Sollte sie nicht funktionieren, aktivierst du das Interface eben wieder und alles ist wie vorher.
          Die Route zum LAN auf FW2 sollte wirkungslos sein, wenn ein Interface mit diesem Netz vorhanden ist.

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

            @it_ib said in Zweite PFSense parallel:

            Die FW2 hängt mit dem Interface LAN ganz normal im Netz, gleiches Subnetz wie FW1.

            Das ist ein Problem. Asymmetrisches Routing ist die Folge, deshalb macht man das im Normalfall nie wenn man es vermeiden kann. Siehe anderer Post gerade mit Erklärung zu asym. Routing (gerade beantwortet).

            Am Besten ein XFER Netz mit der Sense machen über das sauber geroutet wird, dann hat man die Asymmetrie schonmal raus. Andernfalls bindet man sich alle möglichen Probleme ans Bein.

            @it_ib said in Zweite PFSense parallel:

            Also Du meinst ich soll der FW1 ein zusätzliches Interface verbinden, und mit dem LAN-If der FW2 verbinden und hier ein Transfernetz verwenden, welches sich außerhalb unserer anderen Netze befindet (also z.B. ein 192.168er)?

            Nein, das IF der VPN-FW nehmen und mit einem eigenen (V)LAN/IF der HauptFW verbinden und darüber ein Transfernetz /29 oder /30 legen (je nachdem ob geclustered).

            @it_ib said in Zweite PFSense parallel:

            Das ist jetzt bissl knifflig, da ich ja schon mindestens 100 User im VPN auf der FW2 habe...

            Was ist daran das Problem? Eingewählte User sollten eh immer aus Sicherheitsgründen in einem eigenen Subnetz sein das NICHTS mit LAN o.ä. zu tun hat. Man weiß sonst nie was die per VPN einschleppen, daher sind sie normalerweise immer als extern zu behandeln. Reinbridgen ins LAN ist da ein no-go. Und wenn die ein eigenes Netz nach Einwahl haben (wie OpenVPN auch) dann ist es egal was du für Routing Änderungen machst - das bekommen die Clients nicht mit 😃

            Am Rand: Was war der Grund für den Split? Ich habe im Business Umfeld bei ordentlicher HW Dimensionierung noch keinen Kunden gehabt bei dem "Performance" ein Problem gewesen wäre (bei OpenVPN!) dass man unbedingt Main-FWL und VPN hat trennen müssen. Wir haben 2-3 Kunden, die das getrennt haben oder trennen wollen, aber im Prinzip nur deshalb, damit sie bei Failovern der HauptFWL (bpsw. bei Updates) keinen Failover beim VPN haben und sie das getrennt behandeln können. Daher bin ich neugierig was das für HW ist die SO ein Performance Problem bringt, dass 50-100 VPN User (per IPsec was ja noch im Kernel laufen sollen) ein Problem sind?

            Cheers

            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.

            I 1 Reply Last reply Reply Quote 0
            • I
              it_ib @JeGr
              last edited by

              @jegr
              Die Firewall laufen als VM.
              Das Performance-Problem kommt eher von PF selbst, wenn ich versuche Firewall-Logs auszuwerten etc. komme ich da an die Grenzen, weil ich gefühlt pro Sekunde 2000 Log-Einträge bekomme.
              Daher die Idee, die 2. FW alt "Trusted" zu sehen, da alles eigene Mitarbeiter.
              Das VPN kommt IMMER von einem von uns kontrollierten und gehärteten Rechner.

              Die Umstellung der zweiten auf ein Transfernetz daher schwierig, da alle Clients dann erst mal die Verbindungen zu den Systemen verlieren.

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @it_ib
                last edited by

                @it_ib said in Zweite PFSense parallel:

                Die Umstellung der zweiten auf ein Transfernetz daher schwierig, da alle Clients dann erst mal die Verbindungen zu den Systemen verlieren.

                Warum?
                IPSec braucht dabei nicht angetastet zu werden.

                I 1 Reply Last reply Reply Quote 0
                • I
                  it_ib @viragomann
                  last edited by

                  @viragomann
                  Naja, wenn ich das LAN-Interface der Firewall ändere, ist doch die Verbindung nach innen weg.
                  Oder reden wir auf der FW2 über ein zusätzliches Interface, um das Transfer-Netz zu machen?

                  V 1 Reply Last reply Reply Quote 0
                  • N
                    NOCling
                    last edited by NOCling

                    Da wäre doch eher ein Syslog Server mit elastic das Projekt der Wahl.

                    Auf der FW werte ich logs im Heimbereich aus, aber doch nicht im Firmen Umfeld wo 10k+ Einträge pro Sekunde rein kommen.
                    Dafür ist die GUI nicht gedacht und wird sie auch niemals sein.

                    Und wenn schon eine VPN-Konzentrator, dann mit einem Transfernetz angebunden und sauberem Routing, sonst bekommst ganz schnell neue Probleme, async. Routing mag keine Firewall. Die will eine klare Struktur.

                    Netgate 6100 & Netgate 2100

                    M 1 Reply Last reply Reply Quote 0
                    • V
                      viragomann @it_ib
                      last edited by

                      @it_ib
                      Das Transit-Netz kannst du, wie beschrieben parallel einrichten. Zum Testen der Verbindung muss das LAN dann deaktiviert werden. Aber das kann ja zu einem Zeitpunkt geschehen, zu dem nicht alle Roadwarrior die VPN brauchen.
                      Und sollte es nicht funktionieren, aktivierst du eben das LAN wieder und hattest einen VPN-Ausfall von einer Minute.

                      I 1 Reply Last reply Reply Quote 0
                      • I
                        it_ib @viragomann
                        last edited by

                        Danke an alle, hat geklappt!

                        1 Reply Last reply Reply Quote 0
                        • M
                          MaBo1968 @NOCling
                          last edited by

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