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

[han-solo]

Jetzt habe ich die Labor mit freetz gebaut und per remote geflashed und trotzdem kann ich die Freigabe nicht erstellen.
@koyaanisqats: Das ist doch mein eigener Kommentar. Das geht aber nur auf die Fritzbox selbst. Also 192.168.178.1

Ich habe das Problem, dass ich etwas nach 192.168.178.2 freigeben will. Diese IP ist aber Bestandteil einer Route und das merkt die FB vermutlich.
Naja, ich versuche mal die Route zu löschen, dann die Freigabe zu setzen und die Route wieder einzutragen.
Aber spätestens nach dem Neustart ist es sicherlich wieder deaktiviert.

Warum macht AVM sowas? Nervt voll ab!

EDIT:
Meldung: Es ist ein Fehler aufgetreten.
Fehlerbeschreibung: Die Route ist nicht zulässig.
Ihre Eingaben wurden möglicherweise nicht übernommen. Bitte versuchen Sie es noch einmal. Sollte der Fehler erneut auftreten, wenden Sie sich bitte an den AVM-Support.

Verdammt! Jetzt sind die Routen auch nicht mehr setzbar!
ich musste in der ar7.cfg die Routen auf "enable: yes" setzen und booten .... Grrrr!
Wie kann man dieses Abfrage-Script deaktivieren?


Gruß
HS

 

[PeterPawn]

Warum, nimm doch die FRITZ.Box_7390_BETA.84.06.21-29345.image.....

Ok, das wüßte ich jetzt gerne noch einmal genau. Eddie Dickens schreibt zwar, das Problem wäre in der 06.21 behoben, aber er meint damit sicherlich - alles andere wäre imho unlogisch - sein eigenes.

Nachdem in diesem Thread aber zwei verschiedene Probleme diskutiert wurden:

1. Der TE (herbie_2005) und Eddie Dickens konnten keine Portfreigaben in das LAN mehr einrichten.
2. meyergru und ein weiterer Leser konnten keine Portfreigaben in das Gastnetz einrichten.

geht aus der Erklärung "Problem ist behoben" ja nicht hervor, welches damit gemeint ist.

