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

    VPN gleiches Netz + 1 statische Route?

    Deutsch
    5
    23
    4.3k
    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.
    • W
      Wexxler
      last edited by

      Guten Morgen,

      zeichne doch mal bitte deine Infrastrukur auf. Einwählen heisst Mobile Clients? Welches ist dann das Clientnetz?

      1 Reply Last reply Reply Quote 0
      • C
        cyberexpress
        last edited by

        Servus Wexxler,

        ich hoffe, man kann mein Vorhaben aus der Zeichnung erkennen.

        Client PC1 wählt sich von seinem lokalen Netzwerk aus ins Zielnetzwerk ein (openVPN) und bekommt dadurch eine 172.20.16.x IP zugewiesen. Ab diesen Zeitpunkt werden alle lokalen Verbindungen getrennt - dh Client PC1 kann so nicht mehr auf Client Drucker zugreifen.
        Client PC1 öffnet eine RDP zum PC1 (Zielnetzwerk) und soll von dort aus jetzt auf den Client Drucker etwas ausdrucken können.

        Wie oben beschrieben, ist das riesen Problem, dass die zwei Netzwerke den gleichen IP-Bereich nutzen. (Client und Zielnetzwerk) - deshalb musste ich die pfSense so konfigurieren, dass eben diese Verbindungen im Clientnetzwerk nicht mehr verwendet werden. (das kann ich auch leider nicht ändern). Nun die Frage, ob man hier etwas mit statischen Routen machen kann, oder ob es sonst eine Möglichkeit gibt? (ich kann auch keine pfSense im Client Netzwerk betreiben)

        liebe Grüße, CE

        nw.png
        nw.png_thumb

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

          Falls noch aktuell -

          Wenn dein Client sich über VPN einloggt, wird vom OpenVPN Client eine Route angelegt (Konfiguration)
          sieht man mit "route print" diese Route besagt, dass das Zielnetzwerk über die VPN-Verbindung erreichbar ist.

          Was du hier brauchst ist folgendes:

          Deaktivierung der automatischen Erstellung der Route durch OpenVPN
          Manuelle Route nur zum ZielPC mit route add 192.168.2.10 MASK 255.255.255.0 172.20.16.X

          Wobei jetzt X für die IP steht, welche der pfSense Firewall entspricht (innerhalb des Tunnelnetzes)

          Damit kommst du über VPN zu deinem ZielPC, der Rest in deinem LAN ist aber weiterhin ansprechbar. Richtig blöd wäre es dann, wenn dein Drucker auch die 192.168.2.10 hätte :)

          Damit du dir die manuelle Arbeit sparst, kannst du auch auf der FW in der OpenVPN Config unter "IPv4 Local Network/s" nur das eintragen: 192.168.2.10/32 - dann sollte alles hinhauen, hast halt nur Zugriff auf den RDP PC.

          1 Reply Last reply Reply Quote 0
          • C
            cyberexpress
            last edited by

            hallo hege,

            ist nach wie vor aktuell. Die Variante hat aber den Nachteil, dass ich dann für jeden client spezielle Routen benötige, damit alles sauber funktioniert, oder?
            Mein privates Netz ist leider etwas gängig.

            Habe mir was anderes überlegt:
            Ich kaufe einen WRT 54GL Router - der kann auch vpn Client spielen. Der Drucker kommt da dran - ich gebe dem Drucker eine IP aus dem Netzwerk vom Router (lokal) und spreche am Server den Drucker mit der openVPN IP an - sollte via NAT dann zum Drucker kommen und alles ist gut. Habe ich einen Denkfehler?

            Da wäre jetzt aber das nächste Problem:
            Auf der PFSense läuft bereits ein openVPN Server - die User müssen sich da mit Kennwörter zutätzlich anmelden. Das wird der Router nicht können. Demnach muss ich die Authentifizierung via Username und Password abdrehen, was ich eigentlich nicht möchte.

            Kann ich vielleicht einfach einen zweiten openVPN Server auf der gleichen pfSense laufen lassen für diesen Client ohne user/pass Authentifizierung?

            lg.

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

              sofern du über vpn nur zu deinem Drucker willst (bzw. auch deine anderen clients) ist die einfachste Lösung wohl diese:

              "Damit du dir die manuelle Arbeit sparst, kannst du auch auf der FW in der OpenVPN Config unter "IPv4 Local Network/s" nur das eintragen: 192.168.2.10/32 - dann sollte alles hinhauen, hast halt nur Zugriff auf den RDP PC."

              Was den Rest angeht: ich würd mir eher einen zweiten VPN Eintrag nur für mich einrichten (anderer Port), ehe ich mit nem zweiten Router anfange…

              1 Reply Last reply Reply Quote 0
              • C
                cyberexpress
                last edited by

                Servus,

                "Damit du dir die manuelle Arbeit sparst, kannst du auch auf der FW in der OpenVPN Config unter "IPv4 Local Network/s" nur das eintragen: 192.168.2.10/32 - dann sollte alles hinhauen, hast halt nur Zugriff auf den RDP PC."

                Wenn beide Netze im Bereich 192.168.2.x sitzen (Ziel und Quelle) dann ist doch nie Sichergestellt, dass die Pakete in dem Netz ankommen, wo sie hingehören, oder?

                lg.

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

                  Es gibt bei den Routen eine Metrik, welche die Priorität der Route bezeichnet.

                  Der Default Gateway hat normalerweise sagen wir mal Metrik 1000, während jede manuell hinzugefügte Route Metrik 100 hat. (Die über OpenVPN übermittelte hat etwa 100)

                  Dadurch gibt es kein Chaos.

                  1 Reply Last reply Reply Quote 0
                  • C
                    cyberexpress
                    last edited by

                    Servus!

                    ich fürchte, du hast die Zeichnung falsch aufgefasst. (oder ich habs immer noch nicht verstanden) :-)

                    Ich wähle mich vom Client PC1 (Rechts in der Zeichnung) in mein Zielnetzwerk ein, und bekomme die IP 172.20.16.10 zugewiesen. Ich verbinde mich dann via RDP zum PC1 (im Zielnetzwerk IP: 192.168.2.10).
                    Das war die rote Linie.

                    Jetzt öffne ich Word auf PC1 (Zielnetzwerk) und möchte auf den Client Drucker (Client Netzwerk, also rechts) auf die IP 192.168.2.40 drucken. (der Weg war die blaue Linie)

                    Kannst du mir deine Lösung, falls der Ansatz noch immer der gleiche ist, mit den IPs entsprechend beschreiben, wie das funktionieren sollte?

                    Die pfSense ist derzeit so eingestellt, dass die Verbindungen zu den lokalen Netzwerkgeräten verloren geht nach der VPN Einwahl, weil eben Ziel und Quelle im gleichen Netzbereich sind und ich Probleme mit dem Routing hatte, wenn ich am Ziel geräte erreichen wollte, und das System teils glaubte, die Geräte in meinem lokalen Netz finden zu können.

                    lg.

                    1 Reply Last reply Reply Quote 0
                    • jahonixJ
                      jahonix
                      last edited by

                      Wie soll denn ein Host links einen Host von rechts durch ein Transit-Netzwerk erreichen, wenn auf beiden Seite das gleiche Netzwerk vorliegt?
                      In dem Fall wird der Traffic nicht durch das Gateway geschickt, weil die Auflösung lokal funktioniert (egal, ob die IP dort auch vorhanden ist oder nicht).

                      Zwei Möglichkeiten:
                      a) Du bridgest beide Seiten
                      b) eine Seite erhält ein anderes Subnetz und mindestens das GW kennt die Route.

                      c) …da war mal was, so dass OpenVPN zwei Netze gleicher Range miteinander bringen konnte. IIRC!
                      Suche mal danach hier im Forum.

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

                        Du bringst hier etwas durcheinander.

                        Links = VPN / Rechts = LAN

                        Du wählst dich von Rechts über OpenVPN ein. Anschließend verbindest du dich über RDP auf Links und möchtest dort drucken. -> Links kann aber nicht direkt auf den Drucker rechts zugreifen, da nur rechts nach links eine Verbindung aufgebaut hat, aber nicht umgekehrt (das wäre Site2Site)
                        D.h. Links erreicht den Drucker rechts über RDP, damit das funktioniert muss Rechts trotz vorhanderer VPN Verbindung immer noch auf das restliche rechts-netz zugreifen müssen, und hier beginnt dein Problem.

                        Du hast in deiner OpenVPN Konfiguration unter "IPv4 Local Network/s" 192.168.2.0/24 stehen, dadurch kann rechts, sobald die vpn Verbindung aufgebaut ist nicht mehr auf das restliche Netz zugreifen, da du beim Verbindungsaufbau eine höherwertigere Route durch OpenVPN eingetragen wird.

                        Stellst du stattdessen ein "IPv4 Local Network/s" 192.168.2.10/32 und verbindest du dich über VPN, so erreichst du Links und kannst aber immer noch auf das restliche Rechts zugreifen (ausgenommen 192.168.2.10) -> Problem gelöst.

                        Verstanden?

                        1 Reply Last reply Reply Quote 0
                        • jahonixJ
                          jahonix
                          last edited by

                          @hege:

                          Du bringst hier etwas durcheinander.
                          Links = VPN / Rechts = LAN

                          Damit betrachtest Du nur die Hälfte der Schilderung und somit auch nicht das Problem.

                          local-left  192.168.2.0/24
                          local-right 192.168.2.0/24
                          transit 172.20.16.0/24

                          Der RDP-Client (rechts) bekommt als Option mit, zB lokale Drucker an den RDP-Host (links) weiterzureichen.
                          Der Host (links) wird diesen Drucker aber nie erreichen können, da die Adresse des Druckers gleichfalls in seiner Broadcast-Domain liegt.
                          Als Lösung bietet sich ein Bridging beider Seiten an oder unterschiedliche Netze links und rechts. Dann kann zwischen beiden geroutet werden.
                          Wenn Du dem RDP-Client (rechts) eine /32  lokal gibst, dann wird er seinen lokalen Drucker selbst nicht mehr erreichen können.

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

                            @jahonix:

                            Der RDP-Client (rechts) bekommt als Option mit, zB lokale Drucker an den RDP-Host (links) weiterzureichen.
                            Der Host (links) wird diesen Drucker aber nie erreichen können,

                            Bei einer RDP Verbindung hat links keine direkte Verbindung zum Drucker Rechts, sondern der RDP-Client (rechts) spielt den Druckserver und reicht die Druckjobs an den Drucker im lokalen Netzwerk weiter.
                            Schonmal versucht einen lokalen LPT Drucker über RDP durchzureichen? Das funktioniert genauso, obwohl der LPT Drucker nicht über IP erreichbar ist.

                            Wie bereits mehrfach ausgeführt besteht das "Problem" lediglich darin, dass bei vorhandener VPN Verbindung der Client (rechts) nicht mehr auf sein restlichen LAN Netz zugreifen kann, da nach erfolgreichem Verbindungsaufbau der Client (rechts) das Netz 192.168.2.0/24 über VPN erreichen will und der Drucker (rechts) aber im lokalen Netz liegt.

                            Bitte erkläre mir wieso deiner Meinung nach bei einer 32er Route der lokale Drucker nicht mehr angesprochen werden kann?

                            Bitte einfach mal ausprobieren bevor du Bridging empfiehlst, welches nur jede Menge Schrotttraffic verursacht und die Leitung ev. lahm legt.

                            1 Reply Last reply Reply Quote 0
                            • C
                              cyberexpress
                              last edited by

                              Hallo Leute,

                              ist schon etwas länger her - eber das Problem habe ich immer noch nicht lösen können.
                              Ich habe die Variante mit dem "durchreichen" der Druckerverbindung via RDP schon ausprobiert. Das hat auch schon so geklappt. Allerdings musste ich dafür ziemlich viel konfigurieren, auch in den Rechten wegen dem Druckertreiber. Ich will dem User, der sich da einwählt nicht alle Rechte geben. Nun wurde ein Systemwiederherstellungspunkt ausgewählt auf dem pc und alles beginnt von vorne. Deshalb will ich das jetzt richtig machen.

                              Nach einer Woche Recherche und vielen Stunden probieren, habe ich jetzt meinen WRT54GL mit der Tomato Firmware als VPN Client verwenden können. Die Einwahl klappt, er bekommt eine IP und ist auch vom VPN Netz erreichbar. Der Plan war jetzt, dass ich ein Port Forwarding mache - also vom VPN Netz zum Drucker:

                              SRC: TCP 9100 TARGET: TCP 9100 IP: 192.168.2.240

                              Nun habe ich aber festgestellt, dass der Router im Netzwerk nicht mehr erreichbar ist, sobald ich den WAN Port anstecke.

                              Konfiguration:

                              WAN: DHCP -> 192.168.2.148/24 -> openVPN IP: 172.20.0.18
                              LAN: STATIC -> 192.168.2.250/24

                              Wenn ich das Kabel an WAN nicht anstecke, wird die VPN Verbindung nicht aufgebaut und der Router ist ganz normal unter der 192.168.2.250 erreichbar. Sobald die Verbindung zum VPN Server aufgebaut wird, ist er weg.

                              Hat jemand eine Idee, woran das liegt? Hat doch das eine mit dem anderen nichts zu tun?!

                              lg.

                              1 Reply Last reply Reply Quote 0
                              • C
                                cyberexpress
                                last edited by

                                hier nochmal zur Verdeutlichung

                                VPN.png_thumb
                                VPN.png

                                1 Reply Last reply Reply Quote 0
                                • jahonixJ
                                  jahonix
                                  last edited by

                                  Kann es sein, dass Du Dir mit dem Kabel am WAN einen lokalen Ring aufbaust?
                                  Entweder legst Du Dein Netzwerk mit einem Broadcast-Storm lahm oder ein konfiguriertes Spanning-Tree verhindert das (und auch die gewünschte Kommunikation). Ich kann den X2000 und seine Anschlüsse nicht wirklich erkennen.

                                  Was ist eigentlich ein "Splitter" und warum ändert Du nicht auf einer der Seiten das Subnetz, dann ist die Konfiguration ganz simpel?

                                  1 Reply Last reply Reply Quote 0
                                  • C
                                    cyberexpress
                                    last edited by

                                    Hallo Jahonix,

                                    Kann es sein, dass Du Dir mit dem Kabel am WAN einen lokalen Ring aufbaust?

                                    • WAN und LAN des WRT54GL hängen quasi zusammen an den LAN Ports des X2000. Also nehme ich an, dass es das ist, was du meinst? Ist das ein Problem?

                                    Entweder legst Du Dein Netzwerk mit einem Broadcast-Storm lahm oder ein konfiguriertes Spanning-Tree verhindert das (und auch die gewünschte Kommunikation). Ich kann den X2000 und seine Anschlüsse nicht wirklich erkennen.

                                    • Welche weiteren Informationen brauchst du, um mehr darüber sagen zu können? der X2000 verbindet mich ins Internet. Der WRT54GL hängt einfach nur im Netz für den Test.

                                    Was ist eigentlich ein "Splitter" und warum ändert Du nicht auf einer der Seiten das Subnetz, dann ist die Konfiguration ganz simpel?

                                    • Ein Splitter splittet die Frequenzen zwischen Telefon und Internet auf. Bei DSL ist das doch üblich?
                                    • Das mit dem Subnetz bringt mich nur einen halben Meter weiter. Ich kann mir die Netzwerke, von denen sich andere VPN Clients einwählen nicht aussuchen. Da schien mir die Sache mit dem Router die sauberste Lösung, wenn es dann mal funktionieren würde :-)

                                    Habe ich einen Denkfehler?!

                                    Habe gerade etwas anderes versucht: Habe den WRT54GL komplett vom Netzwerk genommen. WAN Steckt jetzt am LAN vom X2000 und mein Notebook ist direkt mit dem WRT54GL am LAN Port verbunden. Sobald der Stecker im WAN ist, ist der WRT54GL am LAN nicht mehr erreichbar. Dafür muss es doch eine Lösung geben? Im jetztigen Fall sind WAN und LAN in keinem Fall verbunden!

                                    lg.

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

                                      • WAN und LAN des WRT54GL hängen quasi zusammen an den LAN Ports des X2000. Also nehme ich an, dass es das ist, was du meinst? Ist das ein Problem?

                                      Ja. Ist es. Zwei Ports am gleichen Switch mit gleichen IP Ranges funktionieren nicht, weil das Gerät nur über eines sprechen kann, nicht über beide, da er nicht weiß welcher Port Vorrang hat. Zudem baust du dann noch einen Ring auf, was gar nicht geht und normalerweise dazu führt, dass eine entsprechende Erkennung einen der Ports Not-abschaltet.

                                      Und ja ein SPlitter trennt Telefon und DSL. Bei altem DSL zumindest, richtig. Aber welches Gerät baut dann die Internetverbindung auf? Denn an einen Splitter einen Switch zu hängen macht eigentlich nur in ganz wenigen Szenarien Sinn.

                                      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
                                      • C
                                        cyberexpress
                                        last edited by

                                        Servus,

                                        ich kann doch zwei verschiedene Netzwerke an einen Switch hängen? (ohne DHCP war das bei mir noch nie ein Problem?)
                                        In meinem letzten Szenario habe ich den Fall nicht mehr.

                                        Notebook -> WRT54GL(LAN) -> WRT54GL(WAN) -> X2000(LAN) -> X2000(WAN) -> Splitter …..

                                        Also der X2000 macht die Einwahl. Und auf dem WRT54GL wird die VPN Verbindung zu einem Server aufgebaut.
                                        Auch wenn ich jetzt keinen Ring mehr habe und auch nicht mehr beide Ports an einem Switch habe, ist die LAN Adresse des WRT54GL nicht mehr erreichbar, sobald das Gerät eine VPN Verbindung erfolgreich aufgebaut hat. Wenn ich das LAN Kabel zum Notebook ab und wieder anstecke, ist der Router wieder kurz erreichbar. Beim Anstecken wird die VPN Verbindung getrennt und dann gleich wieder aufgebaut, dann ist der Router wieder nicht erreichbar.

                                        Redirect internet traffic is der Haken raus. Willst du es dir mal live ansehen? (Skype & Teamviewer?)
                                        -> für die anderen, werde ich natürlich das Resultat hier posten!

                                        lg.

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

                                          Nochmal: Wenn du auf WAN und LAN Seite das gleiche IP Subnetz benutzt wird das nicht funktionieren!

                                          Zitat:

                                          WAN: DHCP -> 192.168.2.148/24 -> openVPN IP: 172.20.0.18
                                          LAN: STATIC -> 192.168.2.250/24

                                          –> beide Netzteile sind im gleichen /24 Netz 192.168.2.x --> das darf nicht sein.

                                          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
                                          • C
                                            cyberexpress
                                            last edited by

                                            Servus,

                                            ja - da ist wohl was wahres dran :-)
                                            Jetzt ist er zumindest mal im VPN Netz und im LAN erreichbar. Das NAT will nur noch nicht. Bin mit iptables nicht noch nicht ganz auf Kurs:

                                            Hier der Output von ifconfig:

                                            br0        Link encap:Ethernet  HWaddr 20:AA:4B:22:7E:1E 
                                                      inet addr:192.168.1.250  Bcast:192.168.1.255  Mask:255.255.255.0
                                                      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                                                      RX packets:3723 errors:0 dropped:0 overruns:0 frame:0
                                                      TX packets:1399 errors:0 dropped:0 overruns:0 carrier:0
                                                      collisions:0 txqueuelen:0 
                                                      RX bytes:638159 (623.2 KiB)  TX bytes:678375 (662.4 KiB)

                                            eth0      Link encap:Ethernet  HWaddr 20:AA:4B:22:7E:1E 
                                                      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                                                      RX packets:6966 errors:0 dropped:0 overruns:0 frame:0
                                                      TX packets:1815 errors:0 dropped:0 overruns:0 carrier:0
                                                      collisions:0 txqueuelen:1000 
                                                      RX bytes:1419031 (1.3 MiB)  TX bytes:739037 (721.7 KiB)
                                                      Interrupt:4 Base address:0x1000

                                            eth1      Link encap:Ethernet  HWaddr 20:AA:4B:22:7E:20 
                                                      UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
                                                      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
                                                      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
                                                      collisions:0 txqueuelen:1000 
                                                      RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
                                                      Interrupt:13 Base address:0x5000

                                            lo        Link encap:Local Loopback 
                                                      inet addr:127.0.0.1  Mask:255.0.0.0
                                                      UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
                                                      RX packets:22 errors:0 dropped:0 overruns:0 frame:0
                                                      TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
                                                      collisions:0 txqueuelen:0 
                                                      RX bytes:1622 (1.5 KiB)  TX bytes:1622 (1.5 KiB)

                                            tun11      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
                                                      inet addr:172.20.0.18  P-t-P:172.20.0.17  Mask:255.255.255.255
                                                      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
                                                      RX packets:62 errors:0 dropped:0 overruns:0 frame:0
                                                      TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
                                                      collisions:0 txqueuelen:100 
                                                      RX bytes:3848 (3.7 KiB)  TX bytes:3984 (3.8 KiB)

                                            vlan0      Link encap:Ethernet  HWaddr 20:AA:4B:22:7E:1E 
                                                      UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
                                                      RX packets:3726 errors:0 dropped:0 overruns:0 frame:0
                                                      TX packets:1399 errors:0 dropped:0 overruns:0 carrier:0
                                                      collisions:0 txqueuelen:0 
                                                      RX bytes:653593 (638.2 KiB)  TX bytes:683971 (667.9 KiB)

                                            vlan1      Link encap:Ethernet  HWaddr 20:AA:4B:22:7E:1F 
                                                      inet addr:192.168.2.121  Bcast:192.168.2.255  Mask:255.255.255.0
                                                      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                                                      RX packets:3240 errors:0 dropped:0 overruns:0 frame:0
                                                      TX packets:416 errors:0 dropped:0 overruns:0 carrier:0
                                                      collisions:0 txqueuelen:0 
                                                      RX bytes:640050 (625.0 KiB)  TX bytes:55066 (53.7 KiB)

                                            iptables -L gibt folgendes aus:

                                            Chain INPUT (policy DROP)
                                            target    prot opt source              destination         
                                            ACCEPT    all  –  anywhere            anywhere           
                                            DROP      all  --  anywhere            192.168.2.121       
                                            DROP      all  --  anywhere            anywhere            state INVALID 
                                            ACCEPT    all  --  anywhere            anywhere            state RELATED,ESTABLISHED 
                                            ACCEPT    all  --  anywhere            anywhere           
                                            ACCEPT    all  --  anywhere            anywhere           
                                            ACCEPT    icmp --  anywhere            anywhere            limit: avg 1/sec burst 5 
                                            ACCEPT    udp  --  anywhere            anywhere            udp dpts:33434:33534 limit: avg 5/sec burst 5 
                                            ACCEPT    udp  --  anywhere            anywhere            udp spt:bootps dpt:bootpc

                                            Chain FORWARD (policy DROP)
                                            target    prot opt source              destination         
                                            ACCEPT    all  --  anywhere            anywhere           
                                            ACCEPT    all  --  anywhere            anywhere

                                            Chain OUTPUT (policy ACCEPT)
                                            target    prot opt source              destination

                                            Chain upnp (0 references)
                                            target    prot opt source              destination

                                            Chain wanin (0 references)
                                            target    prot opt source              destination         
                                            ACCEPT    tcp  --  172.20.0.18          192.168.1.240      tcp dpt:laserjet 
                                            ACCEPT    tcp  --  172.20.0.18          192.168.1.240      tcp dpt:www

                                            Chain wanout (0 references)
                                            target    prot opt source              destination

                                            In der Anlage habe ich meine derzeitigen NAT Regeln angehängt. Aber ich kann da auch keinen VPN Adapter auswählen. :-(

                                            ![Bildschirmfoto 2014-12-27 um 18.42.33.png](/public/imported_attachments/1/Bildschirmfoto 2014-12-27 um 18.42.33.png)
                                            ![Bildschirmfoto 2014-12-27 um 18.42.33.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2014-12-27 um 18.42.33.png_thumb)

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