Portforwarding Port 443

[loomax]

Seit dem in Freetz neuere Avm Firmwares als Version 113.06.69 rev41556 BETA verwendet werden scheint es nicht mehr möglich zu sein eine Portfreigabe für den Port 443 einzurichten.

Im meinem Fall verwende ich den Port 443 um von aussen per ssh tunnel auf die Fritzbox ( dropbear Port 22 ) zu kommen.


Sobald ich einen neueren Freetz build verwende wird die Portweiterleitung gelöscht und lässt sich auch nicht mehr einrichten.


Hat jemand ähnliche Probleme oder eine Lösung ?

 

[koyaanisqatsi]

Moins


Schuss ins Grüne

Kannst ja mal bei dieser Gelegenheit checken, obs...

...hiermit was zu tun hat.

 

[PeterPawn]

@loomax:
Minimal mehr Informationen wären schon hilfreich ... aber da steckt auch zur Zeit generell der Wurm drin in den Portfreigaben (mein Eindruck). Seitdem das umgestellt wurde, funktioniert nur noch wenig ... ich lasse das erst einmal etwas sacken.

Beispiel: Beim Versuch, eine Freigabe (genauer zwei) von zwei verschiedenen externen Ports auf denselben internen Port eines LAN-Clients einzurichten, schmeißt mir die Box im Moment die beiden Freigaben zusammen und ich habe in Wirklichkeit nur eine einzige vom ersten eingestellten Port (mit "showopenports" kann man es kontrollieren) und im GUI werden zwei Dienste mit identischem Mapping, aber anderen Namen angezeigt.

Alles noch mit 41875 - vielleicht ist es mit der 41986 ja wieder besser. Ich werde es nicht sofort probieren, erst mal schauen, was sich diese Woche geändert hat.

 

[loomax]

@PeterPawn

mit der neuen 41986 geht es auch nicht

@[SIZE=2pt]koyaanisqatsi[/SIZE]

ich kann mir nicht vorstellen dass das etws bringt, da ich noch andere Protfreigaben eingetragen habe die Problemlos funktionieren. Es sieht eher so aus als habe AVM die Portweiterleitung von port 443 gesperrt - evt. wegen des Fernzugriffs den ich auf Port 444 laufen habe. Ich muss aber den Port 443 für den ssh Tunnel verwenden, da ich sonst nicht durch die Firewall komme.

 

[PeterPawn]

Dann probiere es einfach einmal mit einem 1:1-Mapping und konfiguriere den SSH-Server auf 443 - es läuft eben im Moment einiges durcheinander, auch dann, wenn man einen abweichenden internen Port verwenden will. Sei kreativ ... bei mir funktionieren 1:1-Mappings ins LAN problemlos - nur wenn es komplizierter wird, kommt im Moment Unfug dabei heraus; das geht bei "grauer LED" los (obwohl die Freigabe existiert und auch aktiv ist, was man von der Shell aus ja kontrollieren kann) und endet beim falschen Gerät, auf das eine Freigabe am Ende wirklich zeigt.

Wenn es wichtig ist, daß die Freigabe funktioniert, nimm eine alte Version ... wie gesagt, sei kreativ. Daß die Firmware (und zwar schon die originale von AVM, denn ich verwende "modfs" und kein Freetz für Modifikationen) bei den Freigaben gerade umgebaut wird und es dabei Probleme gibt, ist ja nun nichts neues ... Du wirst dafür sicherlich keine Lösung hier im IPPF erwarten.

 

[loomax]

Vielen Dank für die ausführliche Antwort. Wenn ich den SSH-Server auf 443 konfiguriere geht es auch nicht, hab ich schon probiert. Die Firewallfreigabe kann gar nicht erst angelegt werden.
Ich bin bereits auf die alte noch funktionierende Freetz bzw AVM Firmware zurückgegengen.

Ich wollte erst mal sehen, ob andere das Problem auch haben bevor ich mal direkt bei AVM anfrage.

 

[PeterPawn]

Ich kann problemlos bei der 41986 auch wieder eine Freigabe von extern 443 (GUI läuft auf einem anderen Port) auf intern 22 an einem Server dahinter anlegen.

Ich gehe mal davon aus, daß es Deine Konfiguration ist, die das Problem verursacht.

Wenn Du diese Freigabe mit dem AVM-GUI einrichten willst (nachdem die Box ohne diese Freigabe gestartet wurde - damit eine ungültige, nicht angezeigte/gestartete nicht das Anlegen einer neuen behindert), was passiert denn genau?

