abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du 
Aktuelle Eilmeldungen

TV: Kabelfernsehen wird Mietersache. Jetzt handeln!
Deine Störung ist nicht dabei? Dann nutz unseren Störungsfinder!

1

Frage

2

Antwort

3

Lösung

Problem mit Bridge Mode Hitron CVE-30360 / Keine public IP per DHCP
Uelfe
Netzwerkforscher
Netzwerkforscher

Hallo,

 

wir haben seit dem 19.07. ca. 02:20 Uhr Probleme mit dem oben genannten Modem im Bridge Modus. Zunächst war die Internetverbindung am 19.07. um 2:20 Uhr weg und konnte erst durch ein Neustart des Modems wiederhergestellt werden (ca. 19.07. 06.28 Uhr). Danach lief es bis zum 20.07. 2:28 Uhr wieder...Danach war die Verbindung permanent nicht verfügbar. Auch ein Neustart des Modems hat hier nicht geholfen. Wir haben seit diesem Zeitpunkt KEINE Internetverbindung über den Bridgemode mehr!

 

Für mich sieht es auf Grund der Zeitpunkte stark danach aus, als wenn hier von Vodafone/Kabel Deutschland geplante Änderungen durchgeführt wurden...Die Hotline gibt hierzu keine Auskunft...

 

 naemon_internet_19.07.PNG

 

Stellen wir auf den normalen Modus um funktioniert alles wie es soll. Dies ist allerdingt keine Option für uns, da wir auf den Bridgemodus angewiesen sind (Vermeidung von double NAT, eigene Firewall, etc. pp.). 

 

Es war heute bereits ein Techniker von Cableway bei uns vor Ort und hat die Kabelleitung überprüft, welcher angeblich eine defekte Muffe im Kabelweg diagnostiziert hat...Die Verbindung funktioniert jedoch ohne bridge mode einwandfrei.

 

Wäre es möglich mit kompetenten Personen im 2nd- bzw. 3rd-level Support zu sprechen? An der Hotline werden wir direkt wieder abgespeist mit z.B. "im normalen Modus funktioniert es doch...Problem gelöst!". Kundenservice mangelhaft!

 

 

