[Problem] Fritzbox 7390 Fon Wlan -- Portfreigabe -- Ziel nicht im Heimnetz ?!

Herbie_2005

Mitglied
Mitglied seit
31 Mrz 2007
Beiträge
413
Punkte für Reaktionen
17
Punkte
18
Hallo, Leute!

Seit den 84.06.10er-Versionen (dezeit Labor 84.06.10-28559 mit Freetz) habe ich ein merkwürdiges Problem mit den Portfreigaben. Ich benutze schon seit langem Portfreigaben, um meinen eigenen Server von außen erreichen zu können. Aber die funktionieren nun nicht mehr.

Meine Fritzbox hat im Netzwerk die IP4-Adresse 192.168.178.1 (wie gewöhnlich). Mein Heimnetzwerk ist also definiert durch 192.168.178.0, Subnetzmaske 255.255.255.0; genauso steht es im Bereich „Heimnetz“ der Fritzbox-Konfigurationsseite auch drin.

Wenn ich eine vorhandene Portfeigabe aktivieren oder eine neue Portfreigabe setzen will, die zu meinem Server 192.168.178.25 führt, dann kommt eine Fehlermeldung:
Code:
Die Portfreigabe kann nicht erstellt oder aktiviert werden, da das Ziel nicht im Heimnetz liegt.
Dieses Problem habe ich definitiv erst seit den 84.06.10er-Versionen, aber hier beständig.

Habe hier, im Forum und bei Google gesucht, aber rein gar nichts gefunden.

Hat irgend jemand eine Idee, was da falsch laufen könnte?
 

Anhänge

  • Fritzbox-Freigabe.jpg
    Fritzbox-Freigabe.jpg
    81.1 KB · Aufrufe: 149
Hallo,
Hast Du da ggf. etwas durch Freetz "zerstört" ?
 
Weiß nicht. Wenn ich zu einer 84.06.04-Version zurückgehe, ist wieder alles ok.
 
In freetz gibt es ja ein IF wo man die AVM Freigaben bearbeiten kann. Hast Du das schon versucht?

Wird Dein Server nicht in Netzwerk angezeigt? Wenn doch musst Du die IP nicht manuell eingeben sondern kannst das Gerät auswählen.
 
Hat irgend jemand eine Idee, was da falsch laufen könnte?
Offenbar prüft die AVM-Firmware beim Speichern einer neuen Portfreigabe jetzt, ob das freigegebene Ziel der Route nach hinter dem 'dev lan' liegt. Früher erfolgte die Prüfung mal nur mit Javascript im Browser und war entsprechend unflexibel.

Anders kann ich es mir jedenfalls nicht erklären, daß die Box bei mir (ich habe 192.168.0.0/16 als Route über ein Gateway hinter 'dev lan' konfiguriert) auch klaglos eine Portfreigabe zum (nicht existenten) Netzwerk-Client mit der IP 192.168.0.1 akzeptiert. Werfe ich die Route raus, wird eine solche Freigabe mit derselben Fehlermeldung wie bei Dir abgelehnt. Meine Box selbst hat dabei eine /28-Adresse.

Nicht falsch verstehen, ich begrüße das neue Verhalten ausdrücklich, damit wird das Zusammenbinden mehrerer Netzwerksegmente wesentlich leichter ... es könnte aber die Ursache für Dein Problem sein. Wenn Dein Freigabe-Ziel aus irgendeinem Grund nicht vom verwendeten Algorithmus dem richtigen Interface zugeordnet wird, gibt es diesen Fehler. Mach doch mal ein traceroute in einer Telnet-Konsole ...
 
Danke für Deine Antwort. Jetzt habe ich gerade wieder eine 84.06.04-Version drauf. Beim nächsten Versuch werde ich da mal genauer nachschauen.
 
Hallo,

leider kann ich seit der FW Version 6.20 keine Port Weiterleitung mehr in das Guest LAN machen, da bekomme ich genau diese Meldung:
Es ist ein Fehler aufgetreten.
Fehlerbeschreibung: Die Portfreigabe kann nicht erstellt oder aktiviert werden, da das Ziel nicht im Heimnetz liegt.
Bitte geben Sie Ihre Daten noch einmal ein. Sollte der Fehler erneut auftreten, wenden Sie sich bitte an den AVM-Support.

