Wer kann mir Exposed-Host erklären?

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
1,728
Punkte für Reaktionen
155
Punkte
63
Ganz so einfach ist es nicht. Ich möchte, dass mir jemand erklärt, was die Firma AVM darunter versteht. Vorweg: Ich habe eine öffentliche IPv4 und kein DS-Lite.

fritz.box → Internet → Freigaben → (Reiter) Ports
Bisher dachte ich, der Exposed-Host erhält alles – aus IPv4 –, was die Firewall keinem Gerät im Heimnetz zuordnen kann. Allerdings mache ich seit Monaten eine andere Beobachtung: Startet ein Client im Heimnetz eine Verbindung nach draußen, dann ist der Quell-Port solange gesperrt, bis die NAT-Session abläuft. Mache ich einen Paket-Mitschnitt auf „1. Internetverbindung“, dann sehe ich das ankommende Paket. Mache ich einen Paket-Mitschnitt auf „LAN“, dann wird das Paket niemanden zugeordnet; es erscheint nicht.

Damit Server-Anwendungen auf meinem Exposed-Host so nicht „zufällig“ blockiert werden, muss ich folglich zusätzlich zu Exposed-Host für jede Server-Anwendung auch Port-Freigaben anlegen – mindestens in IPv4. Egal ob TCP oder UDP. Wusstet Ihr das? Das hat zur Folge, dass das NAT jede Client-Verbindung über einen solchen Port extern auf einen anderen Port umlegt. D.h. wenn ich auf einem Computer im Heimnetz eine Verbindung mit Quell-Port 5060 starte, dann verschickt die FRITZ!Box diese Verbindung ins Internet auf einem ganz anderen, zufälligen Quell-Port.

Andere Geräte wie der DrayTek Vigor machen das so, wie ich es erwartet hätte: Der Quell-Port wird nicht blockiert, sondern Anfragen an diesen Port, leitet der Vigor an meinen Exposed-Host weiter. Folglich muss ich beim Vigor nur Exposed-Host und keine Port-Freigaben einrichten.

Allerdings scheint AVM zu dieser Regel doch Ausnahmen zu kennen. Und die verstehe ich überhaupt nicht. Beispiel: Auf einem Client starte ich eine IPv4-Verbindung zum Telefonie-Server bei 1&1. Als Quell- und Ziel-Port kommen 5060 zum Einsatz. Mein 5060 auf dem Exposed-Host ist blockiert (weiß ich noch nicht mit Gewissheit). Anfragen von einem anderen Telefonie-Server bei 1&1 (= ursprüngliche Ziel-IP ±1) schlagen beim Exposed-Host auf. Ergo: Eine solche Anfrage wird nicht blockiert, obwohl der Quell-Port genutzt ist. Weiß jemand, wo solche Ausnahmen definiert sind, damit ich die einsehen kann?
 
Zuletzt bearbeitet:

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
12,800
Punkte für Reaktionen
372
Punkte
83
Moinsen


Versuchs mal in den Support Daten ab...
Code:
##### BEGIN SECTION PCPD
##### BEGIN SECTION PCPD fwacl
##### END SECTION PCPD fwacl
##### BEGIN SECTION PCPD client
Max Request per Address: 256
##### END SECTION PCPD client
##### END SECTION PCPD
##### BEGIN SECTION PCP
...
##### END SECTION PCP
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
1,728
Punkte für Reaktionen
155
Punkte
63
Was genau sollte dort stehen … vielleicht lese ich das falsch oder mein FRITZ!OS ist zu neu. Wenn ich auf einem Computer eine Client-Verbindung aufmache – also einen Port nutze –, taucht der dort nicht auf. Auch meinte ich mit „Regeln“ eigentlich jene Regel, warum manchmal der Port doch nicht gesperrt ist. Übrigens: Wenn die FRITZ!Box um-mappt, dann nimmt sie einen Port ≧ 61000.
 

mac-christian

Neuer User
Mitglied seit
16 Mrz 2020
Beiträge
88
Punkte für Reaktionen
4
Punkte
8
Mein "Exposed Host" ist aus dem Internet problemlos erreichbar, und zwar mit den angehängten Einstellungen. Erreichbar ist er über die Adresse von myfritz.com, und ich habe darauf einen Listserver mit einigen Mailinglisten laufen. Ohne jegliche spezielle Port-Freigaben für dieses Gerät. Der "Exposed Host" muss seine IP-Adresse per DHCP beziehen - bis ich das gemerkt hatte, hats eine Weile gedauert...

Bildschirmfoto 2020-07-31 um 18.07.04.jpg
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
1,728
Punkte für Reaktionen
155
Punkte
63
Das geht bei mir nicht nur über DHCP sondern auch über eine statische IPv4-Adresse.

Auch ist mein Exposed-Host „erreichbar“. Mein Problem: Ich kann mir Ports auf meinem Exposed-Host durch einen anderen Computer im Heimnetz verschließen. Anders formuliert: Sobald Du im Heimnetz eine Client-Verbindung mit dem selben Quell-Port (wie eines Deines Server-Ports) aufmachst, dann kommt für 5 Minuten (bei UDP) bzw. 15 Minuten (bei TCP) keiner mehr auf diesen Port auf Deinem Exposed-Host. Außer, außer, ich richte in der FRITZ!Box neben Exposed-Host auch noch Port-Freigaben ein. Dann mappt die FRITZ!Box den Quell-Port des IP-Clients intern um. Eigentlich alles völlig unnötig. Ich verstehe nicht, was AVM da geritten hat.

christian, mit Deiner Konfiguration läufst Du in die selbe Falle wie ich. Aktuell musst Du für jeden Server-Port auf Deinem Exposed-Host zusätzlich noch eine Port-Freigabe einrichten.
 

mac-christian

Neuer User
Mitglied seit
16 Mrz 2020
Beiträge
88
Punkte für Reaktionen
4
Punkte
8
Mit einer festen IP-Adresse war der Exposed Host immer wieder mal "verschwunden", sowohl intern wie von aussen. Ich hatte es natürlich zuerst mit einer fixen IP versucht (Fritz!Box 7490, 7.12)...

