Vodafone "Bridge Mode" mit eigener FritzBox 6690 DOCH möglich? Ja, bei mir schon.

[LunaCorp]

Hallo liebe Community,

ich habe eine Frage zum Bridge Mode bei Vodafone: Überall lese ich, dass dieser mit eigenen FritzBox-Geräten nicht mehr funktioniert. Doch bei mir geht es problemlos – ich bin neugierig, warum das so ist.

Ich habe mir eine FritzBox 6690 Cable gekauft, weil ich das Leihgerät von Vodafone nicht wollte. Im Webinterface war die Bridge-Mode-Einstellung allerdings nicht verfügbar. Der Support sagte, sie würden den Bridge Mode nur aktivieren, wenn ich die MAC-Adresse eines Modems angebe, nicht die meiner FritzBox.
Nach einigem Suchen fand ich online eine Anleitung: Durch eine kleine Änderung in der Konfigurationsdatei (Backup) konnte ich LAN1 für den Bridge Mode freischalten – und es funktionierte sofort.
Jetzt läuft mein Netzwerk einwandfrei: Die FritzBox hat Internet, mein Synology-Netzwerk dahinter funktioniert ebenfalls stabil, und ich habe volle Leistung.

Meine Frage: Könnte es sein, dass Vodafone den Bridge Mode absichtlich versteckt? Liegt das an technischen Gründen oder daran, dass sie ihre eigenen Geräte bevorzugen? Oder könnte es an meiner speziellen Situation liegen? In meiner vorherigen Wohnung hatte ein Techniker meine FritzBox eingerichtet und die MAC-Adresse registriert – vielleicht wurde sie deshalb im System erkannt?

Ich würde mich freuen, eure Meinungen und Erfahrungen zu hören!

So bleibt der Text informativ, freundlich und übersichtlich.

 

[boba]

Es hat durchaus technische Gründe, wieso der Bridge Modus nicht zwangsläufig verfügbar sein könnte. Der mir bekannte Grund ist die knappe Verfügbarkeit von öffentlichen IPv4 Adressen. Im Bridge-Modus benötigt ein Anschluss 2 IPv4 Adressen: eine für das docsis Modem (das gebietet die docsis Spezifikation, das ist nicht änderbar) und eine für den Router. Im Router-Modus eines all-in-one Routers hingegen nur eine, weil die Adresse für das Modem auch für den Router verwendet werden kann. Lässt man zu viele doppel-IP-Vergaben zu, könnte es passieren, dass einzelne Kunden überhaupt keine IPv4 Adresse erhalten.

Bestimmt könnte man es so machen, dass im Bridge-Modus das Modem eine private IP-Adresse erhält und der Router eine öffentliche, so dass auch dort nur 1 öffentliche Adresse erforderlich ist. Aber möglicherweise ist eine solche unterschiedliche Vergabe auf den Backends technisch nicht möglich.

Außerdem ist der Support-Aufwand für Heimnetze, in denen der Bridge-Modus läuft, um Längen höher als für den Betrieb eines defaultkonfigurierten all-in-one Gerätes. Das kommt daher, weil viele Leute überfordert sind mit einer Modem/Router Combo und dann Störungen melden, die an der Fehlkonfiguration des Anwenders liegen und nicht an Problemen im Vodafone-Netz. Das weiß ich allerdings nicht, ob das ein hinreichender Grund für die Sperre des Bridge-Modus ist.

 

[why_]

Nach einigem Suchen fand ich online eine Anleitung: Durch eine kleine Änderung in der Konfigurationsdatei (Backup) konnte ich LAN1 für den Bridge Mode freischalten – und es funktionierte sofort.

Das funktioniert nur weil Vodafone West seit ca einem Jahr auch Kundeneigene Geräte mit maxcpe=2 provisioniert. Vorher hat das nicht funktioniert da es bei Kundegeräten immer maxcpe=1 war und sich die Fritzbox immer selbst die einzige IP aus dem öffentlich Service Flow gezogen hat um Telefonie zu machen (oder was auch immer AVM meint wäre wichtiger als dem Käufer Internet bereitzustellen) und man kann den Drecksboxen das auch nicht abtrainieren kann, weshalb man zwangsweise ein anderes Modem benötigte.

