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

    Problem LAN zu DMZ

    Scheduled Pinned Locked Moved Deutsch
    8 Posts 3 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.
    • H
      haithabu84
      last edited by

      Hallo,

      ich habe mir hier eine DMZ konfiguriert und soweit funktioniert diese auch. Leider funktioniert eine Sache nicht:

      Ich möchte eine Verbindung aus dem LAN in die DMZ zu den dort befindlichen Rechnern herstellen können. Aber egal welche Konfiguration ich bisher ausprobiert habe, keine greift.

      Ich habe jeweils für die DMZ und das LAN eine eigene physische Schnittstelle/NIC, deren Netz-Adressen:

      LAN 10.2.0.0/20
      DMZ 10.2.28.0/24

      die jeweiligen Gateway-Adressen die die Pfsense darstellen:

      10.2.0.1
      10.2.28.1

      Lustigerweise kann ich von beiden Netzen aus, jeweils die Schnittstellen-Adresse erreichen. Aber eben nicht die Hosts/Clients/Rechner in diesem Netz.

      Für das LAN habe ich eine Rule mit folgendem Inhalt erstellt: Allow IPv4 any Protocol from Source 10.2.0.0/20 to Destination 10.2.28.0/24

      Bei DMZ habe ich allerdings ein Reject gemacht, da ich nicht will das ausgehend vom DMZ etwas ins LAN geht: Reject IPv4 any Protocol from Source 10.2.28.0/24 to Destination 10.2.0.0/20.

      Dies sollte funktionieren, zumindest nachdem was ich bisher in diversen Foren gelesen habe, da wenn das Hin-Packet pass ist auch das Rück-Packet pass. Aber leider fünktioniert es dennoch nicht.

      Muss ich hier noch ein NAT konfigurieren? Wenn ja wie müsste dies aussehen?

      Würde mich über Hilfe und Tipps freuen.

      Gruß

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

        Muss ich hier noch ein NAT konfigurieren? Wenn ja wie müsste dies aussehen?

        Nein, NAT wäre hier kontra-produktiv. Beides sind interne Netze nach RFC1918, die werden ganz normal geroutet. Die üblichen Fragen gelten auch hier:

        0a) Warum ist das LAN so groß? Muss das ein /20 sein?
        0b) Warum die .8 als Gateway Adresse?

        1. Ist die 10.2.0.8 (pfsense) im LAN das default GW
        2. Ist die 10.2.28.8 (pfsense) in der DMZ das default GW
        3. kann man einen Screenshot der Regeln sehen? Reihenfolge geprüft?
        4. Ist auf den Interfaces (LAN/DMZ) der Haken drin, dass private Adressen geblockt werden?
        5. Gibt es andere Router/Gateways

        Gruß

        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
        • H
          haithabu84
          last edited by

          @JeGr:

          Muss ich hier noch ein NAT konfigurieren? Wenn ja wie müsste dies aussehen?

          Nein, NAT wäre hier kontra-produktiv. Beides sind interne Netze nach RFC1918, die werden ganz normal geroutet. Die üblichen Fragen gelten auch hier:

          0a) Warum ist das LAN so groß? Muss das ein /20 sein?
          0b) Warum die .8 als Gateway Adresse?

          1. Ist die 10.2.0.8 (pfsense) im LAN das default GW
          2. Ist die 10.2.28.8 (pfsense) in der DMZ das default GW
          3. kann man einen Screenshot der Regeln sehen? Reihenfolge geprüft?
          4. Ist auf den Interfaces (LAN/DMZ) der Haken drin, dass private Adressen geblockt werden?
          5. Gibt es andere Router/Gateways

          Gruß

          0a) Muss es nicht, aber ich habe das so ähnlich hier. Ich wollte mich persönlich nicht noch weiter verwirren. Random. ;D
          0b) Ich habe es mal auf .1 abgeändert. Ist ja eigentlich auch Wurst.

          1. Ja.
          2. Ja.
          3. Siehe Anhang.
          4. Nein, der Haken ist nicht gesetzt.
          5. Nur das WAN-Gateway vom Provider, das mehr als Modem fungiert.

          Gruß

          LAN_rules.png_thumb
          LAN_rules.png
          DMZ_rules.png_thumb
          DMZ_rules.png

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

            Hallo,

            die Regeln sollten ja den Zugriff von LAN nach DMZ erlauben, falls das deine 2. LAN-Regel nicht verbietet.

            Möglicherweise blockt die PC-Firewall am Zielrechner den Zugriff aus einem anderen Subnetz. Windows tut das von Haus aus.

            1 Reply Last reply Reply Quote 0
            • H
              haithabu84
              last edited by

              Nein, die PC-Firewall sollte kein Problem sein, da es sich um ein Debian handelt und da ist iptables inaktiv.

              Die Zweite Regel blockt nur den Internetverkehr für einen Client der noch mit XP läuft.

              Könnte vielleicht das VLAN, indem ich die DMZ betreibe, das Problem sein? Ich habe ein untagged VLAN auf einem Brocade Switch eingerichtet, da ich nicht extra einen Switch für die DMZ stellen wollte. Sollte aber aus meiner Sicht kein Problem sein, da die pfSense jeweils ein Standbein in beiden VLANs hat… oder könnte es hier ein Problem geben?

              Mir ist jetzt auch folgendes aufgefallen: Wenn ich ein TCPdump auf der Debian-Kiste laufen lasse und aus dem anderen Netz pinge, kommt das Echo request an. Dann aber wird keines mehr zurückgesendet... auf der pfsense sieht der Mitschnitt dann so aus...

              
              11:54:05.499610 IP 10.4.1.50 > 10.4.29.99: ICMP echo request, id 52481, seq 1, length 24
              11:54:05.499968 ARP, Request who-has 10.4.1.50 tell 10.4.29.99, length 46
              11:54:06.507552 ARP, Request who-has 10.4.1.50 tell 10.4.29.99, length 46
              11:54:07.547546 ARP, Request who-has 10.4.1.50 tell 10.4.29.99, length 46
              
              

              Wie kann das sein? Das default Gateway ist auf jeden Fall gesetzt, dies habe ich gerade nochmal überprüft und es ist auch erreichbar.

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

                Ist der Mitschnitt jetzt von dem Debian auf der 29.99 oder auf der pfsense?

                Mach doch mal zeitgleich beide und poste die, da ist was sehr seltsam und mir scheint das eher auf Netzwerkebene zu sein. Können sie Quelle und Ziel ggf. sehen weil nicht per VLAN separiert? Oder ist auf der Kiste in der DMZ die Maske vllt falsch und sie versucht direkt zu antworten statt es ans Gateway zu schicken?

                Gruß

                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
                • V
                  viragomann
                  last edited by

                  Keine Ahnung von wo du da wohin pingst. Die IPs sind in keinem der o.g. Netze enthalten.

                  Der TCPdump zeigt abgeshen von dem Echo Request nur die zugehörigen ARP-Requests ohne Antworten. Und ARP passiert nur in einem Subnetz.
                  Dass nun 10.4.1.50 im selben Subnetz wie 10.4.29.99, zeigt dass dieses auch sehr groß dimensioniert sein muss, mind. /19. (??) Dass keine Antwort kommt, könnte auf einen Netzwerkkonfigurationsfehler hindeuten.

                  Vielleicht überschneiden sich das doch ein paar Netzwerkkonfigurationen?
                  Ich würde das mal aufräumen.

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

                    Stimmt hatte ich glatt übersehen. Da steht 10.4 nicht 10.2. Das kann also hinten wie vorne nicht sinnvoll in der DMZ ankommen.

                    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.