"kann nicht angelegt werden" kann ja nun alles sein, vom fehlenden Button "Neue Freigabe" bis zu einer Fehlermeldung beim Speichern. Solange es keine Freigabe auf die Box selbst ist, müßte das mit dem AVM-Interface klappen. Hast Du ein anderes Gerät probiert? Manchmal ist auch die IP-Konfiguration des "Ziels" in der "landevices"-Sektion nicht eindeutig (zwei Devices mit derselben LAN-IP) und dann trifft das OS vermutlich (meine Erfahrung) keine Entscheidung für eine davon und richtet die Freigabe eben nicht ein - was auch durchaus richtig ist, falls AVM beim Umbenennen von Geräten irgendwann mal die Freigaben auch anpassen will.

Vielleicht läßt Du auch mal ungenutzte Clients entfernen ... wenn Du das nicht auch schon probiert haben solltest und nur ebenfalls vergessen hast es zu beschreiben.

 

[loomax]

Vielen Dank.

Ich habe versucht die Weiterleitung im Freetz AVM Portforwarding Interface einzutragen. Wenn ich die Weiterleitung eintrage und anschließend neustarte ist die Weiterleitung anschließend verschwunden.

Mit der alten Firmware funktioniert alles bestens - also auch die Freigabe von extern 443 auf intern 22.



Ich werde nochmal ein bisschen rumprobieren nachdem es bei dir ja anscheinend funktioniert.

 

[loomax]

Also ich hab noch mal alles getestet mit der neuesten Firmware -- Sobald der Fernzugriff ( bei mir über Port 444) aktiviert ist lässt sich der Port 443 nicht mehr freigeben.

Man kann die Freigabe im Freetz AVM Interface eintragen und auf "Übernehmen" drücken. Nach dem Reboot ist diese Freigabe aber dann verschwunden und es erscheint lediglich die Freigabe für Port 444 - Fernzugriff

 

[loomax]

Leider geht es auch mit der ganz aktuellen 6.80 Firmware nicht -- Hat jemand eine Idee ? Auch manuelles Ändern der ar7cfg und anschliessender reboot helfen nicht.

 

[PeterPawn]

Das ist generell alles umgestellt auf PCP, damit dürfte das Freetz-Interface (für die Portfreigaben auf die Box selbst) mit größter Wahrscheinlichkeit auch nicht mehr funktionieren (ich benutze kein Freetz-Image), aber das gilt schon für die gesamte Labor-Reihe und ist jetzt eigentlich nicht sooo überraschend. AVM sieht das wohl kaum als "Fehler" an und daher war irgendwie auch nicht zu erwarten, daß es sich in der Release-Version ändern würde.

Wie man es ggf. doch noch hinbekommt mit einer Weiterleitung auf die Box, steht hier: http://www.ip-phone-forum.de/showthread.php?t=289859

 

[loomax]

Super !!!!

Ich habe mit

ctlmgr -s

und voipd -s

die jeweiligen dienste gestoppt.

Anschliessend mit nvi /var/flash/ar7.cfg die Datei im Editor geöffnet.

Der eigentliche Trick ist die Regel nicht unter im Block internet_forwardrules einzutragen sondern unter


voip_forwardrules = ".....",
"tcp 0.0.0.0:443 0.0.0.0:22";

anschliessend habe ich die Datei gespeichert und mit

reboot

die Fritzbox neu gestartet.

 

[albundy118]

Hallo,
ich kämpfe leider mit 6.80 mit dem gleichen Problem, ich habe haproxy auf der Fritze laufen und brauche Port 443. Komischerweise wurde aus der ar7.cfg nur der 443 Forwarding Eintrag gelöscht andere von mir früher eingetragene blieben. Seither kann ich gar nichts mehr hinzufügen, egal ob 443 oder andere Ports.
Leider half bei mir auch nicht ein Versuch unter voip_forwardruls ... mit welcher FritzOS hast es funktioniert?
Ich wäre über weitere Ideen oder Lösungen dankbar!

 

[PeterPawn]

"rules", nicht "ruls". Vielleicht solltest Du diese erst einmal korrekt umsetzen und ausprobieren, bevor man über weitere Alternativen (die aber weiter oben auch schon verlinkt sind) nachdenkt. Ein "hat nicht geklappt" ist als "Fehlerbeschreibung" jetzt nicht sooo präzise.

 

[albundy118]

