11
Netzwerk-Traffic auf weitere Fritzbox routen
Hallo zusammen,
ich habe zuhause eine Fritzbox (6591 Cable im Netz 192.168.0.x; FB hat 192.168.0.3) und im Office habe ich ein Konstrukt mit 2 Internetanbietern, um eine Ausfallsicherheit zu gewährleisten. Falls DSL ausfällt, soll auf Mobilfunk zurückgegriffen werden.
Daher habe ich dort die Fritzbox 7530 (192.168.7.1 bzw. 192.168.7.x), direkt danach kommt der Multi-WAN-Router TP Link TL-ER7206 (192.168.5.1) der dann die ganzen Devices mit IP-Adresse im Bereich 192.168.5.x versorgt.
Zwischen beiden Fritzboxen habe ich die VPN-Verbindung schon konfiguriert. Die funktioniert auch.
Jetzt würde ich gerne im TP Link Router sagen, dass der Traffic zur Fritzbox von zuhause (zunächst erstmal nur die IP-Adresse 192.168.0.3) über WAN1 und damit an die FB 7530 geroutet wird.
Eigentlich dachte ich, dass es einfach wäre und habe eine statische Route in TP Link angegeben:
Destination IP: 192.168.0.3
Subnet Mask: 255.255.255.255
Next Hop: 192.168.7.1
Interface: WAN (= das o.g. WAN1)
Metric: 0
das WAN1 ist Connected und der TP Link Router hat die IP 192.168.7.22, Subnet Mask 255.255.255.0, Gateway 192.168.7.1, Primary DNS 192.168.7.1 bekommen
wenn ich jetzt allerdings ein Tracert in der Eingabeaufforderung ausführe, kommen folgende IP-Adressen in der Reihenfolge: 192.168.5.1 -> 169.254.11.21
danach Zeitüberschreitung der Anforderung.
Was das Ganze ein bissl erschwert ist sicherlich eine eingerichtete VPN-Verbindung auf dem TP Link zu einem Server in Frankfurt, der ebenfalls in 192.168.0.0/24 ist.
Aber ich dachte eben, dass ich mit der statischen Route dies umgehe und zumindest die 192.168.0.3 nach Hause routen kann. Aber scheinbar wird der Ping trotzdem ins VPN geschickt.
Hat jemand eine Idee, wie hier vorgehen könnte?
LG
Marc
ich habe zuhause eine Fritzbox (6591 Cable im Netz 192.168.0.x; FB hat 192.168.0.3) und im Office habe ich ein Konstrukt mit 2 Internetanbietern, um eine Ausfallsicherheit zu gewährleisten. Falls DSL ausfällt, soll auf Mobilfunk zurückgegriffen werden.
Daher habe ich dort die Fritzbox 7530 (192.168.7.1 bzw. 192.168.7.x), direkt danach kommt der Multi-WAN-Router TP Link TL-ER7206 (192.168.5.1) der dann die ganzen Devices mit IP-Adresse im Bereich 192.168.5.x versorgt.
Zwischen beiden Fritzboxen habe ich die VPN-Verbindung schon konfiguriert. Die funktioniert auch.
Jetzt würde ich gerne im TP Link Router sagen, dass der Traffic zur Fritzbox von zuhause (zunächst erstmal nur die IP-Adresse 192.168.0.3) über WAN1 und damit an die FB 7530 geroutet wird.
Eigentlich dachte ich, dass es einfach wäre und habe eine statische Route in TP Link angegeben:
Destination IP: 192.168.0.3
Subnet Mask: 255.255.255.255
Next Hop: 192.168.7.1
Interface: WAN (= das o.g. WAN1)
Metric: 0
das WAN1 ist Connected und der TP Link Router hat die IP 192.168.7.22, Subnet Mask 255.255.255.0, Gateway 192.168.7.1, Primary DNS 192.168.7.1 bekommen
wenn ich jetzt allerdings ein Tracert in der Eingabeaufforderung ausführe, kommen folgende IP-Adressen in der Reihenfolge: 192.168.5.1 -> 169.254.11.21
danach Zeitüberschreitung der Anforderung.
Was das Ganze ein bissl erschwert ist sicherlich eine eingerichtete VPN-Verbindung auf dem TP Link zu einem Server in Frankfurt, der ebenfalls in 192.168.0.0/24 ist.
Aber ich dachte eben, dass ich mit der statischen Route dies umgehe und zumindest die 192.168.0.3 nach Hause routen kann. Aber scheinbar wird der Ping trotzdem ins VPN geschickt.
Hat jemand eine Idee, wie hier vorgehen könnte?
LG
Marc
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 667138
Url: https://administrator.de/contentid/667138
Printed on: April 18, 2024 at 08:04 o'clock
11 Comments
Latest comment
Moin,
ich würde empfehlen, zuhause ein anderes Netz zu verwenden. Gerade wegen der VPN-Themen würde ich da immer etwas extravaganteres nehmen.
Vermutlich übersteuert der VPN-Client deine statische Route, daher stehen die Karten da eher schlecht. Kannst du ja mal probieren, indem du die VPN-Verbindung deaktivierst…
VG
ich würde empfehlen, zuhause ein anderes Netz zu verwenden. Gerade wegen der VPN-Themen würde ich da immer etwas extravaganteres nehmen.
Vermutlich übersteuert der VPN-Client deine statische Route, daher stehen die Karten da eher schlecht. Kannst du ja mal probieren, indem du die VPN-Verbindung deaktivierst…
VG
Also das Paket kommt ja schon mal beim TP-Link 5.1 an. Dieser verwirft es dann offenbar, ignoriert also Dein Routing. Firewalling auf dem TP-Link vielleicht?
Theoretisch ist das alles richtig konfiguriert, denn die Hostroute ins Heminetz ist mit dem 32 Bit Prefix ja die "most significant route". Die Frage ist aber letztlich ob der TP-Link damit richtig umgehen kann. Vermutlich nicht, denn das IP Design verstößt gegen typische TCP/IP Basics das Netzwerke eben einzigartig sein müssen von der Adressierung in einem Verbund.
Knackpunkt ist also des Fehldesign von der Adressierung das das VPN Netz in Frankfurt und dein privates IP Netzwerk gleich sind. In einem sauberen Design ist sowas ein NoGo !
Siehe dazu auch HIER !
Kollege @BirdyB hat hier also absolut recht mit der obigen Empfehlung das auf eine saubere und eindeutige IP Netzadressierung zu ändern. Sowas weiss man aber eigentlich auch vorher im VPN Design gerade wenn man im Heimnetz solche Allerwelts IP nutzt was im VPN Umfeld natürlich wenig zielführend ist. Ein einfaches Heimnetz wie bei dir ist ja in 5 Minuten auf ein neues IP Netz angepasst also kein großes Problem. Damit hast du das Problem dann wasserdicht gelöst.
Du brauchst dann auch keine Hostrouten mehr zu verwenden in deinem Setup.
Knackpunkt ist also des Fehldesign von der Adressierung das das VPN Netz in Frankfurt und dein privates IP Netzwerk gleich sind. In einem sauberen Design ist sowas ein NoGo !
Siehe dazu auch HIER !
Kollege @BirdyB hat hier also absolut recht mit der obigen Empfehlung das auf eine saubere und eindeutige IP Netzadressierung zu ändern. Sowas weiss man aber eigentlich auch vorher im VPN Design gerade wenn man im Heimnetz solche Allerwelts IP nutzt was im VPN Umfeld natürlich wenig zielführend ist. Ein einfaches Heimnetz wie bei dir ist ja in 5 Minuten auf ein neues IP Netz angepasst also kein großes Problem. Damit hast du das Problem dann wasserdicht gelöst.
Du brauchst dann auch keine Hostrouten mehr zu verwenden in deinem Setup.
Zitat von @b-t-o1978:
Hallo zusammen,
ich habe zuhause eine Fritzbox (6591 Cable im Netz 192.168.0.x; FB hat 192.168.0.3) und im Office habe ich ein Konstrukt mit 2 Internetanbietern, um eine Ausfallsicherheit zu gewährleisten. Falls DSL ausfällt, soll auf Mobilfunk zurückgegriffen werden.
...
Was das Ganze ein bissl erschwert ist sicherlich eine eingerichtete VPN-Verbindung auf dem TP Link zu einem Server in Frankfurt, der ebenfalls in 192.168.0.0/24 ist.
Hallo zusammen,
ich habe zuhause eine Fritzbox (6591 Cable im Netz 192.168.0.x; FB hat 192.168.0.3) und im Office habe ich ein Konstrukt mit 2 Internetanbietern, um eine Ausfallsicherheit zu gewährleisten. Falls DSL ausfällt, soll auf Mobilfunk zurückgegriffen werden.
...
Was das Ganze ein bissl erschwert ist sicherlich eine eingerichtete VPN-Verbindung auf dem TP Link zu einem Server in Frankfurt, der ebenfalls in 192.168.0.0/24 ist.
Moin,
Wie schon der Highlander sagte: Es kan nnur einen geben!
Grundsätzlich gilt: IP-netze müssen disjunkt sein. Un du verstößt hier eindeutig dagegen. Das kann und wird nicht funktionieren!
Überarbeite Deine Netzwerk-Adressen und schon wird es laufen.
lks
Zitat von @aqui:
Theoretisch ist das alles richtig konfiguriert, denn die Hostroute ins Heminetz ist mit dem 32 Bit Prefix ja die "most significant route".
Theoretisch ist das alles richtig konfiguriert, denn die Hostroute ins Heminetz ist mit dem 32 Bit Prefix ja die "most significant route".
Auch wenn Hostrouten vor Netzwerkrouten ausgewertet werden (sollten), ist mir bisher kein Baumarktrouter untergekommen, der sowas korrekt umsetzt. Von daher kann die Empfehlung nur sein: Korrekte Netzwerkplanung mit disjunkten IP-Netzen vermeidet jegliche Probleme dieser Art. Hatten wir ja schon vorgestern in diesem Thread.
lks
Zitat von @aqui:
Knackpunkt ist also des Fehldesign von der Adressierung das das VPN Netz in Frankfurt und dein privates IP Netzwerk gleich sind. In einem sauberen Design ist sowas ein NoGo !
Knackpunkt ist also des Fehldesign von der Adressierung das das VPN Netz in Frankfurt und dein privates IP Netzwerk gleich sind. In einem sauberen Design ist sowas ein NoGo !
gehe ich voll mit. Ich hatte nicht mitgeschnitten, dass das zweite VPN auf dem TP-Link läuft. Das ist trotz der händischen Route sehr wahrscheinlich der Knackpunkt.
Du brauchst dann auch keine Hostrouten mehr zu verwenden in deinem Setup.
Hier gehe ich dann nicht mehr mit, denn der TP-Link kennt ja das Netz der heimischen FB nicht. Dieses kennt nur die dienstliche FB. Also muss doch in das Netz der heimischen FB (0.0) vom TP-Link (5.0) zur FB(dienstlich 7.0) geroutet werden, wenn er aus dem TP-Link-Netz nach Hause will.
Ansonsten: Schönes Wochenende @all
Hier gehe ich dann nicht mehr mit, denn der TP-Link kennt ja das Netz der heimischen FB nicht.
Da hast du natürlich absolut Recht. Es war auch so gemeint das er den Netzwerk Prefix dann verwendet mit (vermutlich) 24 Bit und einer Netzwerkroute und nicht die Hostroute mit 32 Bit.Aber gut das du das nochmal hinterfragt hast, war in der Tat etwas missverständlich.
Sinnvoll wäre ohnehin beide VPNs auf dem TP Link zu terminieren und nicht die Frickelei mit dem VPN vor der Firewall des TP-Links. Sowas schafft immer nur Probleme da der TO dann wieder Löcher in die TP-Link Firewall bohren muss was dann die Sicherheit des Firmennetzes erheblich gefährdet. Kein besonders intelligentes VPN Design in einem Firmennetz. Besser, da erheblich sicherer, ist es das FB VPN Netz der 6591 Cable auch auf dem TP-Link zu terminieren.
Die Adressänderung im Heimnetz ist aber weiter zwingend erforderlich.
Grüsse ,
Wow, das wäre mir…
- Zuviel administrativer Overhead.
- Zuviel Geräte an der Steckdose
- Zuviel Fehlerquellen
- Zuviel Assets im Monitoring
Eine FritzBox vor dem Multi-WAN-Router mit LTE-Anbindung. *kicher*
Für den kleinen Hunger klemmen ich ein "altes" Smartphone mit LTE an die Fritzbox und aktiviere USB-Tethering . Danach taucht im Menü der Fritzbox folgendes auf.
C.C.
,ich habe zuhause eine Fritzbox (6591 Cable im Netz 192.168.0.x; FB hat 192.168.0.3) und im Office habe ich ein Konstrukt mit 2 Internetanbietern, um eine Ausfallsicherheit zu gewährleisten. Falls DSL ausfällt, soll auf Mobilfunk zurückgegriffen werden.
Daher habe ich dort die Fritzbox 7530 (192.168.7.1 bzw. 192.168.7.x), direkt danach kommt der Multi-WAN-Router TP Link TL-ER7206 (192.168.5.1) der dann die ganzen Devices mit IP-Adresse im Bereich 192.168.5.x versorgt.
Daher habe ich dort die Fritzbox 7530 (192.168.7.1 bzw. 192.168.7.x), direkt danach kommt der Multi-WAN-Router TP Link TL-ER7206 (192.168.5.1) der dann die ganzen Devices mit IP-Adresse im Bereich 192.168.5.x versorgt.
Wow, das wäre mir…
- Zuviel administrativer Overhead.
- Zuviel Geräte an der Steckdose
- Zuviel Fehlerquellen
- Zuviel Assets im Monitoring
Eine FritzBox vor dem Multi-WAN-Router mit LTE-Anbindung. *kicher*
Für den kleinen Hunger klemmen ich ein "altes" Smartphone mit LTE an die Fritzbox und aktiviere USB-Tethering . Danach taucht im Menü der Fritzbox folgendes auf.
Zwischen beiden Fritzboxen habe ich die VPN-Verbindung schon konfiguriert. Die funktioniert auch.
Hat auch den schönen Vorteil, dass die VPN-Verbindung über die AVM-Knowledgebase supportet werden kann.LG
Marc
GrußMarc
C.C.
Im Grundsatz richtig aber der TO hat aus Redundanzgründen 2 Internet Links, muss also einen Dual WAN Router nutzen oder einen der zumindestens multiple WAN Ports supportet.
Es wäre in der Tat zielführender an diesem Router dann reine Modems zu betreiben als komplette NAT Router Kaskaden die dann wieder ein Doppel NAT und Doppel Firewalling erzwingen was technisch immer kontraproduktiv ist, keine Frage. Vom Einsatz billiger Plaste Consumer Router im Firmenumfeld jetzt mal nicht zu reden.
Der Dual WAN Router ist also zu Recht beim TO gesetzt und dort sollte man dann auch zentral die VPNs terminieren um nicht in dessen Firewall Security Löcher zu produzieren was sich im obigen Setup mit der FritzBox Kaskade ja nicht vermeiden liesse. Der Netzwerk Admin dieser Firma wird sich sicher bedanken wenn er sowas hört...(sofern das der TO nicht eh selber ist ?! )
Da die FB ja Standard IPsec im VPN spricht und der TP Chinese auch ist die Terminierung des 6591er Heim VPNs ja ein Kinderspiel. Damit bleibt alles wasserdicht, ist zentral auf dem TP-Link managebar und benötigt keinerlei Löcher in der Firewall.
Die WAN1 und 2 Ports dann mit reinen NUR Modems wie dem alten Smartphone oder Vigor 165 oder Zyxel VMG3009 auf der DSL Seite zu betreiben wäre dann die Königsklasse... 😉
Es wäre in der Tat zielführender an diesem Router dann reine Modems zu betreiben als komplette NAT Router Kaskaden die dann wieder ein Doppel NAT und Doppel Firewalling erzwingen was technisch immer kontraproduktiv ist, keine Frage. Vom Einsatz billiger Plaste Consumer Router im Firmenumfeld jetzt mal nicht zu reden.
Der Dual WAN Router ist also zu Recht beim TO gesetzt und dort sollte man dann auch zentral die VPNs terminieren um nicht in dessen Firewall Security Löcher zu produzieren was sich im obigen Setup mit der FritzBox Kaskade ja nicht vermeiden liesse. Der Netzwerk Admin dieser Firma wird sich sicher bedanken wenn er sowas hört...(sofern das der TO nicht eh selber ist ?!
)Da die FB ja Standard IPsec im VPN spricht und der TP Chinese auch ist die Terminierung des 6591er Heim VPNs ja ein Kinderspiel. Damit bleibt alles wasserdicht, ist zentral auf dem TP-Link managebar und benötigt keinerlei Löcher in der Firewall.
Die WAN1 und 2 Ports dann mit reinen NUR Modems wie dem alten Smartphone oder Vigor 165 oder Zyxel VMG3009 auf der DSL Seite zu betreiben wäre dann die Königsklasse... 😉
Achtung: Es folgt die selektive Querlesekompetenz eines Winblow-Admin
Jippi...so gehts Happy in WE
Zurück zum Thema.
Mein Lösungsvorschlag beruht auf der These: 1 DSL-Provider und 1 Mobilfunk-Provider.
Wir können nur Vermutungen anstellen und/oder etwas Querlesen.
Be Happy
C.C.
Zitat von @aqui:
Im Grundsatz richtig...
...Kinderspiel. Damit bleibt alles wasserdicht...
...Königsklasse... 😉
Im Grundsatz richtig...
...Kinderspiel. Damit bleibt alles wasserdicht...
...Königsklasse... 😉
Jippi...so gehts Happy in WE
Zurück zum Thema.
Mein Lösungsvorschlag beruht auf der These: 1 DSL-Provider und 1 Mobilfunk-Provider.
…Konstrukt mit 2 Internetanbietern, um eine Ausfallsicherheit zu gewährleisten. Falls DSL ausfällt, soll auf Mobilfunk zurückgegriffen werden.
Wie es am Ende zusammengefriemelt ist, kann uns nur der TO oder die Config des TP-Link mitteilen.Wir können nur Vermutungen anstellen und/oder etwas Querlesen.
Be Happy
C.C.
Volle Zustimmung und auch ein Modem für 130 EUR sollte bei der Firma noch drin sein. Oder eben zwei.
Der guten Ordnung halber sei aber gesagt, dass ein TP-Link als Netzwerkzugangspunkt durchaus auch fragwürdig wäre. Ich bekomme bei meinen leider unkaputtbaren privaten TP-Links (jetzt OpenWRT) immer noch den Hinweis über die Firmware-Backdoor. Irgendwie muss ich da immer denken, wie schön es sein muss, solche Backdoors einzubauen, wenn man mal irgendwann CyberWar spielen möchte.
Königsklasse für SoHo: TP-Link raus, Pfsense oder OpenSense rein und sich sicher fühlen. Da gabs doch mal von irgendwem so eine Anleitung...
Grüße!
Der guten Ordnung halber sei aber gesagt, dass ein TP-Link als Netzwerkzugangspunkt durchaus auch fragwürdig wäre. Ich bekomme bei meinen leider unkaputtbaren privaten TP-Links (jetzt OpenWRT) immer noch den Hinweis über die Firmware-Backdoor. Irgendwie muss ich da immer denken, wie schön es sein muss, solche Backdoors einzubauen, wenn man mal irgendwann CyberWar spielen möchte.
Königsklasse für SoHo: TP-Link raus, Pfsense oder OpenSense rein und sich sicher fühlen. Da gabs doch mal von irgendwem so eine Anleitung...
Grüße!
