UM/Vodafone FB Cable 6590, cablemax & bridge mode

JeGr

Ahoi,

da ich leider wenig Zeit momentan habe durch die aktuelle Situation, ist das auch schon wieder 2-3 Wochen her. Nach der letzten Umstellung auf CableMax500 im Homeoffice, ist die FB von UM durch Vodafone nochmal aktualisiert worden. Bridge Mode hatte ich früher schon gesehen, nun aber tatsächlich mal ausprobieren wollen. Also Setup:

<WAN> ---Koax--- <FB6590> ===== <Uplink Switch> ---< pfSense/TestNB

Vom Koax Kabel also in die Fritte und dort gehen jetzt 2 Kabel auf LAN 1 und 2 raus und in meinen Unifi SW 24 und dort hängt das eine VLAN dann an der pfSense am WAN, das andere ist durchgepatcht auf ein Laptop. Beide bekommen dort default eine 192.168.178er IP. Soweit so klar.

Jetzt Spaß gemacht und den Port, an dem die pfSense hängt an der Fritte im Menü auf "Bridge enabled" gesetzt. Kurz gewartet und... OHA!

Effekt nun wie folgt:

FB ist nach wie vor eingewählt im Kabelnetz mit DualStack! (in der GUI definitiv zu sehen, hat auch ein /56er oder 60er Prefix bezogen. Mein Test-NB bekommt von ihr eine 192.168.178er IP und eine IP6 aus dem bezogenen Zusatzprefix. Spannend! TestNB geht raus ins Internet und kommt dort auch mit der externen v4/v6 der FB an. Wie logisch vorher auch.

ABER

pfSense Box hat nun DHCP und DHCP6 direkt aktiv und ist nun selbst AUCH mit einer eigenen IPv4 UND IPv6 Prefix eingewählt - über die FB als Bridge/Modem. Der Witz daran: Ich kann jetzt aus den internen Netzen der pfSense die FB nicht mehr sehen, habe aber quasi eine eigene IP Verbindung an der Fritte vorbei. Das kann man auch sehen, denn das NB hinter der pfSense hat eine andere externe IP als der TestNB der direkt an der Fritte hängt. 2 echte IPv4 und echtes IPv6 Prefix. NASOWAS!

Aber vielleicht nur Augenwischerei? in Wirklichkeit doch irgendwie alles auf der FB und gemauschelt? Nein, sieht nicht so aus, denn die pfSense Box ist jetzt wirklich direkt verbunden, bekommt auch ohne exposed Host und Co sämtlichen Traffic etc. etc. - kein zusätzliches Routing o.ä. notwendig. Auch von extern fehlt ein zusätzlicher Hop bei einem Traceroute.

Der Test vor kurzem war dann mit einem witzigen Spiel auf der Konsole, dessen Multiplayer etwas verbuggt ist und es momentan nicht hinbekommt, dass 2 Konsolen aus dem gleichen LAN Online zusammen spielen können. (seufz!) Also einfach die Probe aufs Exempel gemacht: zweite Konsole an die Testader gehängt, die direkt auf die FB weitergepatcht ist. Siehe da, Konsole 1 hat 172er IPs, Konsole 2 bekommt die FB 192er IPs. Beide kommen mit anderen externen IPs am Server an und - Tadaa - können sich problemlos gegenseitig finden und verbinden :)

Im Prinzip könnte ich nun die Ader zur FB sogar direkt auf der pfSense als 2. WAN auflegen und damit direkt steuern, wer über welche externe IP rausgeht und müsste das dann nicht mehr stecken, aber das bastle ich, wenn ich das nächste Mal Langeweile habe - also so nächstes Jahr etwa ;)

Aber vielleicht ist das ja für den ein oder anderen Kabelkunden (oder evtl auch bei DSL möglich?) interessant, dass ers mal ausprobieren möchte. Bei DSL ist da ja immer noch die VLAN, Anmeldegeschichte, PPPoE etc. im Spiel, aber da Kabel via DHCP das direkt vergibt, ist man hier mit der Methode anscheinend einfach und schnell die doppelte NAT und Macken der FB davor los - und kann trotzdem die FB und deren LANs/WLAN sowie VoIP noch benutzen (und seis nur fürn Notfall wenn was kaputt konfiguriert ist.

Grüße
Jens