Im Bridge-Modus benötigt ein Anschluss 2 IPv4 Adressen: eine für das docsis Modem (das gebietet die docsis Spezifikation, das ist nicht änderbar)

Fritzboxen ziehen sich im Bridgemode sogar drei IPs, einmal im Service Netz im Öffentlichen Netz für sich selbst und dann noch die IP die sie per Bridge weiterreichen.

Bestimmt könnte man es so machen, dass im Bridge-Modus das Modem eine private IP-Adresse erhält und der Router eine öffentliche, so dass auch dort nur 1 öffentliche Adresse erforderlich ist. Aber möglicherweise ist eine solche unterschiedliche Vergabe auf den Backends technisch nicht möglich.

Alles bis auf Fritzboxen macht das so.
AVM war schon immer der Meinung das sie alles besser Wissen und man dem User lieber nichts konfigurieren lässt, weshalb deren schrott Produkte niemals einen Einzug in mein Heimnetz bekommen werden.

 

[MrHonk]

AVM war schon immer der Meinung das sie alles besser Wissen und man dem User lieber nichts konfigurieren lässt, weshalb deren schrott Produkte niemals einen Einzug in mein Heimnetz bekommen werden.

Was für den Otto-Normal-Käufer, der nun einmal den weitaus größeren Teil der Kundschaft darstellt, auch völlig ausreichend ist. AVM hat nicht ohne Grund so eine große Bekanntschaft und Beliebtheit erreicht. Deren Produkte könnten halt auch von Opa Heinz oder Oma Waltraud angeschlossen werden, die die wenigen benötigten Daten gemäß Anleitung selbst eintragen können.

 

[why_]

Deren Produkte könnten halt auch von Opa Heinz oder Oma Waltraud angeschlossen werden, die die wenigen benötigten Daten gemäß Anleitung selbst eintragen können.

Wenn AVM an ihre Produkte dran schreiben würde nur für Opa Heinz oder Oma Waltraud und hat absolut rein gar nichts, absolut überhaupt nichts, in Haushalten mit Ansprüchen oder kommerziellen Umfeldern was zu suchen, sowie der Müll nicht als Provider Box rausgegeben werden würde wäre ich ja auch glücklich. Leider muss ich den Müll dennoch immer wieder auch bei Kleinunternehmen vorfinden und dann muss man immer wieder erklären warum die die 300€ Fritzbox doch jetzt bitte in den Müll schmeißen und sich jetzt was vernünftiges anschaffen. Ich habe in den letzten Jahren bestimmt über 30.000 € an Fritzboxen entsorgt und zurückschicken lassen und es wäre wirklich schön wenn Leute das Geld stattdessen für irgendwas Sinnvolles ausgegeben hätten.

 

[Tom_123]

es wäre wirklich schön wenn Leute das Geld stattdessen für irgendwas Sinnvolles ausgegeben hätten.

das da wäre? nen Kabelmodem ohne Support und Firmwareupdates?

 

[Soldierofoc]

Ich verstehe schon seinen Punkt. Selbst als Unternehmen (zumindest KMUs) bist du auf dem Land recht angeschmiert und dir bleibt dann in der IT tatsächlich nur z.B. so ein Kabelmodem ohne großen Support, wenn du einen gescheiten Router bzw. gesamtes Netzwerk dahinter setzen willst um z.B. einen ausreichend großen VPN Durchsatz haben zu können.
Wenn mehr Budget da ist, dann eine eigene Glasfaser, sofern es wirtschaftlich abbildbar ist.

 

[audioactive]

Hey, du brauchst grundsätzlich einen dual stack / ipv4 anschluss damit du bridgen kannst. ipv6 wird ja über aftr server auf ipv4 aufgelöst, ergo mit ca 40 user geteilt, da kann man weder bridgen noch ipv4 ports freigeben/forwarden.

Hat man mit homebox (fritzbox + 3 rufnummer), bzw 1000/50 Mbit/s eine DSlite Verbindung, lässt sich das durch VF Support auf Dual Stack umstellen, ohne weitere Kosten.

