
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
30.07.2018 15:17 - bearbeitet 30.07.2018 15:37
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...
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
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
am 30.07.2018 15:47

- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
30.07.2018 15:49 - bearbeitet 30.07.2018 15:57
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ß
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
am 31.07.2018 20:29
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
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
am 31.07.2018 21:25

- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
am 01.08.2018 08:57
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ß
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
01.08.2018 20:14 - bearbeitet 01.08.2018 20:16
@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.

- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
02.08.2018 12:29 - bearbeitet 02.08.2018 12:37
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...

- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
am 08.03.2019 15:29
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

- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
am 09.03.2020 10:28
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