Und das mit den Port-Freigaben ist mir noch nie aufgefallen und ich habe es auch nirgendwo in einer Anleitung gesehen. Kannst du da einen Beleg nennen?
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
1,728
Punkte für Reaktionen
155
Punkte
63
Mit einer festen IP-Adresse war der Exposed Host immer wieder mal "verschwunden"
Spannend; bisher noch nicht gesehen und ich greife von Innen über Außen auf den Exposed-Host zu und habe alle zwei Minuten eine neue Registrierung (VoIP/SIP). Hattest Du das bei AVM gemeldet? Ich musste nur darauf achten, dass die feste IP-Adresse nicht im DHCP-Bereich lag.
… und ich habe es auch nirgendwo in einer Anleitung gesehen.
Das ist ja genau der Punkt. Ich habe das auch noch nirgends gelesen. Mein Test-Aufbau:
  1. starte in der FRITZ!Box einen Paket-Mitschnitt auf dem Interface LAN
  2. gehe zu irgendeinem Computer in Deinem Heimnetz, also nicht zum Exposed Host
  3. öffne eine IPv4-Verbindung, zum Beispiel über einen Web-Browser zu https://ipv4.icanhazip.com oder
    über eine UNIX-Terminal: openssl s_client -connect ipv4.icanhazip.com:443
  4. öffnen den Paket-Mitschnitt mit Wireshark und schaue nach dem Src-Port (irgendwas hohes, Dst-Port ist 443)
  5. schalte auf Deinem Mobiltelefon WLAN aus (damit Du wirklich von Außen mit anderer IP kommst)
  6. öffne auf Deinem Mobiltelefon einen Web-Browser
  7. gib Deine öffentliche IPv4-Adresse ein, Du siehst ein TCP-SYN im Paket-Mitschnitt
  8. mache das selbe, aber jetzt hängst Du mittels Doppelpunkt jenen Src-Port aus Schritt 4 an
Dieses TCP-SYN wird nicht auf Deinem Exposed-Host aufschlagen. Jedenfalls passiert das hier bei nicht. Warte 15 Minuten (wegen den NAT-Session-Timeout für TCP). Versuche es erneut. Jetzt wird der TCP-SYN an Deinen Exposed-Host weitergeleitet.

Das sieht jetzt nicht so dramatisch aus, weil das irgendein hoher Port ist. Aber das ist nur ein einfaches Beispiel. VoIP/SIP-Clients nutzen (viel zu oft) sowohl als Dst-Port als auc Src-Port 5060/udp. Zusammen mit diesem seltsamen Verhalten seitens AVM wird dann auch mein Exposed-Host auf 5060/udp blockiert. Und genau dort liegt mein VoIP/SIP-Server.
 
Zuletzt bearbeitet:

chrsto

Mitglied
Mitglied seit
8 Sep 2010
Beiträge
597
Punkte für Reaktionen
37
Punkte
28
Etwas verklausuliert ist dieses Verhalten in der Hilfe von AVM beschrieben:


Innerhalb von IPv4-Netzen kann pro Port nur eine Freigabe eingerichtet werden.

Wenn in einem IPv4-Netz, in dem noch keine Portfreigabe eingerichtet ist, ein Gerät als Exposed Host eingerichtet wird, dann ist jeder Port in dem IPv4-Netz freigegeben. Es kann auf keinem weiteren Gerät eine Portfreigabe eingerichtet werden.

Wenn in einem IPv4-Netz auf einem Gerät zum Beispiel Port 80 freigegeben ist und ein weiteres Gerät als Exposed Host eingerichtet wird, dann sind auf dem Exposed Host alle Ports außer Port 80 geöffnet.
Oder anders formuliert: Wenn ein Exposed Host existiert und ein weiteres Gerät benötigt einen Source Port, nimmt er diesem dem Exposed Host weg, sofern dafür keine feste Portweiterleitung existiert.
 

mac-christian

Neuer User
Mitglied seit
16 Mrz 2020
Beiträge
88
Punkte für Reaktionen
4
Punkte
8
Es ist m.E. klar, dass es nur eine einzige Weiterleitung für einen Port pro öffentlicher IP Adresse geben kann. Meine öffentliche IP sei z.B. 123.234.201.12, der Exposed Host in meinem Netzwerk ist 192.168.250.57. Der DynDNS Dienst zeigt auf meine öffentliche IP, und der Router leitet solche Anfragen intern an 192.168.250.57 weiter. So weit okay.

Wenn ich jetzt einen weiteren Computer habe den ich öffentlich machen will, weiss der Router natürlich nicht, wohin mit den ankommenden Datenpaketen - an den Exposed Host mit 192.168.250.57 oder an den andern Computer. Da müsste eine Lösung her, bei der (a) zwei öffentliche IP-Adressen bestehen die beide an je einen andern Computer als "Exposed Host" weitergereicht werden, oder (b) der Router kann aufgrund des Computernamensd/ der Subdomain / irgendeinem andern Merkmal unterscheiden, zu welchem Computer die Daten gehören.

Die zweite Lösung geht problemlos, wenn z.B. ein Computer nur Anfragen auf die Mail-Ports (25, 110, 465, 587, usw.) beantworten soll und der andere nur solche für Webseiten (80, 443, usw.) dann brauchts einfach die entsprechenden Portweiterleitungen und keinen Exposed Host. Oder man legt die eingehenden Port-Nummern in den "hohen" Bereich, z.B. http auf 8080 und smtp auf 2525 für den zusätzlichen Computer. Dafür muss der DNS-Eintrag entsprechend konfiguriert sein, damit z.B. www1.domain.com auf 123.234.201.12:80 zeigt und www1.domain.com auf 123.234.201.12:8080. Eine Liste der standardisierten Portnummern gibts z.B. bei Wikipedia.
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,853
Punkte für Reaktionen
14
Punkte
38
Wenn ich jetzt einen weiteren Computer habe den ich öffentlich machen will, weiss der Router natürlich nicht, wohin mit den ankommenden Datenpaketen - ...
Der weitere (2.) Computer muss ja gar nicht öffentlich gemacht werden. Es reicht ja schon wenn die FB NAT (mit IP-Adresse und source-Port) für diesen 2. Computer (als Client an der FB) machen muss. Wenn dieser source-Port identisch mit dem destination-Port des Exposed-Host ist und dieser destination-Port für den Exposed-Host nicht vorab "reserviert" ist (z. B. durch eine Portweiterleitung), ist der Exposed-Host aus dem Internet auf diesem Port nicht erreichbar.
 

Olaf Ligor

Mitglied
Mitglied seit
21 Mai 2019
Beiträge
391
Punkte für Reaktionen
49
Punkte
28
Davon abgesehen, dass "exposed Host" für mich nicht so richtig zu einem Szenario passt, wo sich noch andere "NAT-Kunden" munter Ports öffnen, ist das Verhalten von AVMs Firmware nicht ganz unschlüssig. Wenn wir exposed Host als Portfreigabe mit dem Bereich Port 1 bis 65535 definieren, ist ja kein Platz mehr für die Umleitung auf einen anderen, mehr oder weniger zufälligen Port.

