Portforwarding auf die FritzBox selbst, externer port != internet port

level20peon · 3 Aug 2016

Ich habe diverse forwarding rules in der ar7.cfg eingetragen, die z.B. Port 1194 von extern auf den openvpn Server der Fritzbox selbst weiterleiten, was soweit auch funktioniert:

Code:

internet_forwardrules = "udp 0.0.0.0:1194 0.0.0.0:1194 0 # openvpn";

Nun möchte ich jedoch für eine andere Weiterleitung einen externen port auf einen anderen internen Port weiterleiten:

Code:

internet_forwardrules = "udp 0.0.0.0:1194 0.0.0.0:1194 0 # openvpn",
"tcp 0.0.0.0:280 0.0.0.0:22 0 # SSH alternative";

Das scheint so nicht zu funktionieren, ist meine Syntax falsch?

PeterPawn · 3 Aug 2016

Über dieses Problem bin ich auch schon früher mal gestolpert und habe es auch nicht hinbekommen.

Ich gehe inzwischen davon aus, daß es mit der vorhandenen Implementierung gar nicht funktioniert und das dann auch der Grund ist, warum AVM es selbst nicht gebacken kriegt, extern einen "versteckten" Port für das GUI zu verwenden und diesen aber intern ganz normal auf 443 zu mappen, damit man bei interner Verwendung von TLS bei HTTP nicht immer erst den Port angeben muß.

Ich habe mir dann mit einem "Tunnel" von dem einen Port zum anderen eine andere Lösung gebaut.

koyaanisqatsi · 3 Aug 2016

Moins

Dieser Trick sollte immernoch funktionieren: voip_forwardrules
...für IPv4 & IPv6

PeterPawn · 3 Aug 2016

Ich habe das gerade noch einmal auf einer 113.06.69-40416 durchgespielt, dort funktioniert sogar das Ummappen der Ports (wie in #1) inzwischen (seit wann, weiß ich gar nicht, gehörte nicht zum Standardumfang an Tests). Die erste Angabe ist der extern freizugebende und die zweite der Zielport auf der Box. Allerdings funktioniert es tatsächlich auch erst nach einem Neustart - wobei das jetzt kein systematischer Test war und diese "Rahmenbedingung" daher nicht überbewertet werden sollte.

level20peon · 3 Aug 2016

PeterPawn schrieb:
Ich habe mir dann mit einem "Tunnel" von dem einen Port zum anderen eine andere Lösung gebaut.

Also quasi "ssh -L 280:127.0.0.1:22 [email protected]" ?

koyaanisqatsi schrieb:
Dieser Trick sollte immernoch funktionieren: voip_forwardrules...für IPv4 & IPv6

Was ist denn dabei der "Trick"... es wird an den gleichen Port weitergeleitet von dem aus auch die Umleitung erfolgt. Eine Weiterleitung von 22 an 22 funktioniert bei mir auch mit der Standardlösung in Beitrag #1.

PeterPawn schrieb:
Ich habe das gerade noch einmal auf einer 113.06.69-40416 durchgespielt, dort funktioniert sogar das Ummappen der Ports (wie in #1) inzwischen (seit wann, weiß ich gar nicht, gehörte nicht zum Standardumfang an Tests). Die erste Angabe ist der extern freizugebende und die zweite der Zielport auf der Box. Allerdings funktioniert es tatsächlich auch erst nach einem Neustart - wobei das jetzt kein systematischer Test war und diese "Rahmenbedingung" daher nicht überbewertet werden sollte.

Ich habe gleichzeitig auch noch 22 an 22 geleitet, vielleicht ist das das Problem. Wie dem auch sei, ich werde wohl die Tunnel Lösung verwenden.

- - - Aktualisiert - - -

level20peon schrieb:
Also quasi "ssh -L 280:127.0.0.1:22 [email protected]" ?

Also das scheint nicht zu funktionieren... wie sieht deine Lösung aus?

PeterPawn · 3 Aug 2016

tcpsvd i.V.m. nc

Code:

tcpsvd 192.168.178.1 280 nc 192.168.178.1 22

wäre das dann für einen SSH-Service auf dem externen Port 280 (der natürlich zusätzlich 1:1 gemappt sein muß).

Der interne Tunnel soll ja nur den Payload der TCP-Pakete weiterleiten, da macht eine zusätzliche Verschlüsselung (wie in einem SSH-Tunnel) in meinen Augen wenig Sinn.

koyaanisqatsi · 4 Aug 2016

Eine Weiterleitung von 22 an 22 funktioniert bei mir auch mit der Standardlösung in Beitrag #1.

Bei mir auch.

Aber warum probierst du es nicht mal ?
...zum Beispiel...

Code:

        voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                            [COLOR=#ff0000]"tcp 0.0.0.0:2222 0.0.0.0:22",[/COLOR]
                            "tcp 0.0.0.0:5060 0.0.0.0:5060",
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078";

...dann wird der Externe 2222...

Code:

osmc@osmc:~$ ssh 217.244.151.101 -p 2222
The authenticity of host '[217.244.151.101]:2222 ([217.244.151.101]:2222)' can't be established.
ECDSA key fingerprint is 08:64:30:1c:24:8c:48:d8:1a:b9:52:0e:a4:1f:65:00.
Are you sure you want to continue connecting (yes/no)?

Diagnose/Sicherheit

Code:

dropbear -R -m -p 22

...an den Internen 22 weitergeleitet.

level20peon · 4 Aug 2016

Das 1:1 mappen habe ich gemacht, aber zumindest mit SSH funktioniert es halt nicht. Den Overhead der Verschlüsselung zu vermeiden ist natürlich die sauberere Lösung.

tcpsvd funktioniert im ersten Test, danke!

Languages

Suche

Languages

Suche

Portforwarding auf die FritzBox selbst, externer port != internet port

level20peon

Mitglied

PeterPawn

IPPF-Urgestein

koyaanisqatsi

IPPF-Urgestein

PeterPawn

IPPF-Urgestein

level20peon

Mitglied

PeterPawn

IPPF-Urgestein

koyaanisqatsi

IPPF-Urgestein

level20peon

Mitglied

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums