11
Portforwarding auf eigenen Teamspeakserver für die Kinder und deren Freunde
Guten Abend Forum.
Meine Kinder baten mich, einen Teamspeakserver (und auch gleich, damit es sich lohnt, einen Minecraft Server) bereit zu stellen.
Ich habe beides in eine VM unter Win7pro installiert und im LAN funktioniert der Zugriff auch bestens, ebenso wie von extern über eine VPN Verbindung (wird über eine Synology DS212j und deren VPN Server per PPTP gemacht).
Jetzt hatte ich ausprobiert, den TS3 und Minecraft Server durch Portforwarding (FritzBox 7490) direkt ohne VPN von außen zugänglich zu machen., also die entsprechenden Ports in der FB der bereitstellenden VM (VirtualBox im Bridge Mode) zugeordnet (wie im Standard: TS3 Port 9987 und Minecraft 25565).
Beides ist aber von außen nicht erreichbar. Ein Ping im LAN sowie als auch von Extern auf die DynDNS ist positiv und zeigt richtig die aktuelle IP der FritzBox (DynDNS sowohl mit dem Dienst von Synology als auch einem weiteren funktioniert demnach). Die Firewall von Win7 in der VM habe ich schon komplett abgeschaltet, dennoch kein Connect möglich.
Was übersehe ich?
Danke und Grüße
PS Ist das überhaupt in der richtigen Rubrik eingeordnet?
Meine Kinder baten mich, einen Teamspeakserver (und auch gleich, damit es sich lohnt, einen Minecraft Server) bereit zu stellen.
Ich habe beides in eine VM unter Win7pro installiert und im LAN funktioniert der Zugriff auch bestens, ebenso wie von extern über eine VPN Verbindung (wird über eine Synology DS212j und deren VPN Server per PPTP gemacht).
Jetzt hatte ich ausprobiert, den TS3 und Minecraft Server durch Portforwarding (FritzBox 7490) direkt ohne VPN von außen zugänglich zu machen., also die entsprechenden Ports in der FB der bereitstellenden VM (VirtualBox im Bridge Mode) zugeordnet (wie im Standard: TS3 Port 9987 und Minecraft 25565).
Beides ist aber von außen nicht erreichbar. Ein Ping im LAN sowie als auch von Extern auf die DynDNS ist positiv und zeigt richtig die aktuelle IP der FritzBox (DynDNS sowohl mit dem Dienst von Synology als auch einem weiteren funktioniert demnach). Die Firewall von Win7 in der VM habe ich schon komplett abgeschaltet, dennoch kein Connect möglich.
Was übersehe ich?
Danke und Grüße
PS Ist das überhaupt in der richtigen Rubrik eingeordnet?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 316248
Url: https://administrator.de/contentid/316248
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
11 Kommentare
Neuester Kommentar
Könntest du mal einen oder zwei Screenshots von den Regeln auf der Fritzbox schicken?
Hi WandaStaab,
wenn das der einzige Port für TS3 ist reicht das nicht.
Und Minecraft benötigt TCP und UDP weiterletungen auf dem Port 25565 laut Anleitung.
Dann kommt mir aber eine Frage auf, weshalb bohrst du dein Netzwerk auf und gibst Ports frei auf deiner Fritzbox auf eine Win7 Maschine? Wenn es im sicheren VPN Protokoll funktioniert?
Grüße
wenn das der einzige Port für TS3 ist reicht das nicht.
Ein Teamspeak3 Server benutzt folgende Ports:
Default port (UDP eingehend): 9987
Default filetransfer port (TCP eingehend): 30033
Default serverquery port (TCP eingehend): 10011
Default weblist port (UDP ausgehend): 2010
Default tsdns port (TCP eingehend): 41144
Default accounting port (TCP ausgehend): 2008Und Minecraft benötigt TCP und UDP weiterletungen auf dem Port 25565 laut Anleitung.
Dann kommt mir aber eine Frage auf, weshalb bohrst du dein Netzwerk auf und gibst Ports frei auf deiner Fritzbox auf eine Win7 Maschine? Wenn es im sicheren VPN Protokoll funktioniert?
Grüße
Zitat von @IrunGoldstein:
Dann kommt mir aber eine Frage auf, weshalb bohrst du dein Netzwerk auf und gibst Ports frei auf deiner Fritzbox auf eine Win7 Maschine? Wenn es im sicheren VPN Protokoll funktioniert?
Dann kommt mir aber eine Frage auf, weshalb bohrst du dein Netzwerk auf und gibst Ports frei auf deiner Fritzbox auf eine Win7 Maschine? Wenn es im sicheren VPN Protokoll funktioniert?
Mit VPN würden die freunde ja an alle System im lokalen netz kommen.
lks
PS: Meine Lösung wäre, entweder einen billgen vserver für 5€/Monat dafür zu mieten oder eine DMZ dafür einzurichten und die Kinners dann per VPN in die DMZ zu lassen.
Mit welcher IP Adresse sprichst du denn von außen den Minecraft Server bzw. TS an ?
Dir ist hoffentlich klar das die Ziel IP dann NICHT die lokale LAN IP ist sondern immer die WAN Port IP der FritzBox !
Also die IP die der Provider der FritzBox zuteilt !
Die Frage ist auch warum du das so umständlich machst und 2 VMs nutzt. Das ist eigentlich unsinnig. Eine VM reicht für Minecraft und da dann am besten den schlanken Mumble Server als Sprach Konferenzsystem drauf laufen lassen.
Allemal schlanker und performanter.
Die ganzen Löcher die du in deine FB Firewall bohren musst um die durchlässig zu machen sind schon beunruhigend !
Warum man auch als FB Besitzer, die ja einen eingebauten VPN Server mitbringt, umständlich noch das alte und unsicherere PPTP auf einem internen NAS machen muss und sich dann wiederum mit Port Forwarding rumschlagen muss bleibt vollkommen unverständlich..?! Das FB VPN wäre weitaus sinnvoller wenn man denn VPN machen will.
Vermutlich mangelt es hier an Design Know How. Das zeigt leider die gesamte Vorgehensweise
Aber warum einfach machen wenn es umständlich auch geht...?!
Dir ist hoffentlich klar das die Ziel IP dann NICHT die lokale LAN IP ist sondern immer die WAN Port IP der FritzBox !
Also die IP die der Provider der FritzBox zuteilt !
Die Frage ist auch warum du das so umständlich machst und 2 VMs nutzt. Das ist eigentlich unsinnig. Eine VM reicht für Minecraft und da dann am besten den schlanken Mumble Server als Sprach Konferenzsystem drauf laufen lassen.
Allemal schlanker und performanter.
Die ganzen Löcher die du in deine FB Firewall bohren musst um die durchlässig zu machen sind schon beunruhigend !
Warum man auch als FB Besitzer, die ja einen eingebauten VPN Server mitbringt, umständlich noch das alte und unsicherere PPTP auf einem internen NAS machen muss und sich dann wiederum mit Port Forwarding rumschlagen muss bleibt vollkommen unverständlich..?! Das FB VPN wäre weitaus sinnvoller wenn man denn VPN machen will.
Vermutlich mangelt es hier an Design Know How. Das zeigt leider die gesamte Vorgehensweise
Aber warum einfach machen wenn es umständlich auch geht...?!
Guten Morgen IrunGoldstein.
Du hast völlig Recht, ist an sich eine dämliche Idee, die Firewall unnötigerweise zu öffnen. Aber die, die darauf zugreifen wollen, sind 9-12 Jahre alt und 'hochspezialisiert', will sagen, sie können zocken, aber ich muss gar nicht erst anfangen, Ihnen mehr über die darunter liegende Technik nahe zu bringen (ich bekomme ja selbst nur das Nötigste hin). Der VPN Zugang funktioniert auch nicht immer zuverlässig beim ersten Klick, manchmal braucht es eben deren drei, damit die Verbindung steht. Darüberhinaus läuft der gesamte Internetverkehr dann über unsere Leitung, die nicht die dickste ist (ADSL bei 1&1 mit 11MBit / 1 MBit).
Ich habe noch keine Möglichkeit gefunden PPTP VPN auf einem Windows 10 Client so zu konfigurieren, dass eben nicht der gesamte Datenverkehr über unseren Anschluss läuft. Das hat zwar mit dem Shrew Soft VPN Client über ipsec nach Anleitung bei AVM funktioniert, aber wenn ich jetzt jedem der Kinder einen VPN Client auf deren Rechner installiere, verbringe ich meine Freizeit nur noch mit VPN Client Wartung.
Da sie sich auch auf anderen Minecraft Servern treffen, wäre der Aspekt also nicht kriegsentscheidend. Der Teamspeakserver sollte aber gehen, da sie derzeit beim Spielen per Telefon kommunizieren und damit auch mal gerne 2-3 Stunden die Leitung blockieren, dann wundern sich sämtliche Omas, wer da so lange spricht und die Mütter sind genervt.
Win7 eben weil die entsprechenden Lizenzen vorhanden sind.
Habe die Ports wie von Dir beschrieben geöffnet (siehe Screenshot, 'ausgehend' kann man bei der FB aus meiner Sicht nichts öffnen, das sollte generell offen sein), geht aber dennoch nicht.
Die 'Kindersicherung' ist übrigens sowohl für die VM (VM-MC = 192.168.178.212) als auch deren Host komplett frei gegeben (das geht bei mir auch gerne mal vergessen).
Danke und Grüße
Du hast völlig Recht, ist an sich eine dämliche Idee, die Firewall unnötigerweise zu öffnen. Aber die, die darauf zugreifen wollen, sind 9-12 Jahre alt und 'hochspezialisiert', will sagen, sie können zocken, aber ich muss gar nicht erst anfangen, Ihnen mehr über die darunter liegende Technik nahe zu bringen (ich bekomme ja selbst nur das Nötigste hin). Der VPN Zugang funktioniert auch nicht immer zuverlässig beim ersten Klick, manchmal braucht es eben deren drei, damit die Verbindung steht. Darüberhinaus läuft der gesamte Internetverkehr dann über unsere Leitung, die nicht die dickste ist (ADSL bei 1&1 mit 11MBit / 1 MBit).
Ich habe noch keine Möglichkeit gefunden PPTP VPN auf einem Windows 10 Client so zu konfigurieren, dass eben nicht der gesamte Datenverkehr über unseren Anschluss läuft. Das hat zwar mit dem Shrew Soft VPN Client über ipsec nach Anleitung bei AVM funktioniert, aber wenn ich jetzt jedem der Kinder einen VPN Client auf deren Rechner installiere, verbringe ich meine Freizeit nur noch mit VPN Client Wartung.
Da sie sich auch auf anderen Minecraft Servern treffen, wäre der Aspekt also nicht kriegsentscheidend. Der Teamspeakserver sollte aber gehen, da sie derzeit beim Spielen per Telefon kommunizieren und damit auch mal gerne 2-3 Stunden die Leitung blockieren, dann wundern sich sämtliche Omas, wer da so lange spricht und die Mütter sind genervt.
Win7 eben weil die entsprechenden Lizenzen vorhanden sind.
Habe die Ports wie von Dir beschrieben geöffnet (siehe Screenshot, 'ausgehend' kann man bei der FB aus meiner Sicht nichts öffnen, das sollte generell offen sein), geht aber dennoch nicht.
Danke und Grüße
Nö, sie sind 9-12 Jahre alt, auf Spiele spezialisiert und ansonsten, noch und GottseiDank, nicht in der Lage das zu erkennen oder zu nutzen.
VServer ist echt überdimensioniert, auch wenn die Kosten überschaubar sind. Nö, sehe ich nicht ein.
Aaha, die Profis sind wach! Super!
Zitat von @aqui:
Mit welcher IP Adresse sprichst du denn von außen den Minecraft Server bzw. TS an ?
Dir ist hoffentlich klar das die Ziel IP dann NICHT die lokale LAN IP ist sondern immer die WAN Port IP der FritzBox !
Also die IP die der Provider der FritzBox zuteilt !
Das ist völlig klar. Ein Ping auf die DynDNS Adresse von aussen gibt ja auch die externe IP der FB korrekt zurück.Mit welcher IP Adresse sprichst du denn von außen den Minecraft Server bzw. TS an ?
Dir ist hoffentlich klar das die Ziel IP dann NICHT die lokale LAN IP ist sondern immer die WAN Port IP der FritzBox !
Also die IP die der Provider der FritzBox zuteilt !
Die Frage ist auch warum du das so umständlich machst und 2 VMs nutzt. Das ist eigentlich unsinnig. Eine VM reicht für Minecraft und da dann am besten den schlanken Mumble Server als Sprach Konferenzsystem drauf laufen lassen.
Nein, es ist nur eine VM, auf der Minecraft und Teamspeak Server laufen. VM deshalb, weil auf dem Host der VM noch andere Sachen betrieben werden und ich es einfach trennen möchte. Mumble hatte ich ausprobiert, ist aber schwieriger auf der Client Seite zu konfigurieren als Teamspeak, und wenn Du schon mal Mumble konfiguriert hast, wovon ich stark ausgehe, und jetzt den Kopf gegen die Wand schlägst, was daran schwierig sein könnte, dann hast Du sowas noch nicht mit Kindern in dem betreffenden Alter gemacht und ich wünsche es Dir auch nicht. Auch ich war schon an dem Punkt, sie einfach tief im Wald auszusetzen.Die ganzen Löcher die du in deine FB Firewall bohren musst um die durchlässig zu machen sind schon beunruhigend !
Ja, bin völlig bei Dir.Warum man auch als FB Besitzer, die ja einen eingebauten VPN Server mitbringt, umständlich noch das alte und unsicherere PPTP auf einem internen NAS machen muss und sich dann wiederum mit Port Forwarding rumschlagen muss bleibt vollkommen unverständlich..?! Das FB VPN wäre weitaus sinnvoller wenn man denn VPN machen will.
Die FB macht nur IPSec, dafür müsste ich den Kiddies aber einen Client installieren, den Umgang damit zu erklären und wofür das Teil gut ist, habe ich nach dem ersten Versuch abgebrochen (Wald und so, siehe oben...). PPTP bringt Windows mit, ist daher unmissverständlich ('Guck, hier musst Du klicken...')Vermutlich mangelt es hier an Design Know How.
Ja, sicher deswegen frage ich ja hier. Wenn ich das Know-How hätte, würde ich ein eigenes Forum betreiben.Das zeigt leider die gesamte Vorgehensweise
Naja, in ganz, ganz engen Grenzen, macht es schon ein bisschen Sinn.Aber warum einfach machen wenn es umständlich auch geht...?!
Um zu lernen?!
Vielleicht sollte ich noch die eine oder andere Info hinterherschicken.
Der Host, auf dem die VM mit TS und MC läuft, ist an die FB per WLAN angebunden. Die FB ist nicht in der Lage, die VM und den Host so richtig zu unterscheiden. Mal ordnet sie in der Übersicht der Netzwerkgeräte dem Host der VM die IP der VM selbst zu (sperrt dann den INet-Zugang) und mal nicht, dann erkennt sie aber oft gar nicht, dass die VM bei ihr angemeldet ist und läuft. Das VB Manual sagt nun 'Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines.'
Ist das so und erkennt da die FB eine Regelverletzung und blockt daher?
Ich hatte zwei drei Mal die letzten Jahre Kontakt zum Support vom AVM, da keine der letzten OS Varianten der FB VMs auf per WLAN angebundenen Hosts dauerhaft und sicher erkennen und zuordnen konnte. Die Aussage des AVM Supports war, die 'Kindersicherung' könne nur korrekt arbeiten, wenn man keine statischen IP vergibt (wie ich in dem Fall für den Host und die VM). Das kann ich mir allerdings nicht so recht vorstellen, weil eine IP/MAC Kombi ist doch nun mal eine IP/MAC Kombination und ergibt sich aus der MAC der Schnittstelle und der egal wie vergebenen IP Adresse. Wenn ich beides eindeutig wähle, sollte es doch egal sein, ob die IP vom DHCP kommt oder statisch vegeben wird (solange sie ausserhalb des DHCP Bereichs ist).
Um ein Beispiel zu geben:
Host ist statisch z.B. MAC 'xx' und IP 192.168.178.213 und ebenfalls statisch VM ist MAC 'yy' und IP .212.
Wähle ich in der Netzkonfiguration von VB 'promiscuous mode = deny' bzw. 'promiscuous mode = erlauben für alle VM und host', dann erkennt die FB nicht mehr den Unterschied zwischen dem Host und der VM, ordnet die IP mal dem einen und mal dem anderen Gerät zu (Host MAC zwar 'xx' aber IP .212), sperrt mal den INet Zugang der VM und mal nicht, habe noch keine Gesetzmäßigkeit gefunden, woran es liegt.
Setze ich in der Netzkonfiguration von VB 'promiscuous mode = erlauben für alle VM', dann erkennt die FB relativ zuverlässig den Unterschied zwischen dem Host und der VM, ordnet die IP korrekt zu, erkennt aber selten, dass die VM läuft (wird nicht als verbundenes Netzgerät angezeigt). INet Zugang der VM ist dann oft nicht möglich, obwohl die FB keinen Sperreintrag zeigt.
Die Netzwerkkarte des Hosts ist übrigens eine TP Link WDN 4800.
Ich weiss gar nicht, wie ich erwarten kann, dass das hier jemand liest, geschweige denn versucht zu verstehen. Aber sollte es jemand bis hierher geschafft haben (Gratulation!), folgt wahrscheinlich der Rat, zum ersten WLAN durch Kabel zu ersetzen (geht leider in dem Fall nicht) und zum zweiten es eben zu vergessen (geht!). Aber vielleicht kommt ja doch noch ein hilfreicher Hinweis.
Der Host, auf dem die VM mit TS und MC läuft, ist an die FB per WLAN angebunden. Die FB ist nicht in der Lage, die VM und den Host so richtig zu unterscheiden. Mal ordnet sie in der Übersicht der Netzwerkgeräte dem Host der VM die IP der VM selbst zu (sperrt dann den INet-Zugang) und mal nicht, dann erkennt sie aber oft gar nicht, dass die VM bei ihr angemeldet ist und läuft. Das VB Manual sagt nun 'Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines.'
Ist das so und erkennt da die FB eine Regelverletzung und blockt daher?
Ich hatte zwei drei Mal die letzten Jahre Kontakt zum Support vom AVM, da keine der letzten OS Varianten der FB VMs auf per WLAN angebundenen Hosts dauerhaft und sicher erkennen und zuordnen konnte. Die Aussage des AVM Supports war, die 'Kindersicherung' könne nur korrekt arbeiten, wenn man keine statischen IP vergibt (wie ich in dem Fall für den Host und die VM). Das kann ich mir allerdings nicht so recht vorstellen, weil eine IP/MAC Kombi ist doch nun mal eine IP/MAC Kombination und ergibt sich aus der MAC der Schnittstelle und der egal wie vergebenen IP Adresse. Wenn ich beides eindeutig wähle, sollte es doch egal sein, ob die IP vom DHCP kommt oder statisch vegeben wird (solange sie ausserhalb des DHCP Bereichs ist).
Um ein Beispiel zu geben:
Host ist statisch z.B. MAC 'xx' und IP 192.168.178.213 und ebenfalls statisch VM ist MAC 'yy' und IP .212.
Wähle ich in der Netzkonfiguration von VB 'promiscuous mode = deny' bzw. 'promiscuous mode = erlauben für alle VM und host', dann erkennt die FB nicht mehr den Unterschied zwischen dem Host und der VM, ordnet die IP mal dem einen und mal dem anderen Gerät zu (Host MAC zwar 'xx' aber IP .212), sperrt mal den INet Zugang der VM und mal nicht, habe noch keine Gesetzmäßigkeit gefunden, woran es liegt.
Setze ich in der Netzkonfiguration von VB 'promiscuous mode = erlauben für alle VM', dann erkennt die FB relativ zuverlässig den Unterschied zwischen dem Host und der VM, ordnet die IP korrekt zu, erkennt aber selten, dass die VM läuft (wird nicht als verbundenes Netzgerät angezeigt). INet Zugang der VM ist dann oft nicht möglich, obwohl die FB keinen Sperreintrag zeigt.
Die Netzwerkkarte des Hosts ist übrigens eine TP Link WDN 4800.
Ich weiss gar nicht, wie ich erwarten kann, dass das hier jemand liest, geschweige denn versucht zu verstehen. Aber sollte es jemand bis hierher geschafft haben (Gratulation!), folgt wahrscheinlich der Rat, zum ersten WLAN durch Kabel zu ersetzen (geht leider in dem Fall nicht) und zum zweiten es eben zu vergessen (geht!). Aber vielleicht kommt ja doch noch ein hilfreicher Hinweis.
Problem gelöst.
Scheint, die FB kann tatsächlich nicht so recht mit statischen IP, zumindest nicht in dieser Kombination der Anforderungen, umgehen. Egal wie die physische Netzwerkschnittstelle des Hosts oder die virtuelle der VM konfiguriert sind, die FB wirft IP und deren Freigabe/Blockade durcheinander.
Abhilfe schafft, und zwar bei mir reproduzierbar, die Entfernung der Markierung:
'Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen.' in den Details der Heimnetzübersicht. Ist diese Markierung entfernt, so funktioniert die Portweiterleitung und der Internetzugriff des/der Clients auf Anhieb und so wie erwartet.
Danke für Eure Beiträge; werde mich jetzt, da es ja grundsätzlich funktioniert, damit beschäftigen, wie ich Minecraft und TS sicher vom übrigen Netzwerk abtrennen kann. Solange werden die Regeln in der FB auch nur aktiviert, wenn es tatsächlich gebraucht wird.
Scheint, die FB kann tatsächlich nicht so recht mit statischen IP, zumindest nicht in dieser Kombination der Anforderungen, umgehen. Egal wie die physische Netzwerkschnittstelle des Hosts oder die virtuelle der VM konfiguriert sind, die FB wirft IP und deren Freigabe/Blockade durcheinander.
Abhilfe schafft, und zwar bei mir reproduzierbar, die Entfernung der Markierung:
Danke für Eure Beiträge; werde mich jetzt, da es ja grundsätzlich funktioniert, damit beschäftigen, wie ich Minecraft und TS sicher vom übrigen Netzwerk abtrennen kann. Solange werden die Regeln in der FB auch nur aktiviert, wenn es tatsächlich gebraucht wird.
Das hat aber einen fatalen Nachteil.
Da es somit nicht mehr garantiert ist das dieser Server eine fest IP zugewiesen bekommt besteht die latente Gefahr das die entsprechende Port Forwarding Anweisung die ja eine statische, feste IP erwartet irgendwann mal ins Leere rennt.
Denn sollte sich die IP des lokalen Endgerätes durch die Dynamik von DHCP dann einmal ändern auf die die Port Forwarding Anweisung zeigt ist aus mit dem Zugriff !
Die Logik die oben impliziert wird ist ja geradezu fatal. Eine feste statische IP funktioniert mit mit Port Forwarding. Letztes ginge nur mit dynamischen IPs.
Das wäre ein konträrer Widerspruch, denn die eine Funktion bedingt die andere.
Nichtmal AVM könnte so einen Konfig Unsinn ernst meinen...?!
Da es somit nicht mehr garantiert ist das dieser Server eine fest IP zugewiesen bekommt besteht die latente Gefahr das die entsprechende Port Forwarding Anweisung die ja eine statische, feste IP erwartet irgendwann mal ins Leere rennt.
Denn sollte sich die IP des lokalen Endgerätes durch die Dynamik von DHCP dann einmal ändern auf die die Port Forwarding Anweisung zeigt ist aus mit dem Zugriff !
Die Logik die oben impliziert wird ist ja geradezu fatal. Eine feste statische IP funktioniert mit mit Port Forwarding. Letztes ginge nur mit dynamischen IPs.
Das wäre ein konträrer Widerspruch, denn die eine Funktion bedingt die andere.
Nichtmal AVM könnte so einen Konfig Unsinn ernst meinen...?!
Zitat von @aqui:
Das hat aber einen fatalen Nachteil.
Nichtmal AVM könnte so einen Konfig Unsinn ernst meinen...?!
Das hat aber einen fatalen Nachteil.
Nichtmal AVM könnte so einen Konfig Unsinn ernst meinen...?!
Auszug aus der Antwort des AVM Supports im Juli 2015:
Ihre Ticket-ID: CID42XXXXX
Hallo Herr ...
Den Hintergrund dieser Einschränkung kann ich Ihnen im Detail nicht nennen.
Dem ist aber so, dass wir die Funktion der Kindersicherung nur mit DHCP der
FRITZ!Box für alle Netzwerkgerät zusichern können. Auch wenn dies in der
Anleitung zur Kindersicherung nicht steht.
Mit "DHCP Lease statisch setzen" meine ich genau diese Option "Man kann ja
dem Client in der FB Oberfläche zuweisen, dass immer dieselbe IPV4 Adresse
vergeben werden soll."
Die Kindersicherung arbeitet per Identifikation von IP- und Mac-Adresse.
Diese Kombination ist dann ausschlaggebend. Ich schlage daher das
empfohlene nochmals:
- Sicher stellen, dass alle Netzwerkgeräte Ihre IP-Konfiguration per DHCP
[...]
- DHCP Lease bei bedarf statisch Setzen
... (AVM Support)
2-3 Jahre zuvor hatte ich schon einmal eine ähnliche Anfrage gestellt und eine ähnliche Antwort, aber mit derselben Aussage bekommen. Die FB kann angeblich nur die korrekte Funktion der Kindersicherung, also ihrer Firewall, garantieren, wenn sie alle IP Adressen per DHCP vergibt. Dabei ist ja der DHCP Adressraum ab Werk nur der Bereich zwischen 192.168.178.20-.200. Das würde aber für mich ausschließen, dass ich z.B. in einer Windows AD Domäne mit eigenem DHCP die FB Firewall zuverlässig nutzen kann.
Es kann aber doch nicht sein, dass eine Firewallregel, die auf der Kombi IP-Adresse/MAC basiert, nur dann funktioniert, wenn der FB DHCP Server die IP vergeben hat.
Ich muss als 'Consumer' mal sagen, die FB 7490 ist wirklich gut in der Summe ihrer Eigenschaften (können die Pros hier motzen wie sie wollen), aber sowas, vor allem über Jahre in allen FritzOS Versionen, ist ein Unding.