Mit nem Dual Stack klappts auch mit nem Mietgerät ohne probleme.

 

[why_]

ipv6 wird ja über aftr server auf ipv4 aufgelöst, ergo mit ca 40 user geteilt

Wie kommst du auf diese Zahl?

 

[MartinP_Do]

Wie kommst du auf diese Zahl?

Das ist so das was im Internet verbreitet wird. 30....40 User.

Hatte irgendwo ein YouTube Video von einem Kongressvortrag gesehen, wo jemand das auf irgendeine trickreiche Weise herausbekommen hat
Das Youtube Video habe ich nicht mehr gefunden, hier redet man von 1000 Usern per IPv4 - das halte ich aber für sehr fragwürdig ... Das wären dann nur 65 Ports pro User, da IPv4 Sockets auf 64k (ushort) beschränkt sind ...

https://www.reddit.com/r/tmobileisp/comments/unlga3

The ip4 address are shared. Probably 1000 people per. That’s what CGNAT is.

Dann noch dieser RFC

https://www.rfc-editor.org/rfc/rfc6269
Ich denke eher, dass man vielleicht maximal 64 Subscriber auf eine IPv4 Adresse klemmt, dann wären für jeden Subscriber noch 1024 Ports möglich...
Bei dem Vortrag wurde wohl ausprobiert, wie viele Ports man öffnen kann, und daraus wurden dann Rückschlüsse darauf gezogen, wie viele Subscriber der AFTR auf eine IPv4 Adresse legt ...

 

[audioactive]

Wie kommst du auf diese Zahl?

Ach, grob geschätzt Hier ist ja nicht die Anzahl der Verbraucher, sondern eben der Tunnel an sich im Fokus. Bin was die Anzahl der User angeht, ganz @MartinP_Do 's Meinung

 

[audioactive]

Ich verstehe schon seinen Punkt. Selbst als Unternehmen (zumindest KMUs) bist du auf dem Land recht angeschmiert und dir bleibt dann in der IT tatsächlich nur z.B. so ein Kabelmodem ohne großen Support, wenn du einen gescheiten Router bzw. gesamtes Netzwerk dahinter setzen willst um z.B. einen ausreichend großen VPN Durchsatz haben zu können.
Wenn mehr Budget da ist, dann eine eigene Glasfaser, sofern es wirtschaftlich abbildbar ist.

KMU aufm Land sollte sich nen Docsis 3.1 Kabelfunzel & static IP leisten können. Dann sollte eigenen Infrastruktur nichts mehr im Weg stehen

 

[MartinP_Do]

KMU aufm Land sollte sich nen Docsis 3.1 Kabelfunzel & static IP leisten können. Dann sollte eigenen Infrastruktur nichts mehr im Weg stehen

Naja, wenn es mit dem Upload irgendwann besser wird .. 50 MBit/s sind da wohl eher, nur etwas für "K" und nicht für "M"

 

[why_]

Das wären dann nur 65 Ports pro User, da IPv4 Sockets auf 64k (ushort) beschränkt sind ...

Das wären 65 ports pro Zieladresse und nicht pro user (5-Tuple) oder du musst mal genauer erklären was da beschränkt ist. Ich würde jetzt mal behaupten das man bevor man in irgendwelche technische Limitation reinläuft eher in organisatorische läuft, wenn du da 10k Nutzer hinter einer IP hast kann ich mir vorstellen das so gut wie alles mit captchas und ratelimits zugekleistert ist und man deshalb das Internet nicht mehr wirklich gut nutzen kann. Wenn man mal wissen will wie das in der Praxis ist, kann man ja mal über einen größeren tor exit node surfen und captchas und ratelimits zählen.

 

[boba]

