19.04.2025, aktualisiert um 21:42:37 Uhr

2300

"Kreative" Tricks mit Mikrotik beim Telekom Glasfasermodem2

Hallo Mikrotik-Freaks....

Ich habe leider das Pech dass mein LAN-Subnet zufällig im gleichen Subnet liegt welches das "Glasfasermodem2" von der Telekom macht.
Also mein Haupt-LAN liegt im Bereich 192.168.100.0/24, der Mikrotik als zentraler Router hat die IP:192.168.100.1.
Dieses sch(Pieep#*#*) "Modem" hat tatsächlich die IP 192.168.100.1 welche man auch nicht ändern kann.
Eigentlich ist der Begriff "Modem" falsch, das Ding ist eher ein Medienkonverter von Glas auf Kupfer.
Die Einwahl erfolgt per PPPoE mit dem Mikrotik (sogar die VLAN7 ID muss man setzen, da auch dies nicht durch dieses "Modem" erfolgt)
Nun, das Ding hat ein sehr einfaches WebIF welches den Status der Verbindung (Linkstate / Dämpfung etc.) anzeigt.
Jetzt habe ich verschiedene Optionen:
1. Mein Haupt-LAN und auch die anderen LANs anpassen und auf ein anderes Subnet wechseln, was relativ unbequem und nervig ist.
2. Auf das WebIF von dem Ding verzichten, aber bei Problemen mit dem Anschluss wäre es sicher hilfreich auf das WebIF von dem Teil zu kommen (wenn man die Hotline dran hat etc.)
3. Mit dem Mikrotik gewaltig "Tricksen" und die Adresse "umbiegen" / NATen / etc.
Mein Plan wäre:
Eine virtuelle Adresse schaffen wie z:b. 192.168.100.99 (diese ist frei) und dann die Anfrage geschickt umbiegen auf die WAN-Seite an der das Modem angeschlossen ist. Das Hauptproblem ist ja das die IP-Adresse vom Modem mit der Adresse vom Mikrotik gleich ist.

Der Aufbau sieht so aus:
LAN seitig ist der Mikrotik auf der IP 192.168.100.1
WAN seitig gibt es derzeit nur das PPPoE Protokoll, hier müsste "IP" noch dazu kommen z.B. 192.168.100.99.
Nun müssen Firewallregeln her welche Anfragen im LAN an z.B. 192.168.100.99 "umbiegen" auf die 192.168.100.1 auf der WAN Seite (nicht vergessen, im LAN gibt es ja auch die 192.168.100.1 welche ja der Mikrotik selbst ist)
Hat hier jemand schon so "schmutzige" Tricks angewendet?
Das dies an sich eine "verbotene" Konfig ist, ist mir klar mir geht es nur um eine Machbarkeit

Wenn nicht dann werde ich halt die Kröte schlucken und mein eines LAN komplett umziehen wegen diesen verfl Teil .....

Grüße

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 672552

Url: https://administrator.de/forum/kreative-tricks-mit-mikrotik-beim-telekom-glasfasermodem2-672552.html

Ausgedruckt am: 12.05.2025 um 02:05 Uhr

18 Kommentare

Neuester Kommentar

Moin

Stell einfach Dein Netz auf ein 172-er /24 aus dem Bereich 172.16.0.0/16 um. Dann erstarrt Du Dir jetzt und in Zukunft "Tricksereien".

lks

Um langfristig safe zu sein würde ich auch auf einen anderen LAN-Bereich ausweichen...

eines von 172.16.x.0/24 - 172.31.x.0/24
oder 10.x.y.0/24

ist mir klar mir geht es nur um eine Machbarkeit face-smile

Ja geht...mit ner separaten Routing-Tabelle, zus. 192.168.100.2/30er IP auf dem Port zum Modem, einer Routing-Mark im mangle + Route mit vrf-interface, einer dst-nat rule von einer "virtuellen" nicht existierende IP auf die des Modems, und einer src-nat rule zum Modem hin in Kombination problemlos realisierbar 😋.
Deswegen liebe ich die Dinger, damit kannst du dir so gut wie fast alles passend zurecht schneidern 🤪

Zitat von @BiberMan:

ist mir klar mir geht es nur um eine Machbarkeit face-smile

Alternativ einfach das Modem ignorieren und dem Interface dorthin gar keine IP-Adresse geben. Auf das Modem brauchst Du i.d.R. keinen Zugriff weil die Kommunikation eh über PPPoE erfolgt.

lks

PS: Der oben von @MirkoKR und mir vorgeschlagene Adressraumwechsel ist trotzdem die bessere Lösung.

Auf das Modem brauchst Du i.d.R. keinen Zugriff weil die Kommunikation eh über PPPoE erfolgt.

Ihm gings ja nur um die Machbarkeit und den parallelen Zugriff auf die Statusseite des Modems. Wenn man den Zugriff nicht dauerhaft braucht kann man die obigen Schritte in ein Mikrotik-Skript packen und bei Bedarf aktivieren wenn man Zugriff braucht.
Ansonsten tut's alternativ dazu ein Bridge-Interface mit zwei Ports, an einem hängt das Modem und am anderen ein PC mit ner IP aus dem 192.168.100.0er Modem Netz, und im Falle von Problemen hängt man sich an den einen Port der Bridge für den Zugriff aufs Modem. Das wäre die "Turnschuh-Variante", geht aber wie man sieht auch direkt mit einem passenden Regelwerk.

Zitat von @BiberMan:

Auf das Modem brauchst Du i.d.R. keinen Zugriff weil die Kommunikation eh über PPPoE erfolgt.

Dann halt anders:

Dem Mikrotik eine andere IP-Adresse verpassen, z.B. 192.168.100.254/24. Sollte in einem ordentlich designten Netz kein Problem sein, das default gateway einfach zu ändern.
LAN- und WAN-Interface bridgen.
firewallregel definieren, daß nur die Antworten vom Modem auf Verbindungen vom Land durch die Bridge dürfen und auch Verbindungen von innen nur auf das Modem dürfen.

lks

Ceterum censeo ~~carthago esse delendam~~ ordentliche IP-adressplanung und Änderung ist die bessere Lösung.

Ja das wäre eine weitere Möglichkeit das Modem in sein LAN zu holen, mit all seinen Risiken.
Hier aber noch für den TO ein getestetes und lauffähiges Beispiel ohne jegliche Anpassungen der bereits bestehenden IPs was man auch für andere Zwecke nutzen kann wenn man mehrere gleiche Netze an ein und den selben Router angebunden hat:

Zugriff auf das Modem dann über die virtuelle IP 10.15.0.1, und das Interface an dem das Modem hängt ist hier im Beispiel ether1.

# IP-Adresse auf das Interface zum Modem hinzufügen
/ip address
add address=192.168.100.2/30 interface=ether1

# neue Routing-Tabelle anlegen
/routing table
add disabled=no fib name=to-modem

# Route zur neuen Tabelle hinzufügen
/ip route
add dst-address=192.168.100.0/30 gateway=ether1 routing-table=to-modem

# mittels mangle rule den Traffic zur virtuellen IP aus dem LAN das neue Routing-Tag hinzufügen
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=10.15.0.1 new-routing-mark=to-modem

# via dst-nat die Ziel-IP auf das des Modems umschreiben und die Quell-Adresse per src-nat auf die IP des Mikrotik im Modem Netz
/ip firewall nat
add action=dst-nat chain=dstnat routing-mark=to-modem to-addresses=192.168.100.1
add action=src-nat chain=srcnat dst-address=192.168.100.1 routing-mark=to-modem to-addresses=192.168.100.2

Und schon klappt der Zugriff auch ohne weitere Änderungen

.

Viel Spaß damit und Frohe Ostern.

Zitat von @BiberMan:

Ja das ist eine weitere Möglichkeit das Modem in sein LAN zu holen.

Hier aber noch für den TO ein getestetes und lauffähiges Beispiel ohne jegliche Anpassungen der bereits bestehenden IPs:

...

Und schon klappt der Zugriff auch ohne weitere Änderungen

Wo bleibt da der Lerneffekt, wenn der TO nicht wenigstens selbst noch ein wenig Hand anlegen muß.

Frohe Osterfeiertage

lks

Auch von Rezepten kann man lernen wenn man gewillt ist und anhand dieser etwas dazu lernen möchte, alles ne Sache der Einstellung.

Zitat von @BiberMan:

Auch von Rezepten kann man lernen wenn man gewillt ist und anhand dieser etwas dazu lernen möchte, alles ne Sache der Einstellung.

Du hast aber schon den fertigen Kuchen hingestellt.

Bei Rezepten hat man hingegen Variationsspielraum und oft auch die Möglichkeit zu scheitern.

lks

PS: Ich finde es trotzdem nett von Dir, dem TO die Lösung direkt zu liefern.

das Modem in sein LAN zu holen, mit all seinen Risiken.

Oder auf den Modem Firlefanz ganz zu verzichten und einen Telekom Glasfaser SFP direkt in den Mikrotik Router stecken was die sinnigste Option wäre. So stellt sich das "Problem" der IP Adressierung gar nicht erst.

https://www.heise.de/select/ct/2024/14/2412816201192219089

Hallo,

Dankeschön für die Vorschläge / Anregungen.
Ja, das Netzwerk einfach umstellen wäre quasi die "Kapitulation" vor dem Problem.
Genauso wie der schlichte Verzicht auf das WebIF von dem Modem.

Und zum Thema "fertiger Kuchen", super schmeckt gut!
Da aber das Rezept bei diesem Kuchen dabei ist, kann man den auch leicht selber backen und auch verstehen wie der Teig gemischt wurde.
Ich hatte schon den fast gleichen Kuchen gebacken, um bei der Analogie zu bleiben

Nur ein bisschen anders "gewürzt", tatsächlich war der einzige Unterschied bei der Erstellung der virtuellen IP-Adresse.
Deswegen auch der Titel "Kreative" Tricks....

Es gibt übrigens Gründe warum ich kein Modul in den SFP+ Port meines Mikrotiks gesteckt habe.

1. Die SFP-Module brauchen viel Strom(zumindest die, die man bei der Telekom nutzen kann) und heizen den Mikrotik um den SFP-Port stark auf. Das externe ONT-Modem braucht tatsächlich auch weniger Strom und das trotz dem Betrieb des Ethernet Ports. Bei einem Gerät welches 24/7 eingeschaltet ist, spielt auch "ein bisschen" mehr / weniger Strom eine Rolle.

2.Gibt es mal Probleme mit dem Glasanschluss, ist es idR einfacher mit der Hotline für die Fehlersuche, wenn ein "original" Modem vom Provider am Glas dran hängt ("Routerbindung" hin oder her)

Nebenbei haben auch diese SFP-Module ein eigenes WebIF und auch SSH-Zugänge, diese erreicht man natürlich nur wenn man "IP" neben PPPoE-Protokoll mit auf den SFP-Port gibt. Also genau das Gleiche wie mit einem externen Modem.

Zitat von @150412:

Hallo,

Dankeschön für die Vorschläge / Anregungen.
Ja, das Netzwerk einfach umstellen wäre quasi die "Kapitulation" vor dem Problem.

Das ist keine Kapitulation, sondern die richtige Lösung des Problems. Genauso, wie das Modem durch ein SFP-Modul zu ersetzen.

Alles andere ist nur eine Krücke, die Dir irgendwann mal auf die Füße fällt. Und Probleme verursacht. Meistens in einem Moment, in dem man das gar nicht gebrauchen kann.

lks

PS: Ich habe schon oft bei Kunden irgendwelche Krücken nehmen müssen, weil der Kunde partout dagegen war, die richtige Lôsung zu wählen.. Daher weiß ich, von ich rede.

Ich sehe das persönlich nicht als "Krücke". Mikrotik Router kommen nicht selten in Szenarien zum Einsatz bei denen verschiedene Kundennetze unabhängig voneinander geroutet werden müssen, und da ist es keine Seltenheit wenn an ein und dem selben Router mehrfach gleiche oder überschneidende Subnetze anliegen, das lässt sich meist gar nicht vermeiden (Stichwort VRF). Dafür sind die Dinger extra ausgelegt. Habe ich täglich mit zu tun, und du kannst dem Kunden in dem Business ja nicht einfach mal vorschreiben "wechsle doch bitte dein Subnetz".
So lange man alles ordentlich Dokumentiert und mit Kommentaren versieht was man treibt sehe ich da kein Problem. Die o. genutzten Funktionen des Routers sind ja Brot und Butter eines Routers also ehrlich gesagt nichts besonderes.

Die Welt ist bunt, und viele Wege führen zum Ziel 😉🖖

Na ja das (Zyxel)SFP-Modul hat ein WebIF und das Telekom Modem hat ein WebIF, was jetzt da sicherer oder unsicherer davon, ist will ich nicht entscheiden.

Das SFP-Modul ZYXEL PMG3000-D20B hat z.B.
die Adresse 10.10.1.1(per Default), hat ein WebIF und einen Telnet / SSH Zugang.
Im Normalbetrieb "schmort" das Ding mit 59 Grad im Mikrotik vor sich hin.
Jeder der einmal so ein SFP-Modul das kurz vorher in Betrieb war, weiß das man hier mit den Fingerchen aufpassen muss

Außerdem ist ja dieser Zugang auch noch mit der Seriennummer vom Modem oder SFP-Modul "verheiratet".
Da ich aber auch mal immer wieder Änderungen am Netzwerk / Geräten teste und damit den PPPoE Client wechsle, ist das externe Modem derzeit einfach die bessere Wahl, denn diesem ist es egal welcher PPPoE-Client am Kupferethernet hängt

Im Normalbetrieb "schmort" das Ding mit 59 Grad im Mikrotik vor sich hin.

Ist hier de facto NICHT nachzuvollziehen. Hier läuft es in diversen Cisco 896er und 1100er Router, OPNsense und Mikrotik RB2011ern und es wird nicht einmal handwarm wie jede andere SFP Optik auch. Asbest Handschuhe wie du es behauptest sind völlig übertrieben zumal der Großteil des SFPs inklusive der Kühloberfläche, im Gegensatz zu LAN Optiken, außerhalb des Gehäuses liegt. Es ist aber richtig das die Abwärme letztlich vom thermischen Design eines Gehäuses anhängt.

Außerdem ist ja dieser Zugang auch noch mit der Seriennummer vom Modem oder SFP-Modul "verheiratet".

Na ja...3 Mausklicks im Serviceportal des Providers. Eine eher schwache Argumentation. Pros und Cons halten sich, wie immer, die Waage. Es ist wohl eher persönliche Geschmackssache...

Na ja,
59 Grad ist für den einen "nichts" und eben für den andern zu warm....du harter Hund

Ich empfinde das als "heiß", für dich ist das anscheinend Pillepalle....

Mal sehen, gerade mal nachgekuckt.....bei einem anderen MT bei dem mir das egal ist und auch der Stromverbrauch..... und ja dieser hängt sogar "frei" ist also nicht in einem IT-Schrank.

immer noch knapp 60.....schon steil für "nicht mal handwarm"

und ja wenn ich den PPPoE Client wechsle will ich eben nicht diese 3 Klicks machen

Aber du hast da vollkommen recht, ganz jeder wie er mag.

Da das urspr. Problem gelöst ist, denke ich sollte man diesen Thread endgültig beenden, ergibt ja keinen Sinn mehr hier soweit OT weiter zu machen.

Viele Grüße....
(Last Post)

Ergänzung zum last Post (quasi extra für dich die Finger "verbrannt")
SFP-ModulAUßENtemperatur UNMITTELBAR nach dem Herausnehmen 52 Grad (gemessen mit einem Laserthermometer). Also gibt es ein kleines Delta von Diode zu Gehäuse.
Nicht vergessen sehr kleine Masse, daher sehr schnelle Abkühlung nach herausnehmen.

Auf jeden Fall nicht nur "handwarm", sondern relativ heiß, ist auch logisch bei den beengten Platzverhältnissen.

Egal wie viele Argumente da noch kommen, die Zyxel welche z.B. für die Glas-Telekom passen, werden sehr warm, da kann keine Argumentkette der Welt was daran ändern außer es findet eine (aktive)Kühlung statt (z.B. per Lüfter)
Ist aber bei Komponenten mit nur 1 / 2 Plätzen eher unüblich.
Case nun endgültig closed

Cisco#show int gig 0/0/0 transceiver
The Transceiver in slot 0 subslot 0 port 0 is enabled.
  Module temperature            = +45.847 C [Range: not specified]
  Transceiver Tx supply voltage = 3300.0 mVolts [Range: 3100.0 to 3500.0 mVolts]
  Transceiver Tx bias current   = 13660 uAmps [Range: 3000 to 70000 uAmps]
  Transceiver Tx power          =  3.0 dBm [Range:  0.5 to  4.5 dBm]
  Transceiver Rx optical power  = <-40 dBm [Range: -27.0 to -8.0 dBm]ITU Channel
Transceiver is internally calibrated. 

Und das ist die Temperatur der Messdiode direkt auf der internen SFP Platine. Das die natürlich wenig bis gar nichts mit der SFP Gehäuse Temperatur zu tun hat ist auch klar, da sie natürlich von der Thermik des Gehäuses und Umgebungstemperatur abhängt. Deshalb eben nichtmal handwarm...

Case closed!

gelöstFrage MikroTik

Heiß diskutiert