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

    Nur Teilnetz über OpenVPN erreichbar

    Scheduled Pinned Locked Moved Deutsch
    13 Posts 4 Posters 3.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.
    • M
      mimu
      last edited by

      Hallo.
      Situation:
      Habe pfSense auf einem Alix Board installiert, an einem Lanport hängt der DSL-Router, am anderen der Switch für das interne Netz. Das interne Netz ist 172.29.0.0/16, von diesem Netz komme ich ins Internet, wenn ich am Switch hänge, bekomme ich von pfSense eine Ip-Adresse (DHCP) und ich kann pfSense auf 172.29.1.254, sowie clients auf 172.29.1.1, 172.29.1.2, 172.29.2.1, 172.29.1.100, 172.29.3.1, 172.29.3.2 usw. pingen.

      Problem:
      Verbinde ich mich allerdings über OpenVPN von aussen, erreiche ich pfSense und das Webinterface, ich kann 172.29.1.1, 172.29.1.2, 172.29.2.1 pingen und erreichen, allerdings nicht 172.29.3.1, 172.29.3.2, 172.29.1.100. Woran kann das liegen? Welche Einstellung sollte ich checken?

      In den Logs finden sich keine Einträge über blockierte Pakete. Das selbe Problem hatte ich mit einer pptp Verbindung….
      Die Einstellungen von OpenVPN: Tunnel Network: 172.30.1.0/24  Local Network 172.29.0.0/16  Concurrent Connections 3

      Danke!

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

        Ein /16er Netz spricht für eine große Ansammlung von Endgeräten. Da du aber nichts über den Aufbau des internen Netzes gesagt hast, ist ein Debugging schwierig. Wenn man per VPN verbunden ist, müsste auch die Route gepusht werden. Ist das der Fall? Zum Test einfach mal bei bestehendem VPN ein:

        route -n

        bzw.

        netstat -rn

        bzw.

        route print

        (je nach System)

        ausführen und sich die Routingtabelle anzeigen lassen. Ist dort das 172.29/16er Netz sauber auf den VPN Endpoint geroutet?
        Dann kanns weitergehen mit Fehlersuche. Ich vermute allerdings eher das Problem im LAN und dass hier nicht sauber geroutet wird bzw. die Endgeräte entweder falsche Netzmaske, Routing oder Gateway haben.

        Grüßend

        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
        • M
          mimu
          last edited by

          Hallo JeGr.
          Danke für deine Antwort!

          Das Netz ist jetzt nicht wahnsinnig groß, das dritte Oktett wird aber für eine räumliche Einteilung verwendet.
          Die Endgeräte haben alle 172.29.1.254 als Gateway eingetragen, Subnetzmaske 255.255.0.0.
          Per Ping auf den Interface Richtung Switch kann ich alle erreichen.

          Nach geöffneter VPN-Verbindung wir auf dem entfernten Computer die Route zu 172.29.0.0  255.255.0.0 über Gateway 172.30.1.5 und Schnittstelle 172.30.1.6 eingetragen.

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

            Das sieht dann aber soweit alles OK aus.

            Wie sieht es denn bei nem Traceroute aus auf Systeme die nicht erreicht werden können?

            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
            • M
              mimu
              last edited by

              Von über VPN verbundenen Rechner auf erreichbares Endgerät:
              C:\Users\Michael>tracert 172.29.1.1

              Routenverfolgung zu 172.29.1.1 über maximal 30 Hops

              1  189 ms  216 ms  147 ms  172.30.1.1
                2  166 ms  147 ms  150 ms  172.29.1.1

              Ablaufverfolgung beendet.

              Auf nicht erreichbares Endgerät:
              C:\Users\Michael>tracert 172.29.3.1

              Routenverfolgung zu 172.29.3.1 über maximal 30 Hops

              1  166 ms  137 ms  157 ms  172.30.1.1
                2    *        *        *    Zeitüberschreitung der Anforderung.
                3    *        *        *    Zeitüberschreitung der Anforderung.
                4    *        *        *    Zeitüberschreitung der Anforderung.
                5    *        *

              Dazugehöriger Packet-Capture in pfSense auf dem LAN Interface:
              20:39:31.055126 IP 172.30.1.6.137 > 172.29.1.1.137: UDP, length 50
              20:39:31.055414 IP 172.29.1.1 > 172.30.1.6: ICMP 172.29.1.1 udp port 137 unreachable, length 86
              20:39:32.554966 IP 172.30.1.6.137 > 172.29.1.1.137: UDP, length 50
              20:39:32.555233 IP 172.29.1.1 > 172.30.1.6: ICMP 172.29.1.1 udp port 137 unreachable, length 863
              20:39:34.058993 IP 172.30.1.6.137 > 172.29.1.1.137: UDP, length 50
              20:39:34.059238 IP 172.29.1.1 > 172.30.1.6: ICMP 172.29.1.1 udp port 137 unreachable, length 86
              20:39:41.385915 IP 172.30.1.6 > 172.29.1.1: ICMP echo request, id 1, seq 206, length 72
              20:39:41.386128 IP 172.29.1.1 > 172.30.1.6: ICMP echo reply, id 1, seq 206, length 72
              20:39:41.521699 IP 172.30.1.6 > 172.29.1.1: ICMP echo request, id 1, seq 207, length 72
              20:39:41.521900 IP 172.29.1.1 > 172.30.1.6: ICMP echo reply, id 1, seq 207, length 72
              20:39:41.660324 IP 172.30.1.6 > 172.29.1.1: ICMP echo request, id 1, seq 208, length 72
              20:39:41.660530 IP 172.29.1.1 > 172.30.1.6: ICMP echo reply, id 1, seq 208, length 72
              20:39:41.810014 IP 172.30.1.6.137 > 172.29.1.1.137: UDP, length 50
              20:39:41.810253 IP 172.29.1.1 > 172.30.1.6: ICMP 172.29.1.1 udp port 137 unreachable, length 86
              20:39:43.308242 IP 172.30.1.6.137 > 172.29.1.1.137: UDP, length 50
              20:39:43.308488 IP 172.29.1.1 > 172.30.1.6: ICMP 172.29.1.1 udp port 137 unreachable, length 86
              20:39:44.805899 IP 172.30.1.6.137 > 172.29.1.1.137: UDP, length 50
              20:39:44.806218 IP 172.29.1.1 > 172.30.1.6: ICMP 172.29.1.1 udp port 137 unreachable, length 86

              Wenn ich das richtig erkenne, kommt die Anfrage an die 172.29.3.1 gar nicht durch pfSense?

              1 Reply Last reply Reply Quote 0
              • N
                Nachtfalke
                last edited by

                Prüfe, dass du keine Subnetzkonflikte hast mit dem Subnetz, aus welchem der VPN-Client die Verbindung aufbaut.
                Prüfe, dass du am OpenVPN Server die passende Subnet-Mask /16 angegeben hast und dich nicht vertippt hast.
                Prüfe, dass du an der pfsense Firewall für das Tunnel-Netzwerk den Traffic erlaubst.
                Prüfe, dass die Clients im LAN 172.29.x.x auf der pfsense LAN Schnittstelle/Firewall die Erlaubnis haben, Daten ins das VPN zu senden.
                Prüfe, dass die Clients im LAN auch auf der Windows-Firewall und/oder den Virenscanner eingehende Pakete aus dem Tunnel-Netzwerk erlauben.

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

                  Ich muss Nachtfalke zustimmen, da aus deinem Packet Capture kein einziges Paket an die .3.1 rausging, scheint mir da irgendwo ein Routing oder eine Netzmaske nicht zu stimmen. Oder es überlappen sich Netze.

                  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
                  • O
                    orcape
                    last edited by

                    Hi,

                    als erstes würde ich mal eine klare Trennung zwischen VPN-Netz und LAN vornehmen.
                    Allein schon der Übersichtlichkeit wegen, vergib für den Tunnel z.B. ein…
                    10.15.8.0/24
                    ...Netz oder so, da blickt doch bei einer Fehlersuche keiner mehr durch, wenn alles 172.X.X.X ist.
                    Es fehlt eigentlich nur noch ein 172.er Netz am Tunnelende... :-
                    Du scheinst es ja gerne kompliziert zu haben...;-)
                    Für den Rest kann man Nachtfalke nur Recht geben.

                    Gruß orcape

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

                      Hallo. Bin dem Problem denke ich etwas näher gekommen.
                      Es muss sich um eine Einstellung an pfSense handeln, nicht bei OpenVPN, da ich auch mit einer statischen Route an einem PC über ein Netz am dritten Lan-Port genau das selbe Problem habe. Weiteres packet tracing hat gezeigt, dass die Pakete an bestimmte Adressen im Netz 172.29.0.0 nicht an den Richtigen Lan-Port bzw. gar nicht weitergeleitet werden.
                      Wie kann ich pfSense sagen, dass der gesamte Traffic nach 172.29.0.0 an Lan-Port 2 gehen soll?

                      Danke.

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

                        Wenn die pfSense selbst mit ihrem Interface an LAN Port 2 eine Adresse aus dem Netz hat, muss (darf) man gar nichts tun, dann steht das genau so in der Routing Tabelle. Evtl. mal die Routing Table der pfsense im Diag Menü ansehen, ob da was auffällig ist.

                        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
                        • M
                          mimu
                          last edited by

                          In der Routing Tabelle habe ich folgenden Eintrag: 172.29.0.0/16 link#1 U 0 30619 1500 vr0

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

                            Sofern vr0 der genannte LAN Port 2 ist, liegt damit das Netz genau dort auch völlig korrekt an. Ist er das nicht, hast du die Ports / Interfaces vielleicht falsch zugewiesen oder konfiguriert?

                            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
                            • M
                              mimu
                              last edited by

                              So, das Problem ist gelöst: Es lag am eingeschalteten Captive Portal auf dem 172.29.0.0/16 Netz. Nur Clients mit Passtrough über die Mac-Adresse lassen sich erreichen.
                              Danke allen für die Mühe und Hilfe

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