Diesen Umstand löst Draytek das wohl auch auf die etwas brutalere Art: "... DrayTek Vigor machen das so, wie ich es erwartet hätte: Der Quell-Port wird nicht blockiert, sondern Anfragen an diesen Port, leitet der Vigor an meinen Exposed-Host weiter." Das würde zwar dein Problem mit dem minutenlangen Blockieren deiner Ports verhindern, dürfte aber die ausgehende Verbindung des Nicht-exposed Hosts komplett nutzlos machen. Eher eine lose-lose-Situation.

Prinzipiell wäre es wohl wünschenswert, wenn man das Verhalten zwischen AVM und Draytek umstellen könnte. Allerdings habe ich nicht wirklich ein Scenario dafür, fast immer nur die preiswertere und/oder flexiblere Kombination aus LTE-Router und einer Fritzbox als exposed Host, im letzten Fall wegen eines Speedbox-"IMEI fencing"-Zwangsrouters.
BTW: Interessant, wie lange so AVM TCP/UDP-Ports offen hält.
 

mac-christian

Neuer User
Mitglied seit
16 Mrz 2020
Beiträge
88
Punkte für Reaktionen
4
Punkte
8
@sf3978 Ich schrieb nicht, dass ich zwei Exposed Hosts haben möchte. Ich schrieb, dass es zwei Computer gibt (bzw. geben kann) die beide von aussen erreichbar sein sollen.
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,853
Punkte für Reaktionen
14
Punkte
38
... schrieb nicht, dass ich zwei Exposed Hosts haben möchte. Ich schrieb, dass es zwei Computer gibt (bzw. geben kann) die beide von aussen erreichbar sein sollen.
Ja, das habe ich ja auch so verstanden und auch nicht von einem 2. Exposed-Host geschrieben.
Es ist aber so, dass der 2. Computer gar nicht von außen erreichbar sein muss, denn es reicht ja schon wenn der 2. Computer eine Verbindung nach außen öffnet und die FritzBox NAT macht mit dem source-Port des 2. Computers, den der Exposed-Host als dst-Port benutzen will/soll.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,423
Punkte für Reaktionen
1,130
Punkte
113
Es geht doch gar nicht um Weiterleitungen ... es geht darum, daß das FRITZ!OS bei einer ausgehenden Verbindung den Source-Port nicht nur für die früher oder später eintreffenden Antworten vom adressierten Ziel öffnet, sondern - zumindest der Beschreibung nach, ich habe das nicht selbst geprüft - auch eingehende Pakete für die öffentliche IPv4-Adresse und den verwendeten "Source-Port" (der in den ankommenden Paketen dann natürlich "Destination-Port" ist) blockiert, wenn sie von anderen Adressen als derjenigen stammen, für die diese ausgehende Verbindung "gestartet" wurde.

Wenn solche Pakete nicht einfach bei dem LAN-Client landen, der die ausgehende Verbindung initiiert hat, ist das vollkommen richtig - so ein "Tunnel" durch die Firewall ist i.d.R. durch seine beiden "Endpoints" beschrieben und so ein Endpoint besteht aus der IP-Adresse in Kombination mit einer Portnummer.

Die Frage wäre dann, was man mit Paketen macht, die eben NICHT zu diesem Tunnel gehören und trotzdem (lokal) dieselbe Port-Nummer verwenden - speziell dann, wenn lokal ein "exposed host" vorhanden ist. Ohne diesen wird das gar nicht erst zum Problem, weil bei ausgehenden Verbindungen für den nächsten Client ohnehin eine andere Portnummer im NAT verwendet würde - somit existiert dann immer nur ein (Firewall-)Tunnel für einen lokalen Endpoint.

Es spricht zunächst überhaupt nichts dagegen, dann solche Pakete auch wieder an den "exposed host" weiterzuleiten (so macht es ja der Vigor dann wohl), denn ein Problem für den Client mit der ausgehenden Verbindung ergibt sich dadurch nicht zwangsläufig - der will/soll ja auch nur mit diesem einen (entfernten) Endpoint kommunizieren, zu dem er seine Verbindung aufgebaut hat und Pakete mit abweichenden Endpoints (lokal oder remote, wobei das eben immer die Kombination aus Port und IP-Adresse ist) gehören eben per Definition nicht zu dieser Verbindung.

Bei FRITZ!Boxen stellt sich ggf. nur die Frage, wie "smart" die PPE für die Hardware-Beschleunigung ist bzw. wie sie benutzt wird. Ich weiß nicht, ob es einen "default"-Eintrag gibt, wo ein Paket (per Hardware) an den "exposed host" geschickt wird, wenn es zu keinem anderen Forwarding-Eintrag paßt(e) oder ob das alles erst mal an die CPU geht und von dort dann weiter verteilt wird.

Die Nutzung der CPU an dieser Stelle wäre eigentlich wieder ein Risiko, weil viele eingehende, "unsolicited" Pakete dann natürlich den Port zwischen Switch und CPU auch blockieren und wenn die CPU letztlich auch nichts anderes damit macht, als sie zu verwerfen, kann das dann auch die PPE gleich selbst machen.

Insofern greift man hier (vermutlich) eigentlich schon mit einem Paketmitschnitt (wenn man ihn auf der FRITZ!Box macht) viel zu tief in das zu beobachtende System ein - denn dafür müssen die Pakete in jedem Falle irgendwie zur CPU gelangen ... entweder als Kopie oder sogar als Ingress, den es zu verteilen gilt nach der Aufzeichnung.

Schaltet man die PPE ab, senkt das den maximal möglichen Durchsatz deutlich - ob sich diese aber jetzt wirklich so programmieren läßt, daß sie alle nicht zuzuordnenden Pakete direkt an den "exposed host" weiterleitet, auch wenn es für die als Ziel angegebene Portnummer eine ausgehende Verbindung gibt, weiß ich nicht und meines Wissens gibt es dazu auch keine entsprechenden Unterlagen irgendwo (frei zugänglich) im Internet.