Jede Verbindung läuft über das Gateway. Jede Verbindung erfordert einen Port. Bei mehreren Maschinen können identische Portnummern vorkommen, deshalb muss das Gateway jeden externen Port in einen internen Port umsetzen. So funktioniert NAT, und CGNAT ist da exakt dasselbe. Aus Sicht der Zielsysteme gibt es Verbindungen nur vom und zum Gateway. Das bedeutet, bei 65535 möglichen Ports sind das 65535 mögliche Verbindungen. Bei 1000 Usern wären das 65 Ports pro User. Das ist zu wenig, vor allem da längst nicht alle der 65535 möglichen Portnummern auch tatsächlich zur Verfügung stehen. 10000 User gehen schon gar nicht, realistisch halte ich bis 50-60 User. Das wären dann knapp 1000 mögliche Ports.
Im übrigen sind diese Gateways ganz stinknormale Server oder Appliances mit Netzwerkkarten. Wenn dort ein Durchsatz von 1 Gbit pro Anschluss angenommen wird, dann wären 40 Anschlüsse bis zu 40 Gbit, was im übrigen auch lange Zeit das Maximum war, was man so für Ethernet kaufen konnte. Da gehts bei den neusten mittlerweile bis 200 gbit, aber da ist dann Schluss. Wobei du natürlich eine Netzwerkkarte nicht bis 100% ausnutzen kannst, bis 70% oder so in der Gegend dürfte das gehen, bevor sich die Latenzen erhöhen.

 

[why_]

Jede Verbindung läuft über das Gateway. Jede Verbindung erfordert einen Port. Bei mehreren Maschinen können identische Portnummern vorkommen, deshalb muss das Gateway jeden externen Port in einen internen Port umsetzen. So funktioniert NAT, und CGNAT ist da exakt dasselbe. Aus Sicht der Zielsysteme gibt es Verbindungen nur vom und zum Gateway. Das bedeutet, bei 65535 möglichen Ports sind das 65535 mögliche Verbindungen. Bei 1000 Usern wären das 65 Ports pro User.

???
Dann wäre ja auch bei 65535 aktiven Verbindungen Schluss?

 

[boba]

Mir kommt das gerade so vor, als hätte ich gesagt: "Der Himmel ist blau", und du fragst: "Der Himmel ist blau?"

 

[why_]

Mir kommt das gerade so vor, als hätte ich gesagt: "Der Himmel ist blau", und du fragst: "Der Himmel ist blau?"

Das wäre ja korrekt daher nein, meine Frage war eher ob sich die Sonne um die Erde dreht um mich zu versichern das ich euch richtig verstehe und deine Antwort war ein überzeugtes ja. Das war mal Stand der Wissenschaft, ist aber schon lange her.
Heutzutage tut man Ports wiederverwenden und damit sind dann halt Millionen Sessions möglich solange die ziel IP nicht die selbe ist. Siehe RFC 7857, RFC 4787, RFC 5382, RFC 5508 oder z.B. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJACA0 für konkrete Zahlen.

 

[MartinP_Do]

solange die ziel IP nicht die selbe ist.

Die Ziel IP ist aber für die Server im Internet die selbe: die shared IP des AFTR

Der Hinweg zum Server ist nicht das Problem, sondern der Rückweg....

 

[shm0]

Der AFTR muss ja nicht unbedingt nur eine shared IP haben...

 

[why_]

Die Ziel IP ist aber für die Server im Internet die selbe: die shared IP des AFTR

Der Hinweg zum Server ist nicht das Problem, sondern der Rückweg....

Das wäre nur ein Problem wenn aus welchem Grund auch immer alle hinter dem AFTR gateway sich mit der selben Webseite verbinden wollen also alle z.B. 1.1.1.1 als DoT Server konfiguriert haben und selbst dann wäre das eigentlich kein Problem da DoT http2 nutzt und somit multiplexing macht, somit müssten beim Enduser dann auch noch 60+ DoT resolver laufen. Also irgendwie ist mir das alles zu theoretisch um in der Realität zum Problem zu werden.
Aber vielleicht habt ihr ja ein Beispiel aus der Realität wo das tatsächlich zum bottleneck wird, ich wäre interessiert daran, da mir gerade keins in den Sinn kommt.

 

[MartinP_Do]

Es geht nicht um die Verbindung ZUM Server, sondern um die Verbindung der Server im Internet zur shared IPv4
Mach das Analysetool Deiner Wahl auf, und öffne Einen Browsertab.
Mindestens eine Ausgehende Verbindung auf Socket 443 und zugehörige eingehende Verbindungen auf hohen Socket Nummern jenseits der 10000.
Bei heutigem werbe und Javascript verseuchten Seiten sind es pro Tab schon teilweise 3...5 Sockets, die offen sind, um Inhalte zum Browser zu übertragen.

 

