[Erledigt] Portweiterleitung an Netz hinter LAN-LAN-Kopplung

[Tuffi]

Hallo liebes Forum.

Meine Konstellation ist folgende:
Ich habe 2 mal die FRITZ!Box 7490 mit FRITZ!OS 06.20 im Einsatz.
Am Standort A mit Netz 192.168.2.0 und über das Internet erreichbar
Am Standort B mit Netz 192.168.156.0 und hinter einem Carrier-grade NAT
Beide Boxen sind über VPN per LAN-LAN-Kopplung verbunden.

Meine Frage ist:
Kann ich nun Eine Portfreigabe in Fritz!Box A auf einem Rechner im Netz von Fritz!Box B (auf IP: 192.168.156.10) einrichten?
Wenn ich es versuche, bekomme ich die Meldung "Die Portfreigabe kann nicht erstellt oder aktiviert werden, da das Ziel nicht im Heimnetz liegt."
Ich habe versucht eine Statische IPv4-Route in Fritz!Box A zu erstellen:
IPv4-Netzwerk: 192.168.156.0
Subnetzmaske: 255.255.255.0
Gateway: 192.168.2.115 (eigene IP-Adresse der Box A)
nun kann ich zwar eine Portfreigabe nach IP-Adresse 192.168.156.10 einrichten, allerdings wird die VPN-Verbindung nach Box B nicht mehr aufgebaut.

Hat sonst noch jemand eine Idee oder sogar eine Lösung?


Danke und Gruß,
Tuffi

 

[HabNeFritzbox]

Also 192.168.2.115 ist die VPN IP?

Mit einer Route kann ich Portfreigaben in andere Netze machen, jedoch verwende ich kein VPN in der FB selbst, daher kann ich den Punkt nicht testen.

 

[Tuffi]

192.168.2.115 ist die IPv4 Adresse der Fritz!Box A. Siehe Screenshot

 

[HabNeFritzbox]

Bei VPN Client wird ja noch wenigstens eine IP angegeben, welche man als Gateway angeben kann, aber bei Lan <-> Lan, hmm.



Anderer seids beschwert sich die FB ja nicht, wenn diese selbst als Gateway angeben wird.

Hab da auch keine Idee. Durch die VPN Koppelung gibt es ja eigentlich bereits eine Route.

 

[Tuffi]

Jo eben. Deshalb schmiert, denke ich, auch die VPN-Verbindung ab, sobald ich die statische Route eintrage.
Nur komisch, das ich dann keine Portweiterleitung machen kann, wenn die VPN-Verbindung steht.

 

[PeterPawn]

VPN-Verbindungen LAN-LAN haben in der FRITZ!Box keine eigene Route, die Daten für die Gegenstelle müssen an 'dev dsl' geroutet werden, damit die am IPSec-Stack überhaupt vorbeikommen. Dabei verläßt sich AVM bei LAN-LAN-VPN einfach darauf, daß 'dev dsl' immer das Standard-Gateway einer FRITZ!Box ist.

Die Portfreigabe prüft spätestens seit der 06.20 für jeden freizugebenden Port, ob das Ziel über "dev lan" zu erreichen ist. Ist das nicht der Fall, kommt die erwähnte Fehlermeldung. Das läßt sich ganz simpel prüfen ... richtet man eine lokale statische Route auf 192.168.0.0/16 über irgendeine beliebige lokale Adresse (bei Dir 192.168.2.2 z.B., die muß nicht mal existieren) ein, kann man für alle Ziele aus 192.168.0.0/16 - egal ob diese nun wieder existieren oder nicht - eine Portfreigabe einrichten. Das klappt nicht, wenn für die freigegebene Adresse eine speziellere Route über ein anderes Interface (egal, ob dsl oder guest oder was es sonst noch so gibt in so einer FRITZ!Box) existiert.