Ich könnte mir aber durchaus vorstellen, daß es durch die unterschiedlichen Wege, die solche Pakete in der Box dann nehmen, einen Unterschied machen könnte, wenn man die Paketbeschleunigung deaktiviert - es gäbe ja "nur Software" oder auch "aus" als Alternativen. Auch könnten sich bei unterschiedlichen FRITZ!OS-Versionen durchaus verschiedene Verhaltensweisen finden lassen (insofern fehlen diese Angaben in der Beschreibung) und auch die Fähigkeiten der PPE in den jeweils verwendeten SoC (praktisch jede moderne Plattform hat heute entsprechende Optimierungen im Angebot) spielen sicherlich am Ende noch eine Rolle (damit auch das verwendete FRITZ!Box-Modell). Da kann es bei AVM auch schon mal geschehen, daß man nur den kleinsten gemeinsamen Nenner aller verwendeten SoC auch selbst nutzt - ein schönes Beispiel für solchermaßen vergebene Chancen ist die in einigen SoC ja schon länger vorhandene, aber vor 07.20 brachliegende Hardware-Unterstützung bei kryptographischen Aufgabenstellungen.

Mit der PCP-Einführung hat AVM auch da noch ziemlich "herumgerührt" (auch für eine Freigabe braucht es halt einen Forwarding-Eintrag in der PPE) und je schneller die DSL-Anschlüsse wurden, um so mehr mußte sich auch AVM auf die Hardware-Fähigkeiten (also die PPE) konzentrieren (die man bei anderen Geräten/Herstellern mit demselben SoC i.d.R. automatisch in Benutzung hatte, wenn man die Patches des SoC-Herstellers für den Kernel verwendet), wenn man den WAN-Durchsatz einigermaßen erreichen wollte.

Welche "Merkmale" so eine ausgehende Verbindung in der PPE dann hat, kann man sich (mit Shell-Zugang) in der FRITZ!Box unter "/proc/net/avm_pa/..." ansehen. Wieviel davon jetzt direkt in der PPE als "Ersetzung" programmiert werden kann, ist eben das "Betriebsgeheimnis" des SoC-Herstellers, wo man wohl nur durch NDA bzw. durch Analyse der Kernel-Patches (die findet man ja ab und an mal "im Original", z.B. bei OpenWRT und seinen Ablegern) genauer ermitteln kann. Sind alle notwendigen Ersetzungen erfolgt, kann ein Paket jedenfalls auch direkt an sein Ziel weitergereicht werden - die MAC-Adresse des Ziels gehört auch zu den Daten, die geändert/getauscht werden können.

Die Gretchen-Frage hier wäre es also nicht, wie man es mit der Religion hält, sondern welche Einträge in den PPE-Tabellen vorhanden sind bzw. erzeugt (also genutzt) werden, wenn es einen "exposed host" gibt und welchen Weg so ein Paket durch die PPE nimmt, bevor es (wenn überhaupt) zum passenden Client oder zur CPU (wo dann das eigentliche FRITZ!OS erst läuft) weitergeleitet wird.

Schon die Frage, welche "Reaktion" der Firewall da eingestellt ist für "unerwünschte Pakete" (reject oder drop - ersteres mit (ICMP-)Nachricht, letzteres ohne), könnte einen Unterschied machen - wenn das wieder an unterschiedlichen Stellen behandelt wird. Eigentlich sollte bei "exposed host" ja diese Entscheidung erst von ebendiesem Client getroffen werden - aber da auch das erst später "angestrickt" wurde als Auswahlmöglichkeit durch den Benutzer, kann ich mir auch gut vorstellen, daß das nicht nach der Entscheidung für den "exposed host" erfolgt, sondern schon davor.

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 klingt der letzte Absatz in #1 ja eigentlich schon wieder so, als würde AVM da durchaus die Pakete von anderen Endpoints an den "exposed host" weiterreichen, auch wenn eine ausgehende Verbindung den lokalen Port zu einem anderen Endpoint benutzt - und das wäre dann ja auch vollkommen in Ordnung. Ich habe also die Beschreibung in #1 noch nicht so richtig verstanden ... einerseits blockiert eine ausgehende Verbindung eingehende Pakete für diesen Port (2. Absatz), andererseits erreichen eingehende Pakete für diesen Port den "exposed host" (letzter Absatz).

Das Einzige, was ich mir hier noch vorstellen kann, ist eine unterschiedliche Behandlung von UDP und TCP, die dann in #1 auch nicht erwähnt ist. In einer bereits aufgebauten TCP-Verbindung hat ein weiteres Paket mit gesetztem SYN-Flag nichts mehr zu suchen - solche Pakete kann man also auch dann noch verwerfen (droppen), wenn für die beiden Endpoints ansonsten ein passender Eintrag in der PPE vorhanden wäre. Bei solchen Paketen kommt dann noch hinzu, daß die i.d.R. auch nicht direkt weitergeleitet werden können (außer eingehend zu einem "exposed host" eben), weil die CPU ja von einer solchermaßen aufgebauten (ausgehenden) TCP-Verbindung Kenntnis erhalten muß, damit sie die PPE passend konfigurieren kann. Daher gehen SYN-Pakete eigentlich immer über die CPU (soweit ich das kenne und das sollte für FIN-Pakete ebenfalls gelten, damit dann die Einträge für diese Verbindungen auch wieder abgeräumt werden) und da kann es dann eben auch schon mal vorkommen, daß diese "silently dropped" werden, wenn es eine passende Verbindung bereits gibt.

Wer also von einem Client hinter seiner FRITZ!Box eine ausgehende TCP-Verbindung (zu seinem eigenen Server) aufbaut, die meinetwegen 5060 als (Source-)Port nutzt und - während diese Verbindung noch existiert - dann versucht, vom Server eine (weitere) Verbindung zu demselben (Destination-)Port aufzubauen, der wird dabei (richtigerweise) scheitern und das Paket wird (mit einiger Sicherheit) einfach "verschwinden". Beim UDP gibt es ja keine entsprechenden Flags, die den Aufbau einer neuen Verbindung signalisieren ... da sollte/müßte dann ein Paket vom Server am Ende auch beim Client landen (wenn auch der Source-Port vom Server stimmt). Insofern wäre ggf. auch noch zu klären, ob wirklich der Port an der FRITZ!Box "blockiert" ist für alle IPv4-Verbindungen (L3) oder ob nicht das L4-Protokoll dann doch noch einen Unterschied macht.
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
1,728
Punkte für Reaktionen
155
Punkte
63
Nochmal für alle kurz: Eine Verbindung ist immer ein Quadruple aus Quell-IP, Quell-Port, Ziel-IP und Ziel-Port. Das NAT schaut sich das jedes Mal an und hat dafür Regeln. Das NAT macht daraus ein Quintuple – also mit Egress-Port – … aber das ist mir total egal, denn …
Verhalten von AVMs Firmware nicht ganz unschlüssig
Ein Exposed-Host erhält all jene Pakete, womit das NAT nicht weiß wohin damit.