Tatsächlich hatte es nichts mit der Schreibweise von "voip_forwardrules" zu tun, denn das war, so wie du dir wahrscheinlich auch denken konntest, nur ein typo hier im Beitrag.
Nichts desto trotz, danke für den erneuten Hinweis auf die Lösung.
Es klappt tatsächlich wie hier von loomax beschrieben, durch stoppen der 2 Prozesse. Leider war mir nicht klar, dass hier timing gefragt ist, da sich die Prozesse sonst wieder aktivieren.
Wenn man also erst die ar7.cfg editiert (außerhalb /var/flash/ in temporärer Datei) und erst kurz vor dem zurück kopieren nach /var/flash/ die beiden Prozesse stoppt, klappt auch alles wie gewünscht.
Danke für eure Hilfe!

 

[PeterPawn]

Das Problem, daß der "ctlmgr" intern ein Abbild der aktuellen Konfiguration verwaltet und bei nachfolgenden Änderungen manuelle Eingaben/Änderungen in der "ar7.cfg" einfach wieder überschreibt, ist seit langer Zeit bekannt. Woher sollte ich hingegen wissen, daß es sich beim fehlenden "e" wirklich im einen Schreibfehler ausschließlich im Beitrag handelt und die Ursache des "Nichtfunktionierens" am Ende in einem Lesefehler im Thread zu finden war? Letzteres halte ich persönlich für weniger wahrscheinlich - das hängt sicherlich auch vom Leser bzw. Schreiber selbst ab.

Für weitere Leser, die das nicht mit der manuellen Eingabe von Kommandos "regeln" wollen, könnte ich "tvi" empfehlen. Der Aufruf erfolgt einfach als "tvi ar7.cfg" (die Angabe des Pfades nach "/var/flash" ist also nicht notwendig) und ggü. dem bei AVM verwendeten "nvi" hat es noch den Vorteil, daß vor dem "Zurückschreiben" in das TFFS-Gerät erst einmal geprüft wird, ob überhaupt eine Änderung erfolgte, die das erforderlich machen könnte. Das AVM-Skript (deutlich nicht für die "Öffentlichkeit" bestimmt) schreibt eben auch zurück, wenn man es nur zum Ansehen des Inhalts der Datei verwendet und keine Änderungen vornimmt (das belastet den Flash unnötig).

Endet die edtierte Datei dann auch noch auf ".cfg", wird auf Wunsch der "ctlmgr" vor dem Speichern gestoppt und im Anschluß neu gestartet. Das Stoppen und Neustarten des "voipd" in diesem Kontext hier (Ändern von Portforwardings) war bei mir gar nicht erforderlich - es kann allerdings auch nicht wirklich schaden, sollte aber auch im Nachhinein (also nach dem Neustart des "ctlmgr" während des Speichervorgangs) noch ausreichen, denn eine eigene "Kopie" der "ar7.cfg" schreibt der "voipd" dann doch eher nicht und nur diese würde - vor dem nächsten Neustart geschrieben - die eigenen Änderungen wieder rückgängig machen.

 

[Herbie_2005]

Vielen Dank an loomax und an albundy118 für die Tips. Es funktioniert wirklich!

 

[torsti76]

Vielen Dank an loomax und an albundy118 für die Tips. Es funktioniert wirklich!

Leider funktioniert es nicht mehr mit der aktuellen 113.06.83 auf der 7490.
Hat jemand hierfür schon eine Lösung?

 

[PeterPawn]

Leider funktioniert es nicht mehr mit der aktuellen 113.06.83 auf der 7490.

Etwas mehr "Fleisch" am hingeworfenen Knochen wäre ggf. hilfreich ... auch bei der 113.06.83 funktionieren sowohl in "voip_forwardrules" als auch in der "vpn.cfg" hinterlegte Freigaben (auch auf die Box selbst) in beiden üblichen Varianten - einmal als 1:1-Mapping und auch mit abweichendem externen Port.

Jedenfalls bei mir ist das so ... und das hat sich seit dem 06.69-Laborzweig auch nicht mehr geändert, soweit ich das verfolgt und getestet habe.

 

[torsti76]

Etwas mehr "Fleisch" am hingeworfenen Knochen wäre ggf. hilfreich ... auch bei der 113.06.83 funktionieren sowohl in "voip_forwardrules" als auch in der "vpn.cfg" hinterlegte Freigaben (auch auf die Box selbst) in beiden üblichen Varianten - einmal als 1:1-Mapping und auch mit abweichendem externen Port.

Bisher kannte ich nur die Variante, die Weiterleitungen in die "voip_forwardrules" einzutragen (wo sie bei mir auch nach wie vor drinstehen (*)), daher dachte ich, es wäre "Fleisch" genug.

(*) Dennoch funktionierte das 1:1-Mapping auf 443 nicht.

Ein in der "vpn.cfg" hinterlegter "ike_forwardrules" Eintrag funktioniert dahingegen prima. Danke für den Hinweis!