[boba]

Die Endpunkte einer tcp/ip Verbindung sind durch 2 Angaben spezifiziert: die IP Adresse und der Port. Mit der IP Adresse adressiert man eine Maschine, mit dem Port eine Anwendung auf dieser Maschine, die diese Verbindung verwendet.

NAT funktioniert nun so:
Das interne System kann nicht direkt von einem externen System adressiert werden kann, also fungiert das Gateway als Stellvertreter. Öffnet ein internes System A eine Verbindung zu einem externen System, dann merkt sich das Gateway: Verbindung A hat als internen Endpunkt [internIPA]:[portA]. Nun ersetzt das Gateway internIPA durch seine öffentliche IP Adresse und schickt das Paket nach draußen. Die Antwort kommt an [GatewayIP]:[portA]. Das Gateway sucht in seiner Tabelle nach portA, findet internIPA als Adresse. Es ersetzt in dem Antwortpaket GatewayIP durch internIPA und leitet es entsprechend dort hin weiter.

Nun öffnet ein weiteres internes System B eine Verbindung zu demselben externen System: Verbindung B mit internem Endpunkt [internIPB]:[portB]. Zufälligerweise wurden von Maschine A und Maschine dieselben internen Ports verwendet. Das ist ja möglich. Nun trägt das Gateway [internIPB]:[portB] in seine Tabelle ein und ersetzt wieder die Absenderadresse internIPB durch seine GatewayIP und schickt das Paket raus.
Jetzt kommt das Antwortpaket. Allerdings gibt es jetzt ein Problem: es gibt 2 Einträge in der Tabelle, portA und portB, beide mit demselben Port. Man kann also beim Antwortpaket nicht unterscheiden, ob dieses Paket an A oder B gerichtet ist.

Es ist also erforderlich, einen Ersatzport für die neue Verbindung B zu wählen, einen der von portA verschieden ist. Das Gateway muss also einen Ersatzport aus einen seiner freien 65536 lokalen Portnummern wählen, das in die Tabelle eintragen und bei ausgehenden Paketen sowohl IP Adresse als auch Port umsetzen: [internIPB]:[portB] wird zu GatewayIP:gatewayPortX.
Der Vereinheitlichung halber und aus Performancegründen wird in tatsächlichen Implementierungen grundsätzlich immer ein Ersatzport gewählt - so oder so könnte ein in Gebrauch befindlicher Port ohnehin nicht mehr als Ersatzport für eine weitere Verbindung verwendet werden.

Und so hat das Gateway in seiner Umsetzungstabelle eben Platz für seine 65536 möglichen Ports. So ist das NAT auch sehr schnell gemacht: die Portnummer dient als Index in die Tabelle, im Tabelleneintrag steht die interne IP+interner Port. Macht bei 65536 Einträgen und 4 Byte IP Adresse + 2 Byte Portnummer = 6 Bytes pro Eintrag 65536 * 6 = 393216 Bytes Tabellengröße. Aus diesem Grund ist NAT übrigens auch kein Performanceverlust, dieser simple Table-Lookup erhöht nicht die Latenz, weil er keine wirkliche Rechenzeit erfordert.

 

[why_]

Habt ihr überhaupt irgendeins der RFCs gelesen?

Die Endpunkte einer tcp/ip Verbindung sind durch 2 Angaben spezifiziert: die IP Adresse und der Port. Mit der IP Adresse adressiert man eine Maschine, mit dem Port eine Anwendung auf dieser Maschine, die diese Verbindung verwendet.

NAT funktioniert nun so:
Das interne System kann nicht direkt von einem externen System adressiert werden kann, also fungiert das Gateway als Stellvertreter. Öffnet ein internes System A eine Verbindung zu einem externen System, dann merkt sich das Gateway: Verbindung A hat als internen Endpunkt [internIPA]:[portA]. Nun ersetzt das Gateway internIPA durch seine öffentliche IP Adresse und schickt das Paket nach draußen. Die Antwort kommt an [GatewayIP]:[portA]. Das Gateway sucht in seiner Tabelle nach portA, findet internIPA als Adresse. Es ersetzt in dem Antwortpaket GatewayIP durch internIPA und leitet es entsprechend dort hin weiter.