Stattdessen hat AVM da was wildes mit Regeln programmiert, was niemand – jedenfalls ich nicht – nachvollziehen kann.
Etwas verklausuliert ist dieses Verhalten in der Hilfe […] beschrieben […] Oder anders formuliert …
In meiner Vor-Recherche bin ich über jenen Hilfe-Eintrag auch gestolpert. Und beim ersten Lesen dachte ich auch, dass ist mein Fall! Aber AVM meint damit etwas anderes: Wenn ich für ein anderes Gerät auf der FRITZ!Box eine Port-Freigabe anlege, dann läuft dieser Port nicht mehr auf dem Exposed-Host auf. Also weißt AVM daraufhin, dass die Port-Freigabe bevorzugt wird und Datenpakete nicht gedoppelt werden; der Exposed-Host wird kein Mirroring- bzw. Monitor-Host.
für meine Begriffe ist es tatsächlich ein[ Fehler], 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.
Ja, das bewerte ich genauso.

Allerdings muss ich zugeben, dass ich auch schon beim DrayTek Vigor wilde Effekte mit dessen „DMZ“ hatte – erstaunlicherweise in IPv6. Aktuelle teste ich Lancom LCOS … auch irgendwie komisch. Folglich sind diese beiden Alternativen auch keine Allheilmittel, schon gar nicht, wenn man einen Honeypot betreiben will. Egal, hier nicht Thema.
durchaus die Pakete von anderen Endpoints an den "exposed host" weiterreichen, auch wenn eine ausgehende Verbindung den lokalen Port zu einem anderen Endpoint benutzt – und das wäre dann ja auch vollkommen in Ordnung. Ich habe also die Beschreibung in #1 noch nicht so richtig verstanden ...
Genau das ist mein Problem abseits von dem „Fehler“. Ich erkenne die Logik (noch) nicht. Vielleicht findet irgendwer mal die Zeit und testet das nach. UDP, TCP ist es nicht, Verhalten sich gleich. Habe ich getestet. Bei meinen Tests sah ich sogar einmal ein TCP-ACK auf dem Exposed-Host; Millisekunden vorher war es TCP-Keepalive und ein TCP-Keepalive-ACK auf dem IP-Client. Das TCP-ACK hätte es gar nicht geben dürfen. Egal. Aber warum kam das auf meinem Exposed-Host raus? Irgendwas geht da ab. Ich befürchte, weil das Grundkonzept schon fehlerhaft ist, dass der Rest meiner Beobachtungen einfach nur wildeste Folgefehler sind. Oder es ist eine Zustandsmaschine und bestimmte Übergänge sind in deren Logik schlicht falsch.

Hätte sein können, dass das jemand von Euch bereits angeschaut bzw. kapiert hat. Also werde ich ein Ticket bei AVM aufmachen müssen … und solange kann ich nur jedem empfehlen, dass er für jede Server-Anwendung auf seinem Exposed-Host zusätzlich Port-Freigaben einrichtet. Oder sich überlegt – hoffentlich zum vierten Mal –, ob man wirklich überhaupt Exposed-Host macht.
 
Zuletzt bearbeitet:

t_bone

Neuer User
Mitglied seit
29 Jan 2010
Beiträge
18
Punkte für Reaktionen
0
Punkte
1
Ich nutze die Funktion exposed Host auch schon eine Weile mit festen IP-Adressen und habe damit keine Probleme (FB7490).

Wer also von einem Client hinter seiner FRITZ!Box eine ausgehende TCP-Verbindung (zu seinem eigenen Server) aufbaut, die meinetwegen 5060 als (Source-)Port nutzt und - während diese Verbindung noch existiert - dann versucht, vom Server eine (weitere) Verbindung zu demselben (Destination-)Port aufzubauen, der wird dabei (richtigerweise) scheitern und das Paket wird (mit einiger Sicherheit) einfach "verschwinden". Beim UDP gibt es ja keine entsprechenden Flags, die den Aufbau einer neuen Verbindung signalisieren ... da sollte/müßte dann ein Paket vom Server am Ende auch beim Client landen (wenn auch der Source-Port vom Server stimmt). Insofern wäre ggf. auch noch zu klären, ob wirklich der Port an der FRITZ!Box "blockiert" ist für alle IPv4-Verbindungen (L3) oder ob nicht das L4-Protokoll dann doch noch einen Unterschied macht.
Wenn versucht wird vom Server eine Verbindung zum ursprünglichen Quellport aufzubauen ist dieses eine neue Verbindung, diese sollte von der Fritzbox eigentlich auch als solche interpretiert werden. (bei 5060 gibt es da sogar noch Besonderheiten) Dann ist das ein bug, wenn dabei der ursprüngliche Quellport blockiert ist. (außer Quell und Zielport sind identisch, dann wäre das Verhalten nachvollziehbar, aber selbst dann wird durch das ausgehende PAT der Quellport geändert)

Das Paket wird auch nicht einfach verschwinden, sondern abhängig von den Firewalleinstellungen hoffentlich mit einem rst oder port unreachable beantwortet. Beim "stealth" Modus wird es einfach verworfen, ja.

Insofern wäre ggf. auch noch zu klären, ob wirklich der Port an der FRITZ!Box "blockiert" ist für alle IPv4-Verbindungen (L3) oder ob nicht das L4-Protokoll dann doch noch einen Unterschied macht.
Den Satz finde ich komisch formuliert. Du meinst, wenn der Port eingehend auch für nicht zur Session gehörende eingehende IP-Pakete mit dem entsprechenden Zielport "blockiert werden würde? L3 kommt ja ohne Ports aus, ich bin mir sicher das weißt Du. :)


Gruß

Nachtrag:
Auf welchen ursprünglichen QuellPort machst Du eigentlich von außen eine Anfrage? Ich bin mir sicher, dass die Fritzbox nicht nur IP-NAT sondern ausgehend auch PAT macht. Wenn Du also eine Anfrage von außen auf den Port machst, den dein Client ursprünglich als Quellport verwendet hat, ist diese Verbindung selbst bei richtigem Port nicht in der Session-Tabelle der Box und sollte verworfen werden.

Beispiel, du baust eine Verbindung von einem internen Client zu einem Server auf
ClientIP:23430 zu 8.8.8.8:80, diese Verbindung wird von der Fritzbox geändert: FritzboxIP:50435 zu 8.8.8.8:80

Die Rückantwort sieht wie folgt aus:
8.8.8.8:80 zu FritzboxIP:50435 wird von der Fritzbox geändert zu: 8.8.8.8:80 zu ClientIP:23430

Diese QuellPort-Änderung macht die Fritzbox immer, bei allen ausgehenden Verbindungen.