Während sich für 1. natürlich eine Lösung finden lassen muß, ist 2. offenbar nicht mehr vorgesehen/erlaubt/erwünscht/was auch immer. Da es von AVM dazu keine offiziellen Statements gibt, kann man das nur aus Tests für das Verhalten der Firmware schlußfolgern (und aus einer in Ansätzen zitierten Antwort des AVM-Supports in #43, wenn ich das wieder richtig verstanden habe).

Wenn jetzt also Eddie Dickens schreibt, sein Problem (Freigabe ins LAN) ist gelöst und han-solo versucht, durch Editieren der ar7.cfg etwas an seinem System zu aktivieren, was nach einem Neustart wieder verschwunden ist, dann handelt es sich - imho - auch wieder um Äpfel und Birnen, denn auch bei han-solo geht es ja wohl nicht um eine LAN-Freigabe.

Daher würde ich noch einmal um eine Klarstellung bitten, ob AVM wirklich mit der 06.21 die Rolle rückwärts vollzogen hat und sich nun Portweiterleitungen in andere interne Netze jenseits von "dev lan" (egal auf welchem Weg) doch wieder einrichten lassen.

Verdammt! Jetzt sind die Routen auch nicht mehr setzbar!

Meint das jetzt ein allgemeines Problem, eine spezifischere Route für ein Teilnetz des als "LAN" verwendeten Subnets zu setzen oder bezieht sich das nur auf Deinen Versuch, die Box durch die geänderte Reihenfolge der Aktionen (erst Weiterleitung, dann Route) zu "überlisten" ?

Warum macht AVM sowas? Nervt voll ab!

Ich bleibe - aber nur meine Meinung - dabei, daß das ein - für mich sehr angenehmer - Nebeneffekt der Implementierung des Gastnetzes (und der Hotspot-/Homespot-Funktionen in der Firmware - vermutlich auf Wunsch eines einzelnen Großabnehmers) ist.

Wenn sich eine Freigabe in das Hotspot-Netz einstellen ließe oder der Verkehr dafür (ingress oder egress) irgendwie vom Besitzer der Box mit eigenen Einstellungen zu beeinflussen wäre, würde ich das als eklatantes Sicherheitsproblem einstufen.

Und ein Gastnetz ist nun mal für "Gäste im Netz" gedacht (das sagt in meinen Augen schon der Name) und noch lange keine DMZ. Ein "Gast" ist nach meinem Verständnis auch jemand, der sich dort nur temporär aufhält ... wieso man auf ein solches temporäres Gerät eine Portfreigabe einrichten können muß, verschließt sich mir (muß aber nichts heißen). Wenn man dann dieses Gastnetz für eigene Zwecke "mißbraucht", muß man sich wohl auch mit den dortigen Gegebenheiten arrangieren. (Ich nehme aber an, Dein Problem ist gar nicht das Gastnetz, es war in diesem Thread nur schon Thema.)

Wer etwas ähnliches wie eine DMZ braucht, muß eben ein weiteres Gerät mit einem lokalen Interface im LAN als "exposed host" bereitstellen und kann dann von dort aus wieder beliebige Weiterleitungen machen oder das, was nicht weitergeleitet werden soll und ansonsten schon an der AVM-Firewall scheitert, dann dort erst blockieren.

Wobei Du ja unter Umständen (das müßtest Du aber selbst einschätzen und testen, ich habe ja keinen Schimmer, wohin Deine gesonderte Route für die .2 am Ende zeigen/gehen soll) mit einem gesplitteten Switch (also der Loslösung eines eth-Ports aus der lan-Bridge) doch noch zum Erfolg gelangen könntest. Wenn AVM da wirklich auf "dev lan" und nicht "Port x-y am Switch" testet, geht es wahrscheinlich nicht ... ansonsten ist es einen Versuch wert.

 

[han-solo]

Hallo,

ich stelle besser nochmal meine Umgebung dar.

{INTERNET} -> Fritzbox -> Netscreen Firewall -> LAN

Fritzbox = 192.168.179.1
guest = 192.168.181.1
Netscreen WAN = 192.168.179.2
Netscreen LAN = 10.4.70.1
LAN = 10.4.70.0/24

Ich baue von extern eine IPSec Verbindung zu meiner Netscreen auf. Deshalb hatte ich folgende Routen und Portfreigaben bis zur Firmware 6.05 aktiviert.

Route:

network: 10.4.70.0      255.255.255.0   192.168.179.2
network: 192.168.1.0    255.255.255.0	192.168.179.2		
network: 192.168.10.0   255.255.255.0	192.168.179.2

Port-Forwarding:

IPSec-VPN	UDP	500	> Netscreen 500		
IPSec-VPN	UDP	1701	> Netscreen 1701		
IPSec-VPN	UDP	4500	> Netscreen 4500

Und seit der Firmware 6.20 funktioniert es nicht mehr.
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.

Oder hat es etwas mit den IPSec Ports ansich zutun?
Ich möchte die aber trotzdem gerne weiterhin nutzen.

Gruß
HS

 

[Joe_57]

Fritzbox = 192.168.179.1
guest = 192.168.181.1

Normalerweise hat die FritzBox die IP-Adresse 192.168.178.1
In diesem Zustand wird das Gastnetz unter 192.168.179.x aufgebaut.

Bei dir liegt die Box-IP selbst ja schon im Standard-Gastnetzbereich.
Möglicherweise ist das ja die Ursache deiner Probleme.

Joe

 

[PeterPawn]

Oder hat es etwas mit den IPSec Ports ansich zutun?

Die Frage läßt sich ja leicht klären ... geht es denn für beliebige andere Ports auf die .2 weiterzuleiten ?

Solange in der AVM-Konfiguration nicht das IPSec genutzt wird (avmike gestartet ?), wüßte ich nicht, warum das nicht funktionieren sollte.

Wenn natürlich die FBox selbst schon die Freigabe auf 500/4500 hält, könnte das neue Verhalten imho durchaus zu der Fehlermeldung führen. Aber imho war es bisher zumindest immer so, daß die Weiterleitungen für die IPSec-Ports erst vom avmike eingerichtet wurden, sie stehen m.W. auch nur in der vpn.cfg.

Ob auf Deiner Box die Weiterleitungen aktiv sind oder nicht, kriegst du im proc-Interface des kdsld (dslifaces/internet/forwards oder so ähnlich, findest Du schon) heraus. Wenn da schon welche existieren, würde ich ggf. die vpn.cfg anfassen und dort die Weiterleitungen löschen (keine Ahnung, ob das reicht oder ob dann defaults greifen) oder auf andere Ports umlegen.

Wenn das alles nicht hilft, könntest Du die .2 immer noch als "exposed host" deklarieren (wenn das dann gehen sollte) und mußt dann schauen, ob die IPSec-Ports dort ankommen oder auf der FRITZ!Box "weggefangen" werden. Die Sicherheit der Netscreen-Firewall dürfte ja nicht leiden, wenn da auch etwas anderes als IPSec am WAN-Interface ankommt, das sollte sie ja selbst blocken können.

Normalerweise hat die FritzBox die IP-Adresse 192.168.178.1
In diesem Zustand wird das Gastnetz unter 192.168.179.x aufgebaut.

Wenn das nicht auch schon wieder geändert wurde, benutzt bei der 7490 das Gastnetz das Subnet 172.31.179.0/24 mit der Box als .1 - zumindest bei der 06.20 und ich hoffe mal, das wurde nicht erneut umgestoßen bei der 06.21-Laborversion.

 

[han-solo]

Ok, danke für den Hinweis. Also andere Ports wie z.B. 21 lassen sich auf die .2 weiterleiten. Wobei gelegentlich auch hier der Fehler kommt.
Aber wenn man es 2-3 mal probiert, klappt es irgendwann. Ist auch seltsam aber OK.

@PeterPawn: Kannst du mir bitte nochmal weiter helfen?

Ich hab erstmal folgendes gemacht und nix gefunden:

root@fritz:/# find . -name vpn.cfg
./etc/default.Fritz_Box_HW185/1und1/vpn.cfg
./etc/default.Fritz_Box_HW185/avm/vpn.cfg
./var/flash/vpn.cfg
root@fritz:/# cat ./var/flash/vpn.cfg
cat: can't open './var/flash/vpn.cfg': No such file or directory
root@fritz:/# cat ./etc/default.Fritz_Box_HW185/1und1/vpn.cfg
vpncfg {
}

// EOF
root@fritz:/# cat ./etc/default.Fritz_Box_HW185/avm/vpn.cfg
vpncfg {
}

// EOF

root@fritz:/proc/kdsld# grep -r 500 *
dsliface/internet/ipmasq/mappings:TCP 10.4.70.169:50094 88.76.x.x:50094 flags 0x4, state I, 1 entries, 0 pcp peers
dsliface/internet/ipmasq/mappings:TCP 192.168.179.34:50001 88.76.x.x:50001 flags 0x4, state I, 1 entries, 0 pcp peers

Gruß
HS

EDIT1:
Was ist das? Die Fritzbox hat die Portfreigabe 21 auf .2 wieder sebständig entfernt. ??????

EDIT2:
Versuch 'Exposed Host' zu setzen auf 192.168.179.2:
Die Portfreigabe kann nicht erstellt oder aktiviert werden, da das Ziel nicht im Heimnetz liegt.

 

[PeterPawn]

root@fritz:/# cat ./var/flash/vpn.cfg
cat: can't open './var/flash/vpn.cfg': No such file or directory

Ok, ist die vpn.cfg offenbar leer, in einer befüllten steht normalerweise so etwas drin:

vpncfg {
        connections {
[...]
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}

Wenn das bei Dir nicht der Fall ist, sollte es ja auch kein Problem sein. Das meinte ich aber, als ich schrieb, daß dann vielleicht Default-Einstellungen greifen. Deshalb wäre imho eine Möglichkeit, die o.a. Rules auf andere Ports abzuändern. Allerdings weiß ich auch nicht definitiv, ob AVM diese Einstellungen wirklich berücksichtigt.

Das zweite ziemlich sichere Zeichen, ob die Box VPN aktiviert hat, ist das Auftauchen von 'avmike' in der Prozessliste. Einen Blick ist es wert ...

Bei der 7490 gibt es eine interne Anzeige der extern zugelassenen Ports durch

root@FB7490:~ $ cat /proc/kdsld/dsliface/internet/ipmasq/forwards
---- UPnP-Forward rules ----
No forward rules

---- Man.Forward rules ----
tcp <external_ip>:5060 <fritzbox_ip>:5060 0 (voip)
tcp <external_ip>:8089 <fritzbox_ip>:8089 0  (tr069)
tcp <external_ip>:22 <interne_ip.2>:22 0  (normal)
udp <external_ip>:5060 <fritzbox_ip>:5060 0 (voip)
udp <external_ip>:7078+32 <fritzbox_ip>:7078 0 (voip)
udp <external_ip>:500 <fritzbox_ip>:500 0  (vpn)
udp <external_ip>:4500 <fritzbox_ip>:4500 0  (vpn)
---------------------------

Bei mir ist SIP/RTP, IPSec (IKE und NAT-T), TR-069 (unbenutzt, mal wieder bei Spielen ein "Rest") und SSH offen. Bei Dir dürfte da ja außer SIP/RTP nichts auf der Box selbst terminieren und die UDP-Ports 500/4500 sollten - nach dem grep zu urteilen - gar nicht auftauchen. Ein 'grep' halte ich (Bauchgefühl) im proc-Interface nicht immer für zielführend (obwohl natürlich auch ein grep sicherlich open/read/close macht) ... ich würde noch einmal "zu Fuß" in der Pseudodatei "forwards" nachsehen.

Was ist das? Die Fritzbox das die Portfreigabe 21 auf .2 wieder sebständig entfernt.

Da ist nicht zufällig die Freigabe des boxeigenen FTP-Servers für den Zugriff aus dem Internet aktiviert ?

Wenn AVM generell die Weiterleitung der UDP-Ports 500/4500 für IPSec an ein nachgelagertes Gateway verhindert, auch wenn der Benutzer das VPN der Box gar nicht nutzt, ist das imho wirklich ein Bug und wieder mal über's Ziel hinausgeschossen ... der Versuch mit dem "exposed host" wäre dann mein vorerst letzter Vorschlag mit dem Hintergrund, daß da hoffentlich unter "alles weiterleiten" automatisch auch 500/4500 fällt, wenn keine explizite Regel dafür unter 'forwards' auftaucht.

EDIT: Wenn da nicht etwas neues gebaut wurde, speist sich die Anzeige unter "Portfreigaben" aus dem, was da nach der "Meinung" des ctlmgr eigentlich eingerichtet sein sollte und das muß nicht zwingend mit dem unter "forwards" sichtbaren übereinstimmen. Die Anzeige unter "Sicherheit" greift aber m.W. inzwischen auf das kdsld-Interface zu und die dort angezeigten Werte sollten mit denen auf der Telnet-Kommandozeile übereinstimmen.

 

[han-solo]

Hallo,

nachfolgend meine Ausgabe.
Die Ports die ich brauche: 500, 1701, 4500 sind nicht dabei.

root@fritz:/var/mod/root# cat /proc/kdsld/dsliface/internet/ipmasq/forwards
---- UPnP-Forward rules ----
No forward rules

---- Man.Forward rules ----
tcp 188.107.70.139:5060 192.168.179.1:5060 0 (voip)
tcp 188.107.70.139:8089 192.168.179.1:8089 0  (tr069)
tcp 188.107.70.139:22 192.168.179.1:22 0  (normal)
tcp 188.107.70.139:1723 192.168.179.1:1723 0  (normal)
tcp 188.107.70.139:1195 192.168.179.1:1195 0  (normal)
tcp 188.107.70.139:21 10.4.70.106:21 0  (normal)
udp 188.107.70.139:5060 192.168.179.1:5060 0 (voip)
udp 188.107.70.139:7078+32 192.168.179.1:7078 0 (voip)
udp 188.107.70.139:5060 192.168.179.1:5060 0  (normal)
udp 188.107.70.139:11155 10.4.70.167:11155 0  (normal)
gre 188.107.70.139 192.168.179.1 0  (normal)
---------------------------
root@fritz:/var/mod/root#

Da ist nicht zufällig die Freigabe des boxeigenen FTP-Servers für den Zugriff aus dem Internet aktiviert ?

Ähm, nicht das ich wüsste.

der Versuch mit dem "exposed host" wäre dann mein vorerst letzter Vorschlag

Wie schon berichtet. Mein Versuch 'Exposed Host' auf auf 192.168.179.2 zu setzen bringt:
Die Portfreigabe kann nicht erstellt oder aktiviert werden, da das Ziel nicht im Heimnetz liegt.

Ich werde mal ein paar Tricks ausprobieren. Vielleicht auch mal die Routen entfernen und per rc.custom in freetz stezen.
Ich werde nämlich das Gefühl nicht los, dass es irgendwas damit zutun hat. Die Meldung besagt ja auch, dass die IP nicht im Heimnetz liegt und als Gatewas ist die IP ja ein Teil eines anderen Netzes.

 

[PeterPawn]

tcp 188.107.70.139:21 10.4.70.106:21 0 (normal)

Da ist doch eine FTP-Freigabe - nach dem, was Du vorher geschrieben hast, auf die LAN-Adresse der Firewall ... wie funktionieren das denn, läßt Du den FTP-Traffic direkt durch auf die LAN-Seite der Firewall ? :gruebel: Müßte da nicht vielmehr in der Firewall dann wieder ein weiteres Forwarding vom WAN-Interface aus erfolgen ? Die Firewall "weiß" dann ihrerseits, daß sie den ausgehenden Verkehr für eingehende TCP-Verbindungen nicht NAT'ten darf ?

Ähm, nicht das ich wüsste.

Ok, verstehe ich, als FTP hast Du ja offenbar irgendwas anderes freigegeben ... s.o., da steht ja nun mal ein Forwarding für Port 21 drin, keine Ahnung, wie man dann das EDIT1 in #66 verstehen muß.

Wie schon berichtet. Mein Versuch 'Exposed Host' auf auf 192.168.179.2 zu setzen bringt:
Die Portfreigabe kann nicht erstellt oder aktiviert werden, da das Ziel nicht im Heimnetz liegt.
Ich werde mal ein paar Tricks ausprobieren. Vielleicht auch mal die Routen entfernen und per rc.custom in freetz stezen.

Ich werde das Gefühl nicht los, daß Du da schon etwas zu viel getrickst hast. Wenn da schon andere Routen/Forwards auf die .2 zeigen, wird da imho immer Unsinn bei herauskommen.

Wenn Du wirklich bei ansonsten leeren custom-routes und ohne eingerichtete Portweiterleitungen (egal wofür) auf die .2 bei einer Adresse von 192.168.179.1/24 auf dem LAN-Interface der Box keinen exposed host einrichten kannst, läge da wirklich etwas im argen ... aber angesichts der diversen Portweiterleitungen auf Dienste auf der FRITZ!Box selbst (PPTP, vmtl. OpenVPN, SSH) ist das ja nun alles andere als "native" und da funken wohl eher die Änderungen durch das "AVM-Portforwarding" im Freetz dazwischen, als daß da die AVM-Firmware nicht funktioniert.

Ich habe es zwar nur auf einer 7390 mit LAN1-WAN probiert (von einem signifikanten Unterschied bei der Behandlung von Routen und Forwards habe ich - bei gleichem Firmwarestand - noch nichts gelesen), aber bei mir (7390, original AVM-06.20) ließen sich Forwards für die beim IPSec benötigten Protokolle/Ports problemlos einrichten und zu allem Überfluß auch noch ein "exposed host" für dieselbe Adresse einrichten.
Anhang anzeigen 78952
Ob da dann die Reihenfolge eine Rolle spielt (imho schon, die Regeln werden sicherlich sequentiell durchforstet, aber es könnte natürlich sein, daß die AVM-Firmware die ip-Regel immer an den Schluß setzt), weiß ich nicht:

root@FB7390:/# cat /proc/kdsld/dsliface/internet/ipmasq/forwards
---- UPnP-Forward rules ----
No forward rules

---- Man.Forward rules ----
tcp 192.168.131.7:21 192.168.132.1:21 0  (normal)
tcp 192.168.131.7:443 192.168.132.1:443 0  (normal)
udp 192.168.131.7:500 192.168.132.5:500 0  (normal)
udp 192.168.131.7:4500 192.168.132.5:4500 0  (normal)
esp 192.168.131.7 192.168.132.5 0  (normal)
ip 192.168.131.7 192.168.132.5 0  (normal)
---------------------------

Ergo mußt wohl auch Du Dich schon an eine bestimmte Reihenfolge bei den ganzen Manipulationen halten. Es ist jedenfalls kein plattes Skript, was da irgendwo eine Prüfung macht. In jedem Falle ist es mindestens der ctlmgr, nach meinem Dafürhalten sogar der dsld, der da die Freigaben einrichtet und das auch vorher noch einmal richtig prüft.

 

[han-solo]

Ohje, ich habe das Problem lokalisiert. Und zar werden die Portfreigaben nicht angenommen, solange mein OpenVPN läuft.
Das ist aber NEU, denn ich hatte OpenVPN schon immer in meinem freetz und es machte bislang keine Probleme.

Und wenn ich OpenVPN stoppe und die Freigaben aktiviere, werden diese wieder deaktiviert wenn ich OpenVPN starte.

 

[Herbie_2005]

Interessant. Ich habe ebenfalls eine gefreezte Firmware mit Openvpn. Und ich kann Deine Aussage bestätigen.

 

[han-solo]

Tja, stellt sich jetzt nur die Frage warum die Fritzbox auf einmal so etwas tut und vor allem, wie man dies umgehen kann.

Edit:
Ich werde dazu mal einen neuen Beitrag eröffnen. Passt ja dann doch nicht ganz hier herein.

 

[PeterPawn]

Ich werde dazu mal einen neuen Beitrag eröffnen. Passt ja dann doch nicht ganz hier herein.

Na ja, nachdem der Thread Herbie_2005 "gehört", ist es ja nicht uninteressant, wenn das zu seinem Problem passt. Da waren dann eher die anderen - nebenbei geklärten oder noch zu klärenden - Fragen OT.

Ich denke mal, es liegt daran, daß beim Starten/Beenden des OpenVPN das tun-/tap-Interface "up/down" geschaltet wird und da dann der dsld noch einmal über die Einstellungen drüber schaut, ob da wegen des zusätzlichen oder fehlenden Interfaces irgendwas neu gesetzt werden sollte. Wenn ich es richtig sehe, ist das Interface bei den meisten (wenn man das Freetz-CGI nimmt zum Konfigurieren) auch an die lokale LAN-Adresse gebunden, was dann zur einer Rekonfiguration der lan-Bridge führen dürfte ... vielleicht ist das auch die eigentliche Ursache ?

Mit fällt jetzt aus dem Stand aber auch keine Methode ein, wie man das Interface für OpenVPN "vorbelegen" könnte bzw. das hängt stark davon ab, was man mit OpenVPN auf der Box eigentlich genau macht (server vs. client, tap vs. tun). Ich würde glatt versuchen, das OpenVPN-Interface nicht auf die LAN-Adresse zu setzen beim Start von OpenVPN, sondern es erst später in irgendeinem Skript mit brctl an die lan-Bridge zu tackern ... aber das ist nur eine Idee und ich habe es nicht selbst getestet, außerdem klappt es wahrscheinlich ohnehin nicht in jedem Mode vom OpenVPN.

 

[han-solo]

Also Bug oder Feature ist hier die Frage. An meinem OpenVPN hängen mehr als 10 clients mit Zertifikaten und die meisten Besitzer dieser Clients haben keine Ahnung davon.
Wenn ich einen Weg finden würde das umzukonfigurieren, müsste ich alle Clients abklappern und hätte Arbeit ohne Ende. Und ich glaube ich bin auch nicht der Einzige mit dem Problem.

Ich denke die beste Lösung wäre ein Patch, der dieses, sagen wir mal Feature, deaktiviert.
Diesen in feetz zur Auswahl einbauen und weg ist das Problem. Ich bin dazu aber leider nicht in der Lage. :-(

 

[PeterPawn]

Wenn ich einen Weg finden würde das umzukonfigurieren, müsste ich alle Clients abklappern und hätte Arbeit ohne Ende.

Solange diese Clients nicht ihrerseits alle irgendwelche Portforwardings brauchen, mußt Du doch da gar nichts ändern.

Ich war gerade dabei, im anderen Thread nach zwei Ausgaben (vier bei 1x mit, 1x ohne aktives OpenVPN) zu fragen (ifconfig + brctl show) und nach der - maskierten - OpenVPN-Konfiguration. Das ist leichter, als wenn ich mir jetzt alle vier Fälle für OpenVPN-Modi ausmale (s.o.) und dafür mühsam Konfigurationen erstelle, um die Ausgaben der erwähnten Kommandos zu sehen.

Kannst Du bitte im neuen Thread diese Angaben noch zum ersten Beitrag hinzufügen ?

BTW: Die Idee mit dem Patch kannst Du imho vergessen, das ist in den Binaries verankert (habe ich schon vor drei Monaten geprüft, als ich Herbie_2005 das erste Mal auf das geänderte Verhalten als mögliche Ursache aufmerksam machte in #5) und wenn da irgendwas in irgendwelchen Skripten erfolgt, dann ist das nur "convenience" im Webinterface.

 

[han-solo]

Ok, meine ifconfig Ausgaben mit und ohne OpenVPN habe ich aufgeführt. Aber 'brctl' zeigt bei mir keine Ausgabe.

Edit: Die Clients müssen bei mir mindestens IP 192.168.179.1 und 192.168.179.2 connecten können.

 

[PeterPawn]

brctl show

- zeigt die zu einer Bridge "zusammengebundenen" Interfaces an, bei einer 7490 ohne Gastnetz sind das die 4 eth-Interfaces und das wlan-Interface.
- interessant ist es, ob und wenn ja wie, das tun/tap da auftaucht, deshalb auch 1x mit und 1x ohne OpenVPN

 

[han-solo]

root@fritz:/var/mod/root# brctl show
brctl: invalid argument 'show' to 'brctl'

 

[PeterPawn]

Keine Ahnung, was Du da für eine Busybox im Freetz hast oder ob da sogar ein standalone-brctl rumgeistert.

Kannst noch ein explizites "busybox" (wg. der Versionsnummer) und ein "busybox brctl show" probieren ... ansonsten weiß ich auch nicht, was da bei Dir Sache ist.

Sollte eigentlich bei einer 7490 mit BB (BusyBox v1.22.1 (2014-11-17 01:21:01 CET) multi-call binary.) inkl. brctl-Applet in etwas so aussehen:

root@FB7490:~ $ brctl show
bridge name     bridge id               STP enabled     interfaces
lan             8000.0896d76e9a31       no              eth0
                                                        eth1
                                                        eth2
homewlan        8000.0896d76e9a31       no              wlan
guest           8000.0896d76e9a31       no              eth3

Aber nur in etwa, ich habe bei mir das WLAN aus der LAN-Bridge herausgelöst.

 

[han-solo]

login as: root
Authenticating with public key "xxxxxx" from agent
   __  _   __  __ ___ __
  |__ |_) |__ |__  |   /
  |   |\  |__ |__  |  /_

   The fun has just begun ...


BusyBox v1.22.1 (2014-11-18 10:20:45 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

root@fritz:/var/mod/root# busybox
BusyBox v1.22.1 (2014-11-18 10:20:45 CET) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2012.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, addgroup, adduser, arp, arping, ash, awk, base64, basename, brctl, bunzip2, bzcat, bzip2, cat, chgrp, chmod, chown, chroot,
        cmp, cp, crond, crontab, cryptpw, cut, date, dd, delgroup, deluser, df, dirname, dmesg, dnsdomainname, du, echo, egrep, env,
        ether-wake, expr, false, fgconsole, fgrep, find, flock, free, ftpget, ftpput, getopt, grep, groups, gunzip, gzip, halt, head,
        hexdump, hostname, httpd, id, ifconfig, ifdown, ifup, inetd, init, insmod, iostat, ip, kill, killall, killall5, klogd, ln, logger,
        login, logname, logread, ls, lsmod, makedevs, md5sum, mkdir, mkfifo, mknod, mkpasswd, mkswap, modprobe, more, mount, mpstat, mv,
        nbd-client, nc, netstat, nice, nohup, nslookup, passwd, pidof, ping, ping6, pivot_root, pmap, poweroff, printenv, printf, ps,
        pstree, pwd, pwdx, readlink, realpath, reboot, renice, reset, rm, rmdir, rmmod, route, sed, seq, setconsole, setserial, sh, sleep,
        smemcap, sort, start-stop-daemon, stat, stty, stun-ip, swapoff, swapon, switch_root, sync, sysctl, syslogd, tail, tar, tee,
        telnetd, test, time, top, touch, tr, traceroute, true, tty, ubimkvol, ubirmvol, ubirsvol, ubiupdatevol, umount, uname, uniq, unxz,
        unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, wc, wget, which, whois, xargs, xz, xzcat, yes, zcat

root@fritz:/var/mod/root# busybox brctl show
brctl: invalid argument 'show' to 'brctl'
root@fritz:/var/mod/root#
root@fritz:/var/mod/root# brctl --help
BusyBox v1.22.1 (2014-11-18 10:20:45 CET) multi-call binary.

Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
        addbr BRIDGE            Create BRIDGE
        delbr BRIDGE            Delete BRIDGE
        addif BRIDGE IFACE      Add IFACE to BRIDGE
        delif BRIDGE IFACE      Delete IFACE from BRIDGE

root@fritz:/var/mod/root#