Portforwarding durch VPN Tunnel funktioniert nicht

[ecox]

Hallo zusammen,

das Szenario ist wie auf dem Bild dargestellt.

2016-04-22 07_25_38.jpg

Problem: Wenn ich das Portforwarding wie darggestellt einrichte. Bekomme ich mittels https://WAN-IP:7443 keine Verbindung zur Außenstelle.

Wenn ich nun über das Web-Interface einen TCP/HTTP-Tunnel anlege, geht es problemlos und ich kann über den VPN auf den Router mittels Portforwarding zugreifen.

Ich habe versucht das auszutracen, bin allerdings nicht auf den Fehler gestoßen warum es mit normalen Portforwarding nicht geht.

Ich habe so die Befürchtung, da beide LANCOMS über Port 443 erreichbar sind, lokal wie öffentlich, sich da irgendwas gegenseitig abschießt, evtl bei den Rückanfragen an 443 von der Außenstelle aus :/.

Kann mir das bitte jemand mal erklären ob ich hier einen Denkfehler habe oder das schlicht und einfach gewollt ist.

Grüße

ec0x

P.S.: Ich habe auch zwischen durch die HTTPS Ports der beiden LANcoms verändert und das Routing neu angelegt, jedoch keinen Erfolg - ich verzweifle daran langsam

[Bernie137]

Moin ecox,

Deine Überschrift passt nicht zu dem was Du konfigurierst. Sprich: Du erzählst was mit Forwarding durch den VPN-Tunnel, zeigst aber im Bild die Gegenstelle "T-CLSURF" und sprichst im Text von https://WAN-IP:7443.

Willst Du es nun über die öffentliche WAN-IP ansprechen oder durch den VPN-Tunnel?

Gruß Bernie

[ecox]

Moin ecox,

Deine Überschrift passt nicht zu dem was Du konfigurierst. Sprich: Du erzählst was mit Forwarding durch den VPN-Tunnel, zeigst aber im Bild die Gegenstelle "T-CLSURF" und sprichst im Text von https://WAN-IP:7443.

Willst Du es nun über die öffentliche WAN-IP ansprechen oder durch den VPN-Tunnel?

Gruß Bernie

Also wenn 192.168.1.1 gleich NETZ A ist und 192.168.1.2 gleich NETZ B ist, möchte ich mittels "https://WAN IP vom NETZ A:7443, auf das NETZ B geleitet werden, dies soll für die Gegenstelle T-CLSURF gelten!? Liegt hier das Problem? Wenn ich es auf die VPN Gegenstelle lege, erwartet er doch das diese Anfrage aus dem Tunnel kommt?!

Grüße

[Bernie137]

Jetzt hast Du Dein Bild wieder rausgenommen
War das vom Router A oder B die Konfig?

Dein Ziel ist eine Sache, die quasi gar nix mit dem VPN-Tunnel zu tun hat, richtig?

[ecox]

Jetzt hast Du Dein Bild wieder rausgenommen
War das vom Router A oder B die Konfig?

Dein Ziel ist eine Sache, die quasi gar nix mit dem VPN-Tunnel zu tun hat, richtig?

Ich habe das Bild jetzt drin, aber bei Gegenstelle hatte ich nun VPN-Gst. eingetragen, was aber glaube auch keinen Sinn macht.

Na klar hat das was mit dem VPN zu tun , denke ich, ich möchte doch durch den Tunnel einen Zugriff auf das NETZ B bekommen, daher das Forwarding ins lokale Netz (192.168.2.1)

Grüße

[Bernie137]

Na klar hat das was mit dem VPN zu tun , denke ich, ich möchte doch durch den Tunnel einen Zugriff auf das NETZ B bekommen, daher das Forwarding ins lokale Netz (192.168.2.1)

Und warum dann ein Forwarding? Greife doch konkret auf die IP:Port vom Netz B zu. Genau dafür ist der VPN-Tunnel doch da.

Gruß Bernie

[ecox]

Und warum dann ein Forwarding? Greife doch konkret auf die IP:Port vom Netz B zu. Genau dafür ist der VPN-Tunnel doch da.