Wenn Du jetzt von dem Server oder einem anderen Endgerät eine Verbindung zum ursprünglichen Quellport 23430 aufbauen willst, was soll das bringen? Dieser steht in der NAT-Tabelle als Übersetzung drin aber nicht in der Liste der Sessions. In der Session-Tabelle der Fritzbox sollte aber FritzboxIP:50435 zu 8.8.8.8:80 drin stehen. Bedeutet, eigentlich sollte bereits die erste Verarbeitungsinstanz in der Fritz das Paket wegwerfen bzw. negativ beantworten. Es gibt kein eingehendes NAT dafür und zu einer ausgehenden Session gehört es auch nicht.

hast Du jetzt einen exposed Host, würde die Fritz (so die Theorie), welche ja anscheinend nicht stimmt, das Paket an den exposed Host weiterleiten. (immer davon ausgehend das die flags bei TCP stimmen)
hast Du eine Portweiterleitung für diesen Port, würde die Fritz das an den Server mit PAT durchreichen.
 
Zuletzt bearbeitet:

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,853
Punkte für Reaktionen
14
Punkte
38
Beispiel, du baust eine Verbindung von einem internen Client zu einem Server auf
ClientIP:23430 zu 8.8.8.8:80, diese Verbindung wird von der Fritzbox geändert: FritzboxIP:50435 zu 8.8.8.8:80

Die Rückantwort sieht wie folgt aus:
8.8.8.8:80 zu FritzboxIP:50435 wird von der Fritzbox geändert zu: 8.8.8.8:80 zu ClientIP:23430

Diese QuellPort-Änderung macht die Fritzbox immer, bei allen ausgehenden Verbindungen.
Nein, die FritzBox macht diese QuellPort-Änderung nicht immer.
Beispiel, Du konfigurierst auf dem Client einen festen QuellPort (z. B. aus der range 2000 bis 60000) und erlaubst auf dem Server, das Zustandekommen der Verbindung, nur mit dem auf dem Client konfigurierten QuellPort. Die Verbindung wird zustande kommen. Ich habe es mit OpenVPN (UDP), WireGuard (UDP) und ssh (TCP) getestet.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,423
Punkte für Reaktionen
1,130
Punkte
113
@t_bone:
Ich gehe mal davon aus, daß Du am Ende gar nicht mich meinst?

Ich habe das Problem mit dem "exposed host" nicht und war nur - ebenso wie andere - auf der Suche nach einer Erklärung (möglichst auch noch einer plausiblen), wie es zu dem beschriebenen Verhalten kommen könnte.

Und da würde ich mich auch nicht (ohne eigenen Test) auf die folgende Aussage von Dir festlegen:
Das Paket wird auch nicht einfach verschwinden, sondern abhängig von den Firewalleinstellungen hoffentlich mit einem rst oder port unreachable beantwortet.
Bei einem "normalen" Packet-Flow wäre sicherlich eine ICMP-Antwort zu erwarten (außer eben im Stealth-Mode) - der von mir skizzierte Fall wäre aber schon etwas sehr Absonderliches. Ist der Port tatsächlich "zu", erzeugt mit ziemlicher Sicherheit schon die PPE das entsprechende Paket, weil ansonsten das alles immer erst über den Switch zur CPU müßte (und sich mit Flooding dann wieder DoS-Möglichkeiten eröffnen - gerade bei sehr asymmetrischen Bandbreiten). Ist der Port komplett "auf" (also "freigegeben"), wird (auch hier wieder ziemlich sicher) das Paket entsprechend umgeschrieben von der PPE und direkt weitergeleitet (weil dann die FRITZ!Box ja auch den "Verbindungsstatus" nicht länger überwachen muß).

Der von Dir zitierte Absatz bezog sich jetzt aber ausdrücklich auf die denkbare Situation, daß bei einem ausgehenden "Tunnel" durch die Firewall ein TCP-Paket mit gesetztem SYN-Flags eintrudelt, was (sofern das SYN-Flag nicht gesetzt wäre) auf diese ausgehende Verbindung paßt und daher auch zum Client nach innen weitergereicht würde. Man darf davon ausgehen, daß auch bei aktivierter Hardware-Beschleunigung die TCP-Pakete mit gesetztem SYN- bzw. FIN-Flag (bzw. wohl auch mit RST) an die CPU weitergegeben werden (ggf. in Kopie, wenn das originale Paket direkt zum Client geht - dann geht es halt nicht verloren), weil sich aus deren Abfolge nun mal ergibt, wann eine TCP-Verbindung komplett eingerichtet wurde (es kommt beim 3-Way-Handshake ja auch ein SYN-Paket vom Ziel zurück beim Aufbau einer TCP-Verbindung und ohne dieses SYN-Paket gibt es gar keine "fertig eingerichtete" Verbindung) und wann sie wieder abgeräumt werden kann.

Da ein solches zusätzliches TCP-Paket mit gesetztem SYN-Flag innerhalb einer bereits eingerichteten TCP-Verbindung m.W. aber eine "protocol violation" wäre (das Flag signalisiert einen Verbindungswunsch und die Verbindung ist ja bereits errichtet), würde ich (wie gesagt, ohne eigenen Test) nicht darauf wetten, daß für ebendieses SYN-Paket irgendeine Reaktion (weder per ICMP-Antwort, noch als ACK oder NACK vom TCP auf L4) erfolgt.

Die Stelle, wo es normalerweise abgelehnt würde (und wo dann das ICMP-Paket erzeugt wird von der PPE), hat es m.E. zu diesem Zeitpunkt bereits passiert und trotzdem kann man mit diesem Paket nichts weiter anfangen, weil man es eigentlich auch an keinen Client im LAN weitergeben sollte.

Denkbar, daß hier auch im Linux-Kernel (bzw. im AVM-WAN-Stack im "kdsldmod.ko") noch ein ICMP-Paket erzeugt wird - genauso aber auch denkbar, daß man bei solchen Protokollverletzungen darauf verzichtet, um das Ganze nicht noch zu verschlimmern. Denn eine ICMP-Benachrichtigung, daß dieses Paket tatsächlich verworfen wurde, kann auch selbst zum Problem werden ... was nimmt man da als Typ und Code? Üblich wäre Typ 3 (unreachable), aber was wäre hier der (Sub-)Code? Oder wäre doch Typ 12 (parameter problem) angesagt (welcher Code dann genau?), weil so ein gesetztes SYN in einer bereits bestehenden Verbindung nichts zu suchen hat?

Solange es da nicht noch eine ausgehende Verbindung gibt, die weiterhin funktionieren soll, ist das alles auch kein Problem ... aber wenn es eine solche gibt, sollte diese ja möglichst durch ein generiertes ICMP-Paket nicht in Mitleidenschaft gezogen werden.