Du richtest also mit der von Dir getesteten Route (in #1) einen Weg zu 192.168.156.0/24 über 'dev lan' ein (die .115 ist ja die Adresse der Box auf diesem Interface (bzw. dieser Bridge)) und damit hat die Portweiterleitung nichts zu beanstanden. Nun gehen aber die Daten an dieses Netz nicht mehr an 'dev dsl' (s.o.) und kommen somit nicht am IPSec-Stack vorbei.

Und auch bei aufgebauter VPN-Verbindung kennt die Box ja immer noch keine spezielle Route zur 192.168.156.0/24, daher kannst Du dann auch noch keine Portweiterleitung einrichten (#5).

Die einzige halbwegs praktikable Lösung wäre ein Proxy im LAN (oder auf der Box, wenn Du Freigaben auf das LAN der Box einrichtest, was auch nur auf Umwegen geht), der dann wieder "von innen" die Verbindung in das entfernte LAN verbiegt. Ein SSH-Tunnel könnte theoretisch auch helfen, dann sollte dieser aber ohne eigene Verschlüsselung arbeiten, da ja das VPN bereits einmal verschlüsselt und das zu doppeln nur mehr Power braucht, aber keinen Sicherheitsgewinn bringt. Ohne zusätzliche Programme auf der FRITZ!Box könnte man noch versuchen, da etwas mit 'nc' zu bauen, wenn das im Image ist. Aber das ist dann ein elendes Gefrickel, der Proxy oder ein Dropbear ist sicherlich die einfachste Lösung.

 

[Tuffi]

Ich hatte fast schon befürchtet das ich mir noch ein extra Gerät hin stellen muss.
Wir hatten gestern noch ein bisschen getestet, was über die VPN Verbindung so geht. Leider war beim kopieren von Daten vom einen ins andere Netz bei ca. 10 Mbits/s Schluss, obwohl das Netz A über eine 50/50 Mbits/s Leitung, und das Netz B über 100/100 Mbits/s Leitung ans Internet angeschlossen sind. Auf beiden Seiten sind die jeweiligen Rechner per Netzwerkkabel an die Boxen angeschlossen.
Während des Kopiervorgangs war ebenfalls Telefonieren über die Boxen nicht möglich. Auf Seite A mit einem MT-F und VoIP und auf Seite B mit einem MT-D und ISDN. Man konnte hören das die Gegenseite was sagt, aber nicht was. Das Signal war total "verzerrt". Nach Abbruch des Kopiervorgangs war das Gespräch wieder klar.

 

[HabNeFritzbox]

Ist nicht neu, VPN umgeht wohl QoS und damit fette lags bei Telefonie.

Von NAS und VPN in FB sollte man abgesehen.

 

[PeterPawn]

Wir hatten gestern noch ein bisschen getestet, was über die VPN Verbindung so geht. [...]
Das Signal war total "verzerrt". Nach Abbruch des Kopiervorgangs war das Gespräch wieder klar.

Das ist auch vollkommen logisch, wenn man sich mal den Weg einer Verbindung auf der/durch die FRITZ!Box überlegt.

Eine beliebige Verbindung kommt auf der Box über das LAN-Interface an (das kann auch eine Verbindung auf der Box selbst sein) und wird jetzt durch die QoS-Maschine gedreht (d.h. klassifiziert und in eine der möglichen QoS-Queues eingereiht). Der Scheduler holt sich aus diesen Queues dann das, was er als nächstes auf die Reise schicken soll.

Die IPSec-Verschlüsselung findet nun offenbar aber erst nach diesem Prozess statt und die dabei entstehenden Pakete nehmen wohl nicht noch einmal ihren Weg durch den kompletten Stack der Box, sondern werden direkt anhand ihrer äußeren Verpackung an das Gateway der Gegenstelle geleitet.

Damit greift dann für die IPSec-Pakete keine "nachträgliche" Priorisierung mehr und aus den schon mal erläuterten Gründen (Erhöhung des Volumens durch UDP->IPSec->Payload) reicht dann die ansonsten reservierte Bandbreite nicht mehr aus. Wenn die Box auf der LAN-Seite noch - sagen wir mal - 10% der ihr bekannten WAN-Bandbreite für Echtzeitanwendungen freihalten will und die restlichen 90% für die Datenübertragung zur Verfügung stellen will (keine Ahnung, ob das wirklich relativ oder doch absolut reserviert wird), dann würden bei einer 5%igen Erhöhung des Volumens durch die VPN-Verschlüsselung von dieser Reservierung eben auch nur noch 5% übrig bleiben, bei höherem Overhead entsprechend noch weniger.

 

[Tuffi]

Also wäre ich wohl besser Beraten, mir zwei Einplatinen-Computer (hatte da an ein BeagleBone Black o.ä. gedacht) zu besorgen die mir dann den Tunnel aufbauen. Dann sollte ich ja eine Portweiterleitung über eine IPv4 Router mit dem Platinen-Computer als Gateway hin bekommen und kann den Tunnel dann auch wieder gescheit Priorisieren, oder?

 

[PeterPawn]

Dann sollte ich ja eine Portweiterleitung über eine IPv4 Router mit dem Platinen-Computer als Gateway hin bekommen und kann den Tunnel dann auch wieder gescheit Priorisieren, oder?

Imho ja.

Wenn es Dir dabei auch noch gelingt, einen Einplatinen-Rechner zu finden, dessen Prozessor auch Crypto-Befehle (und sei es nur im Ansatz z.B. für AES-Runden) unterstützt und wo man die auch noch per Kernelmodule benutzen kann, dann kriegst Du auch - neben der funktionierenden Priorisierung - einen ordentlichen Durchsatz hin ... der VR9 ist offenbar nicht für Verschlüsselung gebaut (oder Lantiq/AVM haben keine Lust, eine vielleicht sogar vorhandene Hardware-Unterstützung dafür zu aktivieren ?).

Was da wirklich machbar ist, kannst Du ja problemlos vorher schon mit einem Windows-PC oder etwas ähnlichem auf beiden Seiten testen. Wenn Du da ein L2TP-IPSec zwischen zwei Windows-Rechnern (einstellbar über erweiterte Firewall-Konfiguration) über die unverschlüsselte Verbindung der FRITZ!Boxen laufen läßt (wobei "Verbindung" dann ja eigentlich nicht besteht), sollten eigentlich halbwegs potente Prozessoren in den Clients die 50 MBit/s ausreizen können, ohne allzu sehr ins Schwitzen zu geraten.

Dabei würde mich dann allerdings wirklich mal interessieren, was so eine FRITZ!Box im Upload tatsächlich bei Dir schafft. Bei mir kommen da (LAN1, wie bei Dir sicherlich auch, denn das ist wohl FTTx, oder ?) nur ca. 34 MBit/s (knapp 4 MByte/s davon bleiben auf einem Windows-Host "übrig") im Upload drüber ... ich vermute mal, aufgrund der Inspektion vor dem Routing jedes Paketes, was ansonsten im Download (zumindest teilweise) per "FastPath" direkt vom Switch erledigt wird (PA/PPA, je nachdem, wie es Lantiq oder AVM an dieser Stelle gerade nennt).

EDIT: Ich habe mir gerade mal angesehen, was ein BeagleBone Black so kann ... irgendwie kann ich mir nicht so richtig vorstellen, wie zwei solche Einplatinen-Rechner selbst eine LAN-Verbindung mit akzeptabler Verschlüsselung hinbekommen wollen, die nur annähernd an 50 MBit/s heran reicht, wenn die Daten nicht direkt dort schon vorliegen. Wenn die erst über die max. FE-Schnittstelle in das Gerät rein sollen und dann auf demselben Weg wieder heraus, dürfte das etwas kompliziert werden ... die anderen Schnittstellen erscheinen mir für diesen Zweck auch nicht sehr plausibel.

 

[Tuffi]

Danke für deine Ausführung.
Ja, ist auf beiden Seiten ein FTTH Anschluss. Wenn ich nächste Woche etwas Zeit habe, werde ich die Sache mit den beiden Windows-PCs mal ausprobieren und berichten.
Das BeagleBone Black hab ich als Beispiel genommen, da ich davon eins zu hause rumliegen habe. Ich müsste mich da auch erst mal schlau machen 1. Wie ich es aufsetze und 2. Welches Gerät sich da am besten eignet.

 

[Tuffi]

Vorweg: Da es nun schon ein paar Wochen seit dem letzten Post her ist, erlaube ich mir einen neuen Post unter meinem Eigenen.

Ich habe es nun geschaft dein Szenario mal zu testen.
Habe wie hier beschrieben: Virtual Private Network (VPN) unter Windows 7 einrichten
eine Verbindung zwischen zwei Rechnern eingerichtet. Dabei war die Übertragungsrate im Fritz Box Onlinemonitor am Anfang bei ca. 45 Mbits/s und nahm dann schwankend zwischen auf deine Beschriebenen 35 Mbits/s ab.
Der Windows Kopierdialog schwankte zwischen 35 - 45 Mbits/s.
Gleichzeitig hatte ich wieder Störungen beim telefonieren. Nicht so stark wie im ersten Szenario aber noch unzumutbar vorhanden. Diesmal allerdings kommend und gehend und nicht durchgehend.
Konnte dabei die Fritz Box mit der Internettelefonie als "Störer" ausmachen.
Hab auch mal versucht die IP der Rechner in der jeweiligen Fritz Box auf Priorität Hintergrundanwendung zu stellen. Dies brachte auch keine merkliche Verbesserung. Subjektiv nicht ganz so stark wie ohne Priorisierung, das kann aber auch Einbildung gewesen sein.

Gruß,
Tuffi

 

[PeterPawn]

Es bliebe noch der Versuch, die für die Telefonie reservierte Bandbreite zu vergrößern. Ich bin mir nicht sicher (mir fehlt die Zeit zum Test), aber das hier beschriebene Vorgehen könnte (immer Konjunktiv !) helfen.

 

[Tuffi]

Dankeschön. Ich werde es mir mal im Hinterkopf behalten.
Habe erst mal den AVM Support bemüht und warte mal ab was die dazu sagen, bevor ich in meiner Box rumfummel und die wegen nicht erlaubten Änderungen zurücksetzen muss, damit der Support die Diagnose Daten annimmt.