Hier noch ein Auszug aus dem DHCP-Client der Firewall (OPNsense 18.1.13😞

 

Bridge mode (keine Antwort vom DHCP Server!):

Jul 30 11:52:56	dhclient: TIMEOUT
Jul 30 11:52:56	dhclient[48077]: No DHCPOFFERS received.
Jul 30 11:52:55	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 1
Jul 30 11:52:37	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 17
Jul 30 11:52:28	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 9
Jul 30 11:52:11	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 17
Jul 30 11:52:05	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 6
Jul 30 11:52:00	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 5
Jul 30 11:51:58	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 2
Jul 30 11:51:57	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 1
Jul 30 11:51:55	dhclient[48077]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 1
Jul 30 11:51:44	dhclient[48077]: DHCPREQUEST on vmx0 to 255.255.255.255 port 67

Ohne Bridge Mode (Antwort vom DHCP Server):

Jul 30 14:14:39	dhclient[71493]: bound to 192.168.0.10 -- renewal in 157680000 seconds.
Jul 30 14:14:39	dhclient: Creating resolv.conf
Jul 30 14:14:39	dhclient: RENEW
Jul 30 14:14:39	dhclient[71493]: DHCPACK from 192.168.0.1
Jul 30 14:14:39	dhclient[71493]: DHCPREQUEST on vmx0 to 192.168.0.1 port 67
Jul 30 14:14:39	dhclient[41619]: bound to 192.168.0.10 -- renewal in 30 seconds.
Jul 30 14:14:08	dhclient: Creating resolv.conf
Jul 30 14:14:08	dhclient: /sbin/route add default 192.168.0.1
Jul 30 14:14:08	dhclient: Adding new routes to interface: vmx0
Jul 30 14:14:08	dhclient: New Routers (vmx0): 192.168.0.1
Jul 30 14:14:08	dhclient: New Broadcast Address (vmx0): 192.168.0.255
Jul 30 14:14:08	dhclient: New Subnet Mask (vmx0): 255.255.255.0
Jul 30 14:14:08	dhclient: New IP Address (vmx0): 192.168.0.10
Jul 30 14:14:08	dhclient: ifconfig vmx0 inet 192.168.0.10 netmask 255.255.255.0 broadcast 192.168.0.255
Jul 30 14:14:08	dhclient: Starting add_new_address()
Jul 30 14:14:08	dhclient: BOUND
Jul 30 14:14:08	dhclient[41619]: DHCPACK from 192.168.0.1
Jul 30 14:14:08	dhclient[41619]: DHCPREQUEST on vmx0 to 255.255.255.255 port 67
Jul 30 14:14:08	dhclient: ARPCHECK
Jul 30 14:14:06	dhclient: ARPSEND
Jul 30 14:14:06	dhclient[41619]: DHCPOFFER from 192.168.0.1
Jul 30 14:14:04	dhclient[41619]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 9
Jul 30 14:13:57	dhclient[41619]: DHCPDISCOVER on vmx0 to 255.255.255.255 port 67 interval 7

Danke und Gruß

Uelfe

9 Antworten 9
meister_voda
App-Professor
App-Professor
Kann es sein, dass du bei OPNsense eine andere MAC-Adresse verwendest, als die der Netzwerkkarte selbst? Nutzt der OPNsense Router evtl. eine andere MAC-Adresse beim Booten?

Hallo,

 

nein die MAC-Adresse ist von VMware statisch vergeben. Es handelt sich um einen VMXnet3 Adapter. Diese Konstellation läuft so schon seit über 2 Jahren problemlos (in mehreren Haushalten).

 

EDIT: Das WAN-Interface ist selbstverständlich in einem eigenen, isolierten VLAN. In diesem VLAN befinden sich nur das WAN Interface von OPNsense und ein Interface des Hitron Modems. An dem Modem ist sonst nichts weiteres angeschlossen.

 

 

Gruß

ERFD
Ex-Moderator:in
Ex-Moderator:in

Hallo Uelfe,

 

danke für Deine ausführliche Beschreibung. Kannst Du mir bitte Deine Kundennummer und Anschrift per Privatnachricht zuschicken? Ich schaue mir das Modem gern an. Hast Du es mit einem einzelnen Client im BridgeMode versucht?

 

Gruß Fred

Bewertet hilfreiche Beiträge mit Likes und Sternen!
Hast mal probiert das Modem mit dem WAN Interface für OPNsense mit einer direkten physikalischen Verbindung anzuschließen; also kein VLAN, sondern direktes Kabel?

Hallo,

 

das werde ich am Wochenende mal probieren. Da jedoch der normale Modus einwandfrei funktioniert und das Prinzip das gleiche ist (IP kommt in beiden fällen per DHCP), gehe ich nicht davon aus das sich was ändern wird. Die Verkabelung und auch die entsprechenden Switches habe ich bereits überprüft.

 

Was ich noch probieren kann ist, die MAC-Adresse des WAN Interfaces zu ändern. Evtl. hat Vodafone die MAC von meinem WAN Interface blockiert (warum auch immer)? Kann so etwas sein?

 

@ERFD: Ich habe dir eine PN geschickt.

 

 

Danke und Gruß


@Uelfe@  schrieb:

Hallo,

 

das werde ich am Wochenende mal probieren. Da jedoch der normale Modus einwandfrei funktioniert und das Prinzip das gleiche ist (IP kommt in beiden fällen per DHCP), gehe ich nicht davon aus das sich was ändern wird. Die Verkabelung und auch die entsprechenden Switches habe ich bereits überprüft.

 


Ich habe deinen Aufbau mal bei mir nachgestellt…

 

Dein konkretes Problem ist, dass das Modem im Bridge-Mode drei verschiedene MAC-Adressen erkennt.  Eine vom Interfaca am Switch, die zweite von der Netzwerkkarte und die dritte von der virtuellen Karte der OPNsense Appliance im EXSI.  Der DHCP Server von VFKD vergibt allerdings nur Adressen an die ersten beiden erkannten MAC-Adressen (CPE Limit <= 2).

 

Hier mein Lösungsvorschlag:  Du brauchst eine dezidierte physikalische Netzwerkkarte für OPNsense.  Diese muss dann auch per LAN Kabel direkt (kein VLAN über managed Switches) mit dem Modem verbunden werden.

 

So klappt das ganze dann auch.

 

***

 

Wenn das Modem im Router Mode läuft, dann gibt es diese Einschränkung nicht, so dass dann auch die Appliance ein IP-Adresse vom DHCP Server im Modem bekommt.

Hallo,

 

das kann ich so nicht unterschreiben.

 

Die NICs vom ESXi-Server, die NICs an den Switches und auch das VLAN selbst (auf beiden Seiten untagged) verhalten sich komplett transparent zum Modem und sind hier nicht relevant. Lediglich die (virtuelle) NIC von der virtuellen Maschine (OPNsense) ist im Netzwerk auf Layer 2 sichtbar. Von dieser NIC kommen auch die DHCP DISCOVER datagramme. Es ist die einzige Quelle von DHCP Nachrichten in diesem speziellen Netzwerk. Dies ist auch so per Wireshark über einen mirror port validierbar.

 

Wie gesagt, dieses Kontrukt läuft bei uns in der Familie so seit Jahren in mehreren Haushalten.

 

BTW.: die WAN NIC am ESXI-Host ist dediziert für das WAN...

Horst1234
Netzwerkforscher
Netzwerkforscher

Hallo,

 

gibt es in deinem Fall eine Lösung?
Haargenau das gleiche Szenario habe ich gerade. Erst lief alles im Bridgemode. Dann nur sporadisch und dann gar nicht mehr. Die Hotline konnte mir auch nicht helfen. (Wir haben die Serverseite neu gestartet. Meine Seite. Ein Techniker war hier.)

Gruß

Horst

Ich habe seit dem Deutschlandweiten Wochenendproblem vom 29.02.2020 das gleiche Problem. Auch ich hatte bisher das KDModem/Router im Bridge-Mode via VLAN über meinen TP-LINK Switch an meinem TP-Link Router. Nun kann der Router vom Modem keine puplic ip mehr beziehen. Nach vielen Stunden basteln half nur eine weitere DIREKTE Kabelverbindung. Zudem viel mir auf, dass ich während der gestörten Situation den Switch nicht konfigurieren konnte. Das Modem scheint den Switch regelrecht zu “Stormen“. Es reicht dann das Modem abzuschalten oder nur den Antennenverstärker abzuschalten und der Trafficsturm hört auf. Switch wieder ansprechbar. 

 

 

 

Hat es mittlerweile jemand geschafft, das Problem eleganter zu umgehen?

Mit freundlichen Grüßen

Hacky-sack