Aber vielleicht liege ich auch komplett daneben und ein weiteres gesetztes SYN-Flag innerhalb einer bereits bestehenden Verbindung wird einfach ignoriert ... ich weiß es ja nicht wirklich und es waren nur Überlegungen, warum da ggf. eine eingehende Verbindung mit exakt denselben Endpoints wie eine bestehende ausgehende Verbindung nicht funktionieren könnte (das steht ja nach meinem Verständnis so in #1) und wo die Ursache dafür (bei einer FRITZ!Box) liegen könnte.

Dazu gehört dann wohl auch das:
Den Satz finde ich komisch formuliert.
Mag sein ... es ging lediglich darum, daß in #1 steht, daß der Port für IPv4 dann "blockiert" wäre - und da auf IPv4 sowohl portbasierte (TCP/UDP) als auch nicht-portbasierte (ICMP) Protokolle aufsetzen und diese auch unterschiedliches Herangehen bei der Behandlung in einer Firewall bzw. bei einer Portfreigabe erfordern, stellt(e) sich für mich die Frage, ob bei einer ausgehenden TCP-Verbindung von Port 5060 (um mal wieder bei SIP zu bleiben) auch der UDP-Port von der beschriebenen Blockade betroffen ist.

Der gesamte Nachtrag in #16 bezieht sich dann - so wie ich es verstehe - auf ein Problem, was ich selbst gar nicht habe und was ich selbst auch in dieser Form noch nicht nachgestellt habe. Wenn man jetzt von Deinem Irrtum absieht, die FRITZ!Box würde bei ausgehenden Verbindungen immer mit einer (vorgegebenen) Port-Range auch PAT machen, gibt es m.E. nichts weiter zu schreiben.

Deinen Irrtum hinsichtlich PAT kannst Du ganz leicht selbst verifizieren ... einfach auf einer FRITZ!Box als Edge-Router einen Paketmitschnitt starten (am besten auf "internet") und von irgendeinem Linux-Host mittels "netcat" eine Verbindung irgendwohin versuchen, wobei mittels "-p"-Option der Source-Port vorgegeben wird. Handelt es sich dabei um einen, der nicht bereits durch eine andere Verbindung belegt wird, verwendet das FRITZ!OS auch genau diesen Port für die ausgehende Verbindung:
sourceport.PNG

Zum Test, was jetzt in den 10 Sekunden, in denen die TCP-Verbindung hier bestand, mit einer eingehenden Verbindung in der exakten Gegenrichtung geschehen würde, müßte ich erst zu vieles umkonfigurieren -
das kann ja jeder selbst bei sich probieren.
 

t_bone

Neuer User
Mitglied seit
29 Jan 2010
Beiträge
18
Punkte für Reaktionen
0
Punkte
1
Nein, die FritzBox macht diese QuellPort-Änderung nicht immer.
Ich habe es auch gerade mit meinem Server getestet. Ihr habt Recht. Ich habe mich da aus dem Fenster gelehnt, da der Normalfall eben ein anderes Vorgehen ist. Diese Art Masquerading zu machen ist "ungewöhnlich". Die Fritzbox muss so jedes ausgehende Paket auch mit allen anderen Sessions vergleichen. Das ist eigentlich mehr Arbeit für den TCP-Stack (egal ob in HW oder SW). Ich kann mir auch gerade kein Szenario innerhalb des SOHO-Bereichs vorstellen, in dem das sinnvoll ist.


Ich habe bei Mir im exposed Host auch nur Ports <1024 die angesprochen werden sollen. Bei Mir würde das Problem also auch nicht auftauchen. Aber wie geschrieben, ich habe auch eine feste IP das funktioniert bei Mir auch

-- Zusammenführung Doppelpst gemäß Boardregeln by stoney


@t_bone:
Ich gehe mal davon aus, daß Du am Ende gar nicht mich meinst?
Doch, doch. Ich habe mich mit deinen Aussagen beschäftigt und bin da anderer Ansicht. ;-) Ich habe übrigens die Sequenznummern bei TCP jetzt der Einfachheit halber und weil Sie in dem Szenario aus meiner Sicht nciht wichtig sind, ignoriert. ;-)


Der von Dir zitierte Absatz bezog sich jetzt aber ausdrücklich auf die denkbare Situation, daß bei einem ausgehenden "Tunnel" durch die Firewall ein TCP-Paket mit gesetztem SYN-Flags eintrudelt, was (sofern das SYN-Flag nicht gesetzt wäre) auf diese ausgehende Verbindung paßt und daher auch zum Client nach innen weitergereicht würde. Man darf davon ausgehen, daß auch bei aktivierter Hardware-Beschleunigung die TCP-Pakete mit gesetztem SYN- bzw. FIN-Flag (bzw. wohl auch mit RST) an die CPU weitergegeben werden (ggf. in Kopie, wenn das originale Paket direkt zum Client geht - dann geht es halt nicht verloren), weil sich aus deren Abfolge nun mal ergibt, wann eine TCP-Verbindung komplett eingerichtet wurde (es kommt beim 3-Way-Handshake ja auch ein SYN-Paket vom Ziel zurück beim Aufbau einer TCP-Verbindung und ohne dieses SYN-Paket gibt es gar keine "fertig eingerichtete" Verbindung) und wann sie wieder abgeräumt werden kann.

Da ein solches zusätzliches TCP-Paket mit gesetztem SYN-Flag innerhalb einer bereits eingerichteten TCP-Verbindung m.W. aber eine "protocol violation" wäre (das Flag signalisiert einen Verbindungswunsch und die Verbindung ist ja bereits errichtet), würde ich (wie gesagt, ohne eigenen Test) nicht darauf wetten, daß für ebendieses SYN-Paket irgendeine Reaktion (weder per ICMP-Antwort, noch als ACK oder NACK vom TCP auf L4) erfolgt.
Dui hast Recht, ich habe da nur einen Teil zitiert. Aber ich bin da anderer Ansicht. Der Threadstarter beschrieb nicht, dass er mittels Paketcrafting, ein neues Paket mit ursprünglichem Quellport erzeugt hat. Er schrieb, er hat den Browser aufgemacht und eine Verbindung auf den Ursprünglichen QuellPort als neuen Zielport initiert. (Das kann er ja auch z.B. auf dem ursprünglichem Zielhost). Das bedeut aber, dass das neue Paket einen neuen Quellport hat und damit eine neue Verbindung ist.

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.

