Er schrieb, er hat den Browser aufgemacht und eine Verbindung auf den Ursprünglichen QuellPort als neuen Zielport initiert.
Das lese ich in #1 überhaupt nicht. Er schreibt gar nichts von einem Browser, sondern führt zweimal sogar explizit den Port 5060 an, der i.d.R. ja für SIP genutzt wird (da dann auch sowohl mit UDP als auch TCP, was die Unterscheidung bei weiteren Überlegungen erforderlich macht) und für den er beschreibt, daß eingehende Verbindungen mit diesem Zielport mal bei seinem "exposed host" ankommen und mal nicht (weil eine ausgehende Verbindung diesen Port i.V.m. der öffentlichen IPv4-Adresse verwendet) und daß er darin kein wirkliches System erkennen kann - was zur Suche/Frage nach ähnlichen Erfahrungen bei anderen führt.
Und wenn ich den Threadstarter richtig verstanden habe, ist dieser ursprüngliche Quellport, dank ursprünglichen ausgehenden Verbindung jetzt für ALLE eingehende Verbindungen "blockiert" obwohl die Fritzbox diesen eindeutig zur ursprünglichen Verbindung zuordnen können MÜSSTE.
Und sollte das tatsächlich so sein, halte ich selbst das auch für einen Fehler der AVM-Firmware:
Die Nutzung dieser "exposed host"-Option ist sicherlich auch exotisch genug, daß da nicht sofort jeder Fehler auffällt - und für meine Begriffe ist es tatsächlich einer, wenn die ausgehende Verbindung den genutzten lokalen Port komplett für andere Endpoints blockiert und nicht nur ankommende Pakete vom adressierten (entfernten) Endpoint an den Client (der die ausgehende Verbindung eröffnete) weiterreicht.
Nur kann ich aus #1 eben nicht klar erkennen, für welche Pakete das wirklich gilt, denn da werden beide Fälle beschrieben - sowohl der erfolgreiche (parallele) Verbindungsaufbau durch einen 1&1-Server, wenn der Port "in use" ist (aber mit einer anderen Gegenstelle) im letzten Absatz ... als auch im zweiten Absatz, daß eine solche Verbindung nicht funktionieren würde.
Bei Deinen eigenen Experimenten hast Du dann halt auch nur - wenn ich das alles richtig verstanden habe - mit TCP-Verbindungen hantiert (SSH und HTTP wären jedenfalls üblicherweise solche) und das Verhalten mit UDP-Paketen gar nicht weiter betrachtet. Auch vermisse ich die Aussagen, was mit den Paketen jeweils passiert, wenn Du nur schreibst, die Verbindung taucht nicht im Log des "exposed host" auf. Gibt es denn nun die von Dir vermuteten/erwarteten ICMP-Pakete bei "nicht zustellbar" oder geht das Paket tatsächlich sogar an den Client, der die Connection in der FRITZ!Box-Firewall freigeschaltet hatte? Macht es einen Unterschied, ob ein einkommendes Paket jetzt das SYN-Flag gesetzt hat oder nicht?
Das Verhalten ist aus meiner Sicht nur schlecht sinvoll begründbar. Anscheinend gibt es eine Tabelle der aktuellen Sessions.
Die gibt es ja zweifellos (wir betrachten jetzt mal der Einfachheit halber tatsächlich nur TCP über IPv4) - genau mit solchen "Tabellen" arbeitet die PPE ja. Solange nicht wirklich geklärt ist, was mit den "verschwundenen" Paketen passiert, kann man das auch nicht klar beurteilen, ob das Verhalten nun "sinnvoll" ist oder nicht. Solange die beiden EP einer Verbindung in einem Paket "passen" und es "passieren" darf, wird es halt irgendwie weiter verarbeitet.
Diese EP sind dann die von Dir und auch von mir in #14 schon erwähnten Angaben aus Quell-Adresse/-Port und Ziel-Adresse/-Port - und auch nur die stehen in einem Paket und auch nur die können daher zur "Einordnung" eines Pakets herangezogen werden und da interessiert es mich dann wiederum nicht, was das NAT lt. #15 sich da noch "merkt" für eine ausgehende Verbindung und ob das jetzt ein Quadrupel oder ein Quintupel sein sollte. Bei der PPE sind das dann eben nicht nur 4, 5 oder 6 "Merkmale", die in so einem Eintrag verwaltet werden, weil auch das Umschreiben der L2-Adressen ja gleich mitgemacht wird (ebenso das "Zählen" von Paketen) und nicht - wie bei "normalem NAT" im Linux-Kernel - erst nachträglich per ARP erledigt wird, wenn das umgeschriebene Paket wieder ins Routing gesteckt wird.
Bei einem UDP-Paket
kann die Firewall in der FRITZ!Box (und auch die PPE) bei identischen EPs nicht erkennen, ob ein einkommendes Paket zu der vorhandenen "Verbindung" gehört oder nicht - das sollte/müßte also immer bei dem Client landen, der den Tunnel erzeugt hat. Bei UDP ist "Verbindung" ohnehin eher ein Euphemismus, denn das ist ja bekanntlich verbindungslos und der einzige Teil, der hier als "Verbindung" bezeichnet werden kann und das eben häufig auch wird, ist der "ausgehende Tunnel" durch die Firewall, der passenden Paketen in der Gegenrichtung dann auch das Passieren ermöglicht.
Bei TCP braucht es ja schon mal den erfolgreichen Austausch von drei Paketen zwischen den beteiligten Partnern einer solchen Verbindung, damit diese überhaupt zustandekommen kann. Da die ersten beiden Pakete in einer solchen Verbindung (das erste vom Client zum Server und die erste Antwort vom Server zum Client) jetzt genau diese SYN-Flags gesetzt haben
müssen und damit erkennbar nicht zu einer bereits komplett eingerichteten, ausgehenden Verbindung gehören
können, ergibt sich hier tatsächlich eine Option, das auch zu erkennen und solche Pakete dann nicht an den Client weiterzuleiten (dem die ausgehende Verbindung "gehört").
Die Frage, ob das ein FRITZ!OS tatsächlich so handhabt, ist für mich auch nur teilweise geklärt ... nach #1 wird ein solches ankommendes Paket nicht im Mitschnitt auf dem LAN-Interface sichtbar und damit wohl innerhalb der FRITZ!OS-Firewall "vernichtet". Du selbst hast - wenn ich das nicht überlesen habe - gar nicht weiter geprüft, ob diese "verschwundenen" Pakete, die bei Dir keinen Log-Eintrag für einen Verbindungsversuch zur Folge hatten, nicht am Ende doch bei dem Client mit der SSH-Session gelandet sind, der sie dann seinerseits verworfen/ignoriert/abgelehnt hat.
Aber selbst wenn das FRITZ!OS dieses Paket tatsächlich "verschwinden" läßt ... welche Alternativen hätte es denn? Wenn es dieses Paket passieren läßt zum "exposed host", kann es in folgenden Paketen gar nicht mehr erkennen, ob die nun für den "exposed host" oder für den bereits bestehenden Tunnel gedacht sind - denn den nachfolgenden Paketen fehlt dann das SYN-Flag und alle anderen Schutzmaßnahmen in irgendwelchen Protokollen gegen "spoofing" (wie die Sequenznummern auf L4), sind Sache des jeweiligen Protokoll-Stacks auf dem Server und dem Client und haben mit der Firewall im FRITZ!OS (und mit der PPE am Ende) nichts zu tun. Diese führt Buch über die (IPv4-)Verbindungen und nicht über die Inhalte der übermittelten Pakete.
====================================================================
Die Frage, was "sinnvoll begründbar" ist im Kontext einer Portfreigabe, eines "exposed host" oder sogar einer richtigen demilitarisierten Zone (so ein "exposed host" wird ja oft auch als Pseudo-DMZ gewertet), kann man auch nicht wirklich - unparteiisch - beantworten, denn es gibt (afaik) dafür gar keine exakten Definitionen und so versteht jeder (Kunde und auch jeder Hersteller) darunter ggf. etwas Abweichendes und die Implementierung eines Herstellers wird halt immer auf seinen Vorstellungen und Möglichkeiten basieren und denen muß man sich dann eben (als Kunde) anpassen.
Oder wo wäre das RFC, welches einem Edge-Router "vorschreibt", daß er zwangsweise eine Port-Adress-Translation für die hinter ihm versammelten Clients ausführen müsse und diese dabei auf eine "definierte Range" von ausgehenden Portnummern zu mappen hätte? Was passiert denn dann, wenn ein Kunde nun auf einmal auf die Idee kommt, einen Port aus
dieser Range für eingehende Verbindungen zu einem Client freizugeben? Das Fehlen eines Standards dafür macht die Bewertung:
ist aus meiner Sicht auch nicht richtig.
dann eben auch subjektiv (was Du mit dem "aus meiner Sicht" ja auch verdeutlichst) - und selbst die Zeiten, wo der Linux-Kernel für das Masquerading die Port-Range 61000-65095 verwendete, sind schon seit Kernel-Version 2.4 vorbei (iirc). Schon beim Auseinandersortieren der Begriffe "SNAT", "DNAT", "Masquerading", "Portforwarding", etc. ergibt sich (erst recht mit Blick auf Vergangenes) häufig eine vollkommen andere Sichtweise bei mehreren Beteiligten und so tut man gut daran, sich zunächst mal darauf zu verständigen, was man darunter genau verstehen will.
Das sind jedenfalls alles Grauzonen in der Behandlung von solchen Features und häufig genug basieren solche Funktionen auf irgendeiner Implementierung eines Herstellers, der das mal "vorgemacht" hat (ob man das dann gleich "Referenz" nennt, liegt im Auge des Betrachters) und dabei aber darauf verzichtete, das in eine vernünftig auf- und ausgebaute Spezifikation zu packen und diese dann - und sei es nur als "Quasi-Standard" und nicht gleich als RFC - zu veröffentlichen.
Das "magic packet" zum Wake-On-LAN ist genauso eine Wundertüte (um mal ein weiteres, "unterspezifiziertes" Feature zu benennen), wo sich auch jeder sein eigenes Süppchen kocht - zumindest war es das in der Vergangenheit.
====================================================================
Solange sich das Problem dadurch bewältigen läßt, daß ein für bereitzustellende Dienste an der öffentlichen IPv4-Adresse benötigter Port sich über eine "Portfreigabe" auch "reservieren" läßt für solche eingehenden Verbindungen, ist aus meiner Sicht auch alles in Ordnung.
Ein "exposed host" erhält eben nur die Pakete, mit denen die Firewall des Edge-Routers nichts anzufangen weiß - und für einen weiteren Verbindungsaufbau zu einem Port, der bereits für eine ausgehende Verbindung genutzt wird (und zwar auch nur von demselben "Server" im Netz, weil es bei unterschiedlichen IP-Adressen des Peers ja funktioniert nach #1), stellt sich diese Frage, ob man damit etwas anfangen kann, gar nicht erst ... das MUSS man unterdrücken, weil nachfolgende (TCP-)Pakete sonst nicht mehr (reliable) zugeordnet werden können.
Das ganze "exposed host"-Feature ist also nicht klar "spezifiziert" und wenn man in den AVM-Hilfetext schaut (online), kann man auch diesen durchaus in beide Richtungen interpretieren:
Dieses Gerät komplett für den Internetzugriff über IPv4 freigeben (Exposed Host)
Wenn diese Option aktiviert ist, dann hat das folgende Auswirkungen:
- Alle Ports in der Firewall der FRITZ!Box werden für das ausgewählte Netzwerkgerät freigegeben. Ausgenommen sind Ports, die bereits für ein anderes Netzwerkgerät freigegeben wurden.
- Der Schutz durch die Firewall der FRITZ!Box ist für dieses Netzwerkgerät nicht mehr gegeben.
- Im gesamten Heimnetz können keine weiteren Portfreigaben eingerichtet werden.
- Diese Option kann nur für ein einziges Netzwerkgerät im Heimnetz aktiviert werden.
Sie sollten diese Option nur zu Testzwecken aktivieren. Sicherer ist es, für jedes Gerät nur die Ports freizugeben, deren Freigabe tatsächlich erforderlich ist.
Jetzt kann man sicherlich trefflich darüber streiten, ob dieses "bereits ... freigegeben wurden" sich nur auf die expliziten Freigaben durch den Benutzer beziehen oder ob da die "automatischen Freigaben" für eintreffende Antwort-Pakete im Rahmen einer ausgehenden Verbindung eingeschlossen sein sollten. Sicherlich könnte man das klarer formulieren ... nur ändert eine genauere Beschreibung ja nichts am Verhalten der Firmware.
Aber schon die Feststellung (in #1), daß Pakete von einem anderen Host als demjenigen, der in der ausgehenden Verbindung angesprochen wurde, auch tatsächlich am "exposed host" ankommen (letzter Absatz in #1), zeigt für mich, daß sich AVM hier alle erdenkliche Mühe gegeben hat, um das so "reliable" wie möglich zu machen. Zwar könnte man mit "zwangsweiser Übersetzung" des Quellports solche Konflikte tatsächlich auf eine Port-Range beschränken (denn auch nach PAT erreichen dort eingehende Pakete den "exposed host" natürlich nicht mehr, wenn sie auf diesen Tunnel passen), aber damit handelt man sich dann wieder andere Probleme ein (jetzt kann ein Client nämlich nicht gar nicht mehr von einem vordefinierten Port senden, solange man das nicht auch wieder über Ausnahmen konfigurierbar macht).
Mit der Lösung, daß eine eingerichtete Portfreigabe einen solchen Port dann "reserviert" und damit dafür sorgt, daß er für ausgehende Verbindungen nicht länger verwendet wird, hat man da in meinen Augen schon das Maximum am Flexibilität erreicht, was mit dem - doch sehr auf einfache Bedienbarkeit getrimmten - Interface des FRITZ!OS beim "normalen Benutzer" benötigt würde.
Letztlich läuft das hier im Thread ja gar nicht auf ein "geht nicht" hinaus ... es fehl(t)en nur die Ansätze zum Verständnis des Ganzen und daraus resultierte dann wohl die Suche nach irgendwelchen Einstellungen dafür (#1, letzter Satz), die es m.W. so gar nicht gibt, weil sich das Verhalten an dieser Stelle aus dem dynamischen Verlauf der "Verbindungen" in der FRITZ!OS-Firewall ergibt.
