VPN gleiches Netz + 1 statische Route?



  • Hallo Jungs,

    ich brauch mal eure Hilfe - ich steh etwas aufm Schlauch  :-[

    Ich habe eine pfSense laufen. (Netzwerk 192.168.2.0/24) (Transportnetz 172.20.16.0/24)
    Es gibt in diesem Netzwerk einen Server, der als Gateway die pfSense eingetragen hat. Wenn ich mich aus einem anderen Netzwerk dort einwähle, kann ich den Server problemlos erreichen. Weil ich mich aus dem Client Netz ebenfalls im gleichen Netz (192.168.2.0/24) befinde, habe ich die pfSense damals so konfiguriert, dass ich die Geräte im Clientnetzwerk nicht mehr erreichen kann. Funktioniert bis zu diesem Punkt alles Problemlos.

    ABER:

    Jetzt bekomm ich in dem Clientnetzwerk einen Netzwerkdrucker. Ich muss den irgendwie vom Zielnetzwerk aus erreichen können, wenn ich mich mit dem Client einwähle und eine RDP auf dem Server öffne. Welche Ansätze gibts hier theoretisch? Und vor allem was muss ich wie konfigurieren, dass das überhaupt funktionieren kann?

    Freue mich über gute Inputs!

    Liebe Grüße, CE



  • Guten Morgen,

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



  • 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




  • 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.



  • 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.



  • 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…



  • 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.



  • 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.



  • 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.



  • 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.



  • 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?



  • @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.



  • @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.



  • 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.



  • hier nochmal zur Verdeutlichung




  • 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?



  • 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.


  • LAYER 8 Moderator

    • 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.



  • 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.


  • LAYER 8 Moderator

    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.



  • 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)


  • LAYER 8 Moderator

    IPTables? Screenshot? Huh? Was hat das da denn mit pfSense zu tun? verwirrt



  • Hallo,

    ja - hast du natürlich recht :-) Dachte man könnte das vielleicht noch als angrenzendes Gebiet betrachten. Ich habe es mittlerweile gelöst. Für die Allgemeinheit wie Versprochen:

    iptables -t nat -I PREROUTING -i tun11 -p tcp –dport 9100 -j DNAT --to-destination 192.168.1.240

    Das war die Lösung. Alles was vom VPN Netz an Port 9100 sendet, wird an 192.168.1.240 weitergeleitet.
    Die Konfiguration unter Portforwarding in der Tomatofirmware hat keinen Einfluss darauf! Habe diese wieder gelöscht

    liebe Grüße und Danke für die Unterstützung bei den anderen Fragen!


Log in to reply