Nun öffnet ein weiteres internes System B eine Verbindung zu demselben externen System: Verbindung B mit internem Endpunkt [internIPB]:[portB]. Zufälligerweise wurden von Maschine A und Maschine dieselben internen Ports verwendet. Das ist ja möglich. Nun trägt das Gateway [internIPB]:[portB] in seine Tabelle ein und ersetzt wieder die Absenderadresse internIPB durch seine GatewayIP und schickt das Paket raus.
Jetzt kommt das Antwortpaket. Allerdings gibt es jetzt ein Problem: es gibt 2 Einträge in der Tabelle, portA und portB, beide mit demselben Port. Man kann also beim Antwortpaket nicht unterscheiden, ob dieses Paket an A oder B gerichtet ist.

Es ist also erforderlich, einen Ersatzport für die neue Verbindung B zu wählen, einen der von portA verschieden ist. Das Gateway muss also einen Ersatzport aus einen seiner freien 65536 lokalen Portnummern wählen, das in die Tabelle eintragen und bei ausgehenden Paketen sowohl IP Adresse als auch Port umsetzen: [internIPB]:[portB] wird zu GatewayIP:gatewayPortX.
Der Vereinheitlichung halber und aus Performancegründen wird in tatsächlichen Implementierungen grundsätzlich immer ein Ersatzport gewählt - so oder so könnte ein in Gebrauch befindlicher Port ohnehin nicht mehr als Ersatzport für eine weitere Verbindung verwendet werden.

Eben nein, das was ihr da beschreibt hat man vor 20 Jahren gemacht, allein um gegen port exhausten angriffe sich zu wappnen wäre das ein absolutes nogo das heute noch so zu machen.
Heute merkt sich das Gateway [interneIP], [internerPort], [zielIP], [zielPort], [lokalerPort], bei Nutzung von IP pools noch [lokaleIP]

Aufbau aus Sicht des Gateways:

1. Gerät A sendet eine Verbindung:
   • Quell-IP/Port: [interneIP1]:50000
   • Ziel-IP/Port: [zielIP1]:443
   • NAT-Mapping: [lokaleIP]:50000 → [zielIP1]:443
2. Gerät B sendet gleichzeitig eine Verbindung:
   • Quell-IP/Port: [interneIP2]:50000
   • Ziel-IP/Port: [zielIP2]:443
   • Das Gateway nutzt denselben externen Port 50000:
     • [lokaleIP]:50000 → [zielIP2]:443
3. Das Gateway unterscheidet die beiden Verbindungen anhand der [zielIP]:
   • [interneIP1]:50000 ↔ [lokaleIP]:50000 ↔ [zielIP1]:443
   • [interneIP2]:50000 ↔ [lokaleIP]:50000 ↔ [zielIP2]:443

Da die [zielIP] unterschiedlich ist, kann das Gateway erkennen, an welches interne Gerät es Antworten weiterleiten muss und somit besteht das 65536 Port Limit pro [zielIP] und nicht pro [lokaleIP] und bei Nutzung von einem IP pool an [lokaleIP]s steigt dieses Limit noch um die Anzahl an [lokaleIP]s für jede einzelne [zielIP]

 

[boba]

Das geht so zwar theoretisch, aber hättest du ein konkretes Produkt und eine entsprechende Referenz, wo das tatsächlich und real Anwendung findet? Ich habe bisher nur NAT Implementierungen gesehen, die eindeutige Portnummern verwenden und damit auf 65535 Verbindungen pro IP Adresse limitiert sind, z. B. ist das mein Kenntnisstand von iptables/netfilter. Das Problem ist, dass man überall nur oberflächliche Beschreibungen findet, wie man Dinge konfiguriert, und was sie generell tun, aber sowas ist ein Detail, das einfach nirgendwo zu finden ist.