Weil ich niemals vor Ort an Standort A oder B sein werde, ich jedoch nur eine feste IP an Standort A habe, aber anderen die Möglichkeit geben will eben über die feste WAN-IP von Standort A mit Port-Forwarding diese Außenstelle zu erreichen mit einem TCP/HTTP-Tunnel geht es ja, weiß eben nur nicht was da anders gemacht wird :/ Wird das nochmal extra gekapselt :/?

Grüße

[Bernie137]

Aber die WAN-IP vor Router B gehört nun mal nicht zum lokalen Netz am Standort B. Demnach wird diese IP im Router A anhand seiner Routing-Tabelle lokal ins Internet ausgekoppelt und niemals durch den VPN-Tunnel geschickt. Wenn Du überhaupt ein Port Forwarding einrichten willst, dann am Router B. Dann nimmt Dein Paket den Weg: Netz A - Router A - Internet - WAN IP Router B -...

aber anderen die Möglichkeit geben will eben über die feste WAN-IP von Standort A mit Port-Forwarding diese Außenstelle zu erreichen

Da Du an anderen Stellen immer die IP 192.168.2.1 anführst, geht es Dir um den Router selbst? Denn ein ganzes Netz sprichst Du ja nicht an mit der Makierung. Wäre es dann nicht am einfachsten dafür ein DynDNS zu nehmen am Router B? Der DNS-Name wird dann an jeder Lokalität aufgelöst, auch im Standort A und Standort B. Ansonsten haben ich Deinen Sinn und Zweck des Ganzen noch nicht verstanden.

Gruß Bernie

[ecox]

Also ich versuche das jetzt hier nochmal ganz in Ruhe zu erfassen.

LANCOM 1(feste WAN IP):
IP: 192.168.1.1