Geht bei der FW 84.06.04 ohne Problme. (reproduzierbar)

An einer Lösung diese Security Feature zu umgehen wäre ich sehr interessiert .....

Da heute die Telekom meinen Anschluss auf Vectoring umgestellt hat und Vektoring erst ab der AVM FW 6.20 wirklich unterstützt wird ..
Bei der FW 84.06.04 steht zwar das sie Vectoring könnte , kann sie aber nicht wirklich !

Ich habe die Portweiterleitug ins Gast LAN auch intensiv genutzt ...

Wer eine Lösung hat .. z.B. funktionierende ar7.cfg unter FW 6.20 bitte melden!

PS: einfach das Kommentar Zeichen entfernern funktioniert leider nicht
"#tcp 0.0.0.0:80 192.168.179.5:80 0 # http"
Die Einträge konnen in dem AVM Web GUI grundsätzlich gemacht werden, allerdings nicht aktiviert ... Dann kommt o.g. Fehlermeldung
 
Zuletzt bearbeitet:
Hab leider nach wie vor keine Lösung parat.
 
Ich habe dieses Problem nun auch...
Anscheinend bleiben alle "alte" Portfreigaben weiterhin aktiv, nur neue lassen sich nicht erstellen oder bestehende Protfreigaben verändern!

Ich habe mal bei AVM ein Ticket aufgemacht...
 
Ein Ticket bei AVM ist auf alle Fälle mal eine Maßnahme , ich bin auf die Antwort gespannt ;-)

PS: Bei mir sind leider auch die bestehenden Regeln deaktiviert worden ...
 
Bei mir sind ebenfalls die alten Regeln deaktiviert worden. Und sie lassen sich auch nicht reaktivieren (siehe obige Fehlermeldung).
 
Heute habe ich eine Antwort erhalten...
AVM hat keine Ahnung ;-)
Bei der Auswertung der Support-Daten und des Screenshots ist weiterhin
keine Ursache festzustellen.
Ich bin gebeten worden eine Rufnummer zu hinterlassen, um das Problem telefonisch zu besprechen.
 
Na das ist ähnlich wie ich es erwartet habe ...
Ich denke es stimmt etwas im Webinterface nicht.
Dort wird wahrscheinlich ein Prüfung der Ziel IP gemacht , allerdings ist die Gast LAN IP dort nicht gelistet ...

Ich bin weiterhin gespannt ob der Support von AVM diese Problem nachvollziehen kann und hoffentlich auch beheben kann/wird .

Meine ganze Infrastruktur ist auf den "Eingang" via Gast LAN ausgelegt...

VG
 
Ich habe die 86.06.04 im Einsatz - bei mir erlaubt die die Anlage und Aktivierung derartiger Regeln per GUI - funktionieren tut es dann allerdings nicht.

Ich glaube nicht, dass es nur das Webinterface ist, das Probleme macht, wie folgende Fehlermeldung zeigt (nachdem ich die Regeln in der ar7.cfg von Hand geändert hatte):

Code:
Oct 25 18:13:56 dsld[1029]: udslinterface_set_forwardrules: group=3
Oct 25 18:13:56 dsld[1029]: udslinterface_set_internet_forwardrules: FORWARDRULES_INTERNET_NORMAL=13
Oct 25 18:13:56 dsld[1029]: internet: 192.168.179.20 not an intern host, forwardrule "tcp 0.0.0.0:3004 192.168.179.20:3004 0 # XXX" ignored
Oct 25 18:13:57 dsld[1029]: udslinterface_set_forwardrules: group=13
Oct 25 18:13:57 dsld[1029]: udslinterface_set_forwardrules: group=10
Oct 25 18:13:57 dsld[1029]: udslinterface_set_forwardrules: group=11
Oct 25 18:13:57 dsld[1029]: udslinterface_set_forwardrules: group=12

Mir wäre Port-Forwarding ins Gastnetz (DMZ) auch sehr wichtig.
 
Das ist ja komisch , bis zur FW 84.06.04 (auf Fritzbox 7390) hat das bei mir immer einwandfrei funktioniert.
Anscheinend muss das Gast LAN in irgend einer Form "Mitglied" in einer "Gruppe" "verfügbare" Netzwerke sein.
 
