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

    Ping zwischen zwei Netzen klappt nicht

    Scheduled Pinned Locked Moved Deutsch
    7 Posts 3 Posters 4.4k 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.
    • D
      deskdevil
      last edited by

      !!! Achtung die Tabellen werden hier in weiß angezeigt - weiß nicht wie ich das ändern kann !!!

      Guten morgen Leute,

      ich habe hier in der Firma die Aufgabe / das Projekt bekommen ein komplett neues Netzwerk für unsere Firma zu planen und zu realisieren.

      Da wir in dem Zuge auf Windows Server 2008 und Windows 7 wechseln wollen möchte ich dies zunächst in einer VMWare aufbauen.

      Leider habe ich gleich zu Beginn Schwierigkeiten einen einfachen Ping zwischen zwei Netzwerken durch pfSense zu machen.

      Aktuell habe ich zwei Netzwerke, die ich miteinander Verbinden will.

      | Interface | Netz-IP | pfSense-IP |
      | WAN | 10.64.6.0/23 | 10.64.6.98 |
      | Server | 10.66.4.0/24 | 10.66.4.1 |

      Das WAN Netzwerk ist ein Netzwerk, welches hier im Haus tatsächlich genutzt wird. Ich habe in pfSense alle NAT-Regeln gelöscht und das NAT auf manuell eingestellt. Weiter habe ich alle Firewallregeln für das WAN-interface (RFC 1798 etc) gelöscht.

      Nun versuche ich von dem Server 10.66.4.2/24 einen Ping auf den WAN-Client 10.64.6.101/23 zu machen. Um dies zu erreichen habe ich folgende Regeln eingestellt.

      WAN-Interface

      | Proto | Source | Port | Destination | Port | Gateway | Schedule | Desription |
      | ICMP | 10.64.6.0/23 | * | 10.66.4.0/24 | * | * | | |

      Server-Interface

      | Proto | Source | Port | Destination | Port | Gateway | Schedule | Desription |
      | ICMP | 10.66.4.0/24 | * | 10.64.6.0/23 | * | * | | |

      Versuche ich nun von der VMWare mit der IP 10.66.4.2/24 einen Ping auf den realen Client 10.64.6.101/23 durchzuführen finde ich folgendes im Log.

      | Act | Time | IF | Source | Destionation | Proto |
      | * | Jun 11 06:33:12 | Server | 10.66.4.2 | 10.64.6.101 | ICMP |

      Wobei "Act" folgende Meldung anzeigt: @79 block drop in log quick all leble "Default deny rule

      Ich kann mir nur noch vorstellen, dass ich das Prinzip einer Firewall nicht verstanden habe, trotz erfolgreicher Watchguard-Schulungen (wenn das Projekt erfolgreich verläuft, sollen hier im eropäischen Netz die WGs komplett durch pfSense ersetzt werden). Daher würde ich mich freuen, wenn hier jemand mal seine Vermutungen und ggf. Lösungsansätze posten könnte.
      Falls ich Fragen offen gelassen habe, dann lasst es mich einfach wissen. Ich werde euch dann die benötigten Infos geben.

      Vielen Dank fürs Lesen und noch mehr wenn ihr mir antwortet!

      Gruß aus der schönsten Stadt der Welt

      Alex

      isn't there a jabber field in the profile?

      1 Reply Last reply Reply Quote 0
      • J
        jlepthien
        last edited by

        Welchen ICMP Type hast du denn explizit ausgewählt? Steht 'echo' drin?
        Ich würde deinen Test auch eher mit LAN und OPT Interface machen und nicht über WAN…

        Ich würde auch weiterhin die WatchGuards nutzen, die können wesentlich mehr! Vor allem seit der XTM 11!
        Wenn du eine WG konfigurieren kannst, wirst du über pfSense nur lachen.

        Default Gateway in beiden Netzen ist auch korrekt die pfSense Box?

        | apple fanboy | music lover | network and security specialist | in love with cisco systems |

        1 Reply Last reply Reply Quote 0
        • D
          deskdevil
          last edited by

          Hallo,

          ich habe zu Testzwecken bei ICMP-Type "any" ausgewählt.

          Wieso nicht über WAN? Ist es nicht so, dass WAN, LAN und OPT# einfach nur Namen sind und wenn ich alle Rules aus der Konfig nehme die Interfaces identisch sind?

          Naja unsere WGs laufen jetzt aus und wir werden die wohl nicht verlängern.
          alternativ sind ZL-Module für unsere HP Switche angedacht. Aber hier geht es ja um pfSense ;)

          Default GW ist beim 10.66.0.0/16 (10.66.4.0/24) ist ja nur ein Subnet die pfSense-Box bei dem 10.64.0.0/16 ist es ein Router, welcher alles für 10.66.0.0/16 auf das WAN Interface der pfSense-Bos leitet.

          isn't there a jabber field in the profile?

          1 Reply Last reply Reply Quote 0
          • J
            jlepthien
            last edited by

            Ich meinte nur weg vom WAN, damit auf jeden Fall keinerlei NAT Probleme kommen, auch wenn du es deaktiviert hast. Mach mal sonst Screenshot vom Regelwerk. Die Default Deny darf nur ziehen, wenn alles andere nicht zieht, also muss dort was falsch sein…

            | apple fanboy | music lover | network and security specialist | in love with cisco systems |

            1 Reply Last reply Reply Quote 0
            • D
              deskdevil
              last edited by

              anbei mal die Screenshots.

              fw_rules_1.png
              fw_rules_1.png_thumb
              fw_rules_2.png
              fw_rules_2.png_thumb

              isn't there a jabber field in the profile?

              1 Reply Last reply Reply Quote 0
              • J
                jlepthien
                last edited by

                Log mal mal via ssh oder console auf der Kiste ein und poste dann den Inhalt von /tmp/rules.debug hier her. Vielleicht kann man da sehen, warum die Regeln nicht greifen…

                | apple fanboy | music lover | network and security specialist | in love with cisco systems |

                1 Reply Last reply Reply Quote 0
                • M
                  MaxHeadroom
                  last edited by

                  Unter Wan gibt es einen Punkt (ganz unten) 'Block private networks'    disablen 
                  10.0.0.0/8 ist so ein Netz also auch dein Wan
                  mfg max

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