LANCOM 2(dyn. WAN IP // IPoE eingerichtet // FRITZ!Box hängt vor LANcom):
IP: 192.168.2.1

LANCOM 1 <<---VPN--->> LANCOM 2:
»Verbindung ist stabil, austausch von Daten kein Problem.
»Ich habe am LANCOM 1 ein Portforwarding eingerichtet

Code: Alles auswählen

D-port-from              INFO:    7443
D-port-to                INFO:    7443
Protocol                 INFO:    TCP+UDP
Peer                     INFO:    T-CLSURF
WAN-Address              INFO:    0.0.0.0
Intranet-Address         VALUE:   192.168.2.1
Map-Port                 VALUE:   443
Active                   VALUE:   Yes
Comment                  VALUE:   Aussenstelle

Nun zur Fragestellung:
Wieso, leitet mich LANCOM 1 nicht an LANCOM 2 weiter wenn ich über die öffentliche IP den Port 7443 ankomme.
Und was macht der TCP/HTTP-Tunnel anders? Denn lege ich darüber einen Tunnel auf die lokale Adresse vom LANCOM 2 an (Port 3144), komme ich von überall auf der Welt auf den LANCOM 2, wo ist der der Trick, was macht der TCP/HTTP Tunnel...

Es ist wirklich eine ganz einfach Sache die ich hier machen möchte, aber eben nur kein Portforwarding auf eine lokale IP am LANCOM 1, sondern auf eine lokale IP am LANCOM 2.

Ich hoffe, das jetzt klar ist was ich möchte

Grüße

P.S.: DynDns habe ich natürlich empfohlen, ist aber nicht er wünscht. Der Anwender hat nicht viel Ahnung aber weiß durchaus was ein Tunnel und ein Portforwarding ist, ihm zu erklären warum es nicht geht, fällt mir sichtlich schwer denn über einen TCP/HTTP Tunnel geht es ja...

[Bernie137]

Gut, nun habe ich verstanden, was Du möchtest. Finde die Lösung dennoch komisch.

Nun zur Fragestellung:
Wieso, leitet mich LANCOM 1 nicht an LANCOM 2 weiter wenn ich über die öffentliche IP den Port 7443 ankomme.
Und was macht der TCP/HTTP-Tunnel anders? Denn lege ich darüber einen Tunnel auf die lokale Adresse vom LANCOM 2 an (Port 3144), komme ich von überall auf der Welt auf den LANCOM 2, wo ist der der Trick, was macht der TCP/HTTP Tunnel...

Das wird Dir bestimmt backslash beantworten können.

Ich verstehe Deine Lösung so, dass man auf jeden Fall die WAN Adresse des LANCOM1 aufrufen muss, damit es überhaupt greifen könnte. Jedoch gehört zur Rückwärts Übersetzung des NATs die Adresse 192.168.2.1 nicht zum lokalen Netzwerk dieses NATs. Auf jeden Fall ist mit Aufruf der WAN-IP von LANCOM1 immer das Internet im Spiel. Was macht es da jetzt für einen Unterschied, dass es erstens wieder in den VPN-Tunnel geht oder gleich durchs Internet und zweitens sehe ich jetzt keinen Sicherheitstechnischen Unterschied zu DynDNS??? In beiden Fällen geht der Traffic immer durchs Internet. Lediglich am WAN-Port von LANCOM2 kann der https Port zum Internet hin zu bleiben. Ganz toll wird es, wenn jemand Dein Konstrukt im Standort B aufruft. Dann geht es von hinten durch die Brust ins Auge.

Verbiege doch in beiden Standorten lokal die Auflösung zur DynDNS Adresse auf die richtige Intranetadresse. Das müsste doch klappen und von extern bleibt es extern DynDNS.

Der Anwender hat nicht viel Ahnung aber weiß durchaus

Stellt sich die Farge, was er dann auf dem Router machen soll/will?

Gruß Bernie

[Dr.Einstein]

Hallo zusammen,

ein Standard VPN hat die Netzbeziehung Netz A <-> Netz B. Wenn du jetzt über eine Portweiterleitung reinkommst, brauchst du eine Netzbeziehung ANY <-> Netz B, da du ja übers Internet reinkommst. Das wäre Punkt 1.

Punkt 2 ist die Rückroute. Wenn das Paket dann über den Router im Netz A ins B geschickt wird, steht als Quell IP die öffentliche IP deines Rechners drin, nicht die vom Router A. Router B guckt für die Antwort in seine Routing Tabelle und schickt die Antwort zur IPoE Verbindung / Firtzbox und nicht über den Tunnel zurück.

HTTP Tunnel erzeugt eine neue Anfrage vom Lancom A aus. Eine Portweiterleitung wird nur weitergeleitet, nicht entgegengenommen und eine neue Session erzeugt.

Gruß Dr.Einstein

[backslash]

Hi,

Das wird Dir bestimmt backslash beantworten können.

besser als Dr.Einstein kann ich es auch nicht sagen...

Gruß
Backslash

[ecox]

Hallo Einstein,

das klingt so ganz plausibel kannst du mir bezüglich der Rückroute auf LANCOM 2 sowie der FW-Regel auf LANCOM 1 ein Beispiel liefern, bin gerade kurz angebunden, würde das nachher gerne auf die schnelle realisieren...

Grüße

[Dr.Einstein]

kA ob das so professionell ist, hatte das bis jetzt nur in 2..3 Fällen in den letzten Jahren:

Router A:

Zwei neue Firewallregel mit

Firewall-Rule: no
VPN-Rule: yes
Quelle: Netz B
Ziel: beliebig

Firewall-Rule: no
VPN-Rule: yes
Quelle: beliebig
Ziel: Netz B

In Router B musst du für die geeignete Rückroute sorgen. In meinen Fällen war immer hinter dem Lancom Router das Gerät. Dadurch konnte ich mittels Policy Based Routing die Sache lösen. Da du jetzt aber direkt auf den Lancom zugreifst, klappt das glaube ich gar nicht. Kannst es aber versuchen.

Leg dafür eine unmaskierte 2. Default Route an mit Gegenstelle VPN, Routing Tag z.B. 10. Neue Firewallregel nach dem Muster

Firewall-Rule: yes
VPN-Rule: no
Rtg-Tag 10
Quelle: IP-Lancom, Port 443
Ziel: beliebiger Port / beliebiges Ziel

Wie gesagt, selbst noch nicht gebastelt. Sollte das nicht klappen, würde ich vermutlich die Default Route auf VPN ändern, und dann mittels Regeln den kompletten lokalen Verkehr auf die 2. Default Route Fritzbox bringen.

Gruß Dr.Einstein

[ecox]

Ich danke dir vielmals, ich werde das so schnell wie möglich testen aktuell bootet ein 9100+ VPN lieber alle 30 Minuten neu :p

Grüße