Die Stelle, wo es normalerweise abgelehnt würde (und wo dann das ICMP-Paket erzeugt wird von der PPE), hat es m.E. zu diesem Zeitpunkt bereits passiert und trotzdem kann man mit diesem Paket nichts weiter anfangen, weil man es eigentlich auch an keinen Client im LAN weitergeben sollte.
Hängt davon ab, was das jetzt für ein Paket ist. Aber ja, bei einem zur etablierten Verbindung passenden Rückpaket hast Du m.E. nach Recht

Denkbar, daß hier auch im Linux-Kernel (bzw. im AVM-WAN-Stack im "kdsldmod.ko") noch ein ICMP-Paket erzeugt wird - genauso aber auch denkbar, daß man bei solchen Protokollverletzungen darauf verzichtet, um das Ganze nicht noch zu verschlimmern. Denn eine ICMP-Benachrichtigung, daß dieses Paket tatsächlich verworfen wurde, kann auch selbst zum Problem werden ... was nimmt man da als Typ und Code? Üblich wäre Typ 3 (unreachable), aber was wäre hier der (Sub-)Code? Oder wäre doch Typ 12 (parameter problem) angesagt (welcher Code dann genau?), weil so ein gesetztes SYN in einer bereits bestehenden Verbindung nichts zu suchen hat?
Ich meine mich zu erinnern, dass ein entsprechendes Paket mit einem TCP RST beantwortet werden würde. Aber ich würde nicht streiten wollen


Solange es da nicht noch eine ausgehende Verbindung gibt, die weiterhin funktionieren soll, ist das alles auch kein Problem ... aber wenn es eine solche gibt, sollte diese ja möglichst durch ein generiertes ICMP-Paket nicht in Mitleidenschaft gezogen werden.

Aber vielleicht liege ich auch komplett daneben und ein weiteres gesetztes SYN-Flag innerhalb einer bereits bestehenden Verbindung wird einfach ignoriert ... ich weiß es ja nicht wirklich und es waren nur Überlegungen, warum da ggf. eine eingehende Verbindung mit exakt denselben Endpoints wie eine bestehende ausgehende Verbindung nicht funktionieren könnte (das steht ja nach meinem Verständnis so in #1) und wo die Ursache dafür (bei einer FRITZ!Box) liegen könnte.
Du darfst aber auch nicht vergessen, dass es Fehler oder andere Probleme in der Verbindung geben kann, auf die TCP mit Retransmissions oder anderen Mechanismen reagieren kann und das es mit den RFC's auch ein entsprechendes Vorgehen gibt. Das heißt ja aber auch nicht, das die RFC's korrekt implementiert sind. :)


Deinen Irrtum hinsichtlich PAT kannst Du ganz leicht selbst verifizieren ... einfach auf einer FRITZ!Box als Edge-Router einen Paketmitschnitt starten (am besten auf "internet") und von irgendeinem Linux-Host mittels "netcat" eine Verbindung irgendwohin versuchen, wobei mittels "-p"-Option der Source-Port vorgegeben wird. Handelt es sich dabei um einen, der nicht bereits durch eine andere Verbindung belegt wird, verwendet das FRITZ!OS auch genau diesen Port für die ausgehende Verbindung:
Anhang anzeigen 106953

Zum Test, was jetzt in den 10 Sekunden, in denen die TCP-Verbindung hier bestand, mit einer eingehenden Verbindung in der exakten Gegenrichtung geschehen würde, müßte ich erst zu vieles umkonfigurieren -
das kann ja jeder selbst bei sich probieren.
Habe ich, ich habe die Verbindung auf dem Client und auf einem Server mitgeschnitten. Hätte ich nicht erwartet, ist aus meiner Sicht auch nicht richtig. Aber ich hatte an der Stelle unrecht.


Gruß


Nachtrag:

Ich konnte das von sonykatze beschriebene Verhalten nachstellen.
Folgendes Szenario:
Client im Netz hinter einer Fritzbox, ESXi-Host mit virtuellem System als Firewall, die Firewall als exposed Host. Server irgendwo im Internet.

ausgehende SSH-Verbindung vom Client zum Server. Quellport der Verbindung 35106, Port mit tcpdump auf dem Client und dem Server überprüft
auf dem Server mittels telnet neue Verbindung zur öffentlichen IP der Fritzbox initiert.
telnet 1.2.3.4 35106 > diese Verbindung taucht im Log der Firewall, welche als exposed Host konfiguriert ist nicht auf
telnet 1.2.3.4 35107 > diese Verbindung taucht im Log der Firewall als geblockte Verbindung auf.

ich habe dann mal eine neue Verbindung vom Client auf den Port des Webservers initiert. Den Quellport dieser Verbindung mit tcpdump auf dem Client und dem Server überprüft.
Dabei war der Webserver auf dem Server deaktiviert, das heißt die Verbindung kam nicht zu stande.
auf dem Server: telnet 1.2.3.4 35115 > diese Verbindung taucht im Log der Firewall als geblockte Verbindung auf.

Webserver wurde aktiviert und der Client hat die Webseite auf dem Server neu aufgerufen.
auf dem Server: telnet 1.2.3.4 35212 > diese Verbindung taucht im Log der Firewall, welche als exposed Host konfiguriert ist nicht auf

Sofern die Verbindung zum Server beendet wurde.
auf dem Server: telnet 1.2.3.4 35212 > diese Verbindung taucht im Log der Firewall als geblockte Verbindung auf.

Das Verhalten ist aus meiner Sicht nur schlecht sinvoll begründbar. Anscheinend gibt es eine Tabelle der aktuellen Sessions. Sonst würde der Status der beendeten Verbindung nicht so aktualisiert. Zu einer Session gehören mindestens QuellPort, QuellIP und ZielIP, ZielPort. Die ausgehende Session besteht nicht aus den selben Merkmalen wie die eingehende Session.
Genau wie es bei ausgehenden Verbindungen auf der Fritzbox die selbe Kombination mit QuellPort und Zielhost geben kann (eigentlich würde richtiges PAT das verhindern) kann es natürlich bei eingehenden Verbindungen auch die selbe Kombination geben. Ich vermute aus diesem Grund blockiert die Fritz stumpf den Port statt die Sessions insgesamt zu prüfen. Das ist an dieser Stelle schneller und (Thema DOS, DDOS) und kostet weniger Rechenzeit auf der Box für die eingehenden Verbindungen
 
Zuletzt bearbeitet von einem Moderator:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,423
Punkte für Reaktionen
1,130
Punkte
113
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.
 
3CX

Statistik des Forums

Themen
236,553
Beiträge
2,078,468
Mitglieder
358,071
Neuestes Mitglied
fhasel