Wer kann mir Exposed-Host erklären?

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
1,446
Punkte für Reaktionen
125
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,510
Punkte für Reaktionen
323
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,446
Punkte für Reaktionen
125
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
52
Punkte für Reaktionen
1
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,446
Punkte für Reaktionen
125
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
52
Punkte für Reaktionen
1
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,446
Punkte für Reaktionen
125
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
460
Punkte für Reaktionen
25
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
52
Punkte für Reaktionen
1
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,846
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
314
Punkte für Reaktionen
40
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
52
Punkte für Reaktionen
1
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,846
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,099
Punkte für Reaktionen
1,000
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,446
Punkte für Reaktionen
125
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:
3CX

Neueste Beiträge

Statistik des Forums

Themen
235,582
Beiträge
2,062,854
Mitglieder
356,343
Neuestes Mitglied
markusgrau