PS: Ich habe eben nochmal meine ar7.cfg mit der "alten" verglichen , der einzige Unterschied was für das forwarding relevant war:

# tcp 0.0.0.0:pORT ......
tcp 0.0.0.0:pORT ....

Kommentar Zeichen und Blank entfernt dann die Änderung via

cp /var/tmp/ar7.cfg /var/flash/ar7.cfg
exec /etc/init.d/rc.net reload

aktiviert , und alles geht wieder ....

Im Webinterface ist es natürlich weiterhin als nicht aktiviert markiert ...

Ich gehe davon aus das jede Änderung im Webinterface (oder reboot) diese Einstellung wieder deaktivieren wird ...

Ich denke weiterhin es liegt am Webinterface welches die eingegebenen Daten prüft ;-)

Ich dachte eigentlich es genau so schon einmal gemacht zu haben ... wie auch immer, jetzt tut es erstmal ...
 
Zuletzt bearbeitet:
Sehr interessant...
Ich gehe davon aus, das AVM hier mitliest, da ich diesen Thread angegeben habe und weiß, dass hier schon jemand von AVM gelesen hat!
 
Na dann bin ich ja mal auf ein offizielles Statement von AVM gespannt ,
allerdings wäre mir ein patch/update definitiv lieber da das ganze etwas umständlich in der Handhabung ist ;-) ...
 
Ich denke es wird in diesem script geprüft und verworfen:

/usr/www/all/js/validate.js

Beim aktivieren der angelegten Regle im web interface werden folgende req. abgesetzt:

#request# POST http://FBIP/internet/port_fw.lua
POST /internet/port_fw.lua active_6=1&sid=SOMEID&apply=

danach wird u.a. validate.js aufgerufen das einige plausibilitäts Prüfungen der eingegeben Daten durchführt , und dann eben zu der bereits genannten Aussage kommt ..

Da es sich hier leider um Daten im ROM handelt die natürlich nur ro sind sind mir weitere debugging Tests zu aufwendig ..

cheers
 
Interessant! – Möglicherweise hat dieser Teil der genannten Datei „validate.js“ etwas mit dem Problem zu tun:
Code:
var net = ip.analyseNet(g_boxIp, g_boxNetmask);
if (!ip.addrInNet(net, clientStr)) {
for (var b=0; b < Math.ceil(net.net.length / 8); b++) {
var part = net.net.substr(b*8, 8);
if (ip.byteToBitstr(jxl.getValue(prefix+String(b))).substr(0,part.length) != part) {
mark(prefix+String(b));
}
}
return lib.outofnet;
}
if (ip.isNetAddr(net, clientStr)) {
mark(prefix + "3");
return lib.thenet;
}
if (ip.isBroadcast(net, clientStr)) {
mark(prefix + "3");
return lib.broadcast;
}
}
return res;
};
lib.checkIpNet = function(ipPrefix, netmaskPrefix, gatewayPrefix) {
var clientIp = ip.partsToQuad(ipPrefix);
var netmask = ip.partsToQuad(netmaskPrefix);
var gateway = ip.partsToQuad(gatewayPrefix);
var net = ip.analyseNet(clientIp, netmask);
if (ip.isNetAddr(net, clientIp)) {
mark(ipPrefix + "3");
return lib.thenet;
}
if (ip.isBroadcast(net, clientIp)) {
mark(ipPrefix + "3");
return lib.broadcast;
}
if (!ip.addrInNet(net, gateway)) {
for (var b=0; b < Math.ceil(net.net.length / 8); b++) {
var part = net.net.substr(b*8, 8);
if (ip.byteToBitstr(jxl.getValue(gatewayPrefix+String(b))).substr(0,part.length) != part) {
mark(gatewayPrefix+String(b));
}
}
return lib.outofnet;
}
if (ip.isNetAddr(net, gateway)) {
mark(gatewayPrefix + "3");
return lib.thenet;
}
if (ip.isBroadcast(net, gateway)) {
mark(gatewayPrefix + "3");
return lib.broadcast;
}
return lib.ok;
};
Näheres kann ich bisher allerdings nichts sagen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.