15
PfSense hinter Cisco 3212 Kabelmodem DHCP Problem - Unitymedia
ch schon wieder... mit der verteufelten PfSense Installation (siehe auch: PfSense Installationsproblem (Ping Timeouts LAN-Port) )
Die Box läuft im Augenblick fehlerfrei, der Kunde gewinnt langsam Vertrauen, dass er sein Geschäft auch mit der PfSense in Zukunft weiter betreiben kann...
wenn da nicht noch eine nervige Geschichte wäre:
Die Pf bezieht ihre WAN Adresse per DHCP vom Cisco 3212 Kabelmodem. Das klappt auch beim ersten Booten, wenn das Modem bereits connected ist. Wenn nun aber die ext. IP von Unitymedia neu vergeben wird z.B. weil das Modem neu gestartet wird, oder Unitymedia Lust hat, vor Ablauf der eigentlichen Leasedauer eine neue IP zu vergeben (was zwar blöd, aber ihr gutes Recht, wenn auch nicht üblich ist) bekommt die PfSense die neue ext. IP nicht auf den Schirm. (Öffentliche IP aus dem Unitymedia Range, nix privates wie teils schon verbreitet)
Wie ich im PfSense Forum nachlesen konnte, liegt es wohl daran, dass die Pf vor Ablauf der Leasedauer nicht auf die Idee kommt, nach einer neuen Adresse anzufragen, sondern das dann wohl erst nach einem Reboot macht. Nach Ablauf der Leasedauer soll es da keine Zickigkeiten geben, das konnte ich aufgrund der Intervalle aber noch nicht testen.
Ein Anruf bei der Unitymedia Business Hotline hat mich von Hinz zu Kunz verbunden, keiner konnte zu der Frage eine Auskunft geben und die Frage, ob man für diesen Business Vertrag nicht einfach eine feste IP bekommen könnte, führte zu dem Versprechen, dass mich jemand aus der "IP-Adress-Abteilung" zurückruft. Die waren Freitag 16:00 Uhr aber wohl schon alle bei ihren privaten Adressen eingeloggt und nicht mehr pingbar...
Weiterhin sehe ich in den Firewall Logs (Block private Networks ist angehakt) auf dem WAN Interface massenhaft DHCP Range Requests mit einer Source 10.x.x.x und einer Destination WAN Adress.
Z.B.: block Aug 1 23:08:04 Destination: WAN Source: 10.42.x.x :67 255.255.255.255:68 UDP
Das sieht für mich so aus, dass der (private) Host 10.42.x.x auf meiner WAN IP per DHCP eine Anfrage startet. Sollte das nicht umgekehrt sein???
Ist das im Kabelumfeld erwünschtes Verhalten? Ist das evtl. nur die Antwort auf eine nicht geloggte weil nicht geblockte Anfrage meinerseits???
Konnte dazu nichts finden, ausser einer Anleitung, wie man eine Rule erstellt, die diesen Alarm nicht ausgibt. Sollte man das zulassen? Könnte das einen Einfluss auf die Problematik haben? Kenne mich mit DHCP Interna zu wenig aus, um das beurteilen zu können.
Auf meinen (V-) DSL Installationen gibt es keine DHCP Requests in den Logs auf dem WAN Interface, das ist aber auch technisch was völlig anderes.
Wie gefährlich ist es eigentlich, private und "Bogon" Netzwerke auf dem WAN zuzulassen? Wie kommen die überhaupt bis dahin? Ich kann mir mit meinem gepflegten Halbwissen keine private IP-Adresse vorstellen, die durchs Internet bis auf meine WAN-IP geroutet wird. Bei "privaten" UMTS Sachen gehen ja Geschichten wie VPN etc. genau deswegen nicht oder nur auf Umwegen...?
Bitte macht mich schlauer.
Der Buco
Die Box läuft im Augenblick fehlerfrei, der Kunde gewinnt langsam Vertrauen, dass er sein Geschäft auch mit der PfSense in Zukunft weiter betreiben kann...
wenn da nicht noch eine nervige Geschichte wäre:Die Pf bezieht ihre WAN Adresse per DHCP vom Cisco 3212 Kabelmodem. Das klappt auch beim ersten Booten, wenn das Modem bereits connected ist. Wenn nun aber die ext. IP von Unitymedia neu vergeben wird z.B. weil das Modem neu gestartet wird, oder Unitymedia Lust hat, vor Ablauf der eigentlichen Leasedauer eine neue IP zu vergeben (was zwar blöd, aber ihr gutes Recht, wenn auch nicht üblich ist) bekommt die PfSense die neue ext. IP nicht auf den Schirm. (Öffentliche IP aus dem Unitymedia Range, nix privates wie teils schon verbreitet)
Wie ich im PfSense Forum nachlesen konnte, liegt es wohl daran, dass die Pf vor Ablauf der Leasedauer nicht auf die Idee kommt, nach einer neuen Adresse anzufragen, sondern das dann wohl erst nach einem Reboot macht. Nach Ablauf der Leasedauer soll es da keine Zickigkeiten geben, das konnte ich aufgrund der Intervalle aber noch nicht testen.
Ein Anruf bei der Unitymedia Business Hotline hat mich von Hinz zu Kunz verbunden, keiner konnte zu der Frage eine Auskunft geben und die Frage, ob man für diesen Business Vertrag nicht einfach eine feste IP bekommen könnte, führte zu dem Versprechen, dass mich jemand aus der "IP-Adress-Abteilung" zurückruft.
Die waren Freitag 16:00 Uhr aber wohl schon alle bei ihren privaten Adressen eingeloggt und nicht mehr pingbar...Weiterhin sehe ich in den Firewall Logs (Block private Networks ist angehakt) auf dem WAN Interface massenhaft DHCP Range Requests mit einer Source 10.x.x.x und einer Destination WAN Adress.
Z.B.: block Aug 1 23:08:04 Destination: WAN Source: 10.42.x.x :67 255.255.255.255:68 UDP
Das sieht für mich so aus, dass der (private) Host 10.42.x.x auf meiner WAN IP per DHCP eine Anfrage startet. Sollte das nicht umgekehrt sein???
Ist das im Kabelumfeld erwünschtes Verhalten? Ist das evtl. nur die Antwort auf eine nicht geloggte weil nicht geblockte Anfrage meinerseits???
Konnte dazu nichts finden, ausser einer Anleitung, wie man eine Rule erstellt, die diesen Alarm nicht ausgibt. Sollte man das zulassen? Könnte das einen Einfluss auf die Problematik haben? Kenne mich mit DHCP Interna zu wenig aus, um das beurteilen zu können.
Auf meinen (V-) DSL Installationen gibt es keine DHCP Requests in den Logs auf dem WAN Interface, das ist aber auch technisch was völlig anderes.
Wie gefährlich ist es eigentlich, private und "Bogon" Netzwerke auf dem WAN zuzulassen? Wie kommen die überhaupt bis dahin? Ich kann mir mit meinem gepflegten Halbwissen keine private IP-Adresse vorstellen, die durchs Internet bis auf meine WAN-IP geroutet wird. Bei "privaten" UMTS Sachen gehen ja Geschichten wie VPN etc. genau deswegen nicht oder nur auf Umwegen...?
Bitte macht mich schlauer.
Der Buco
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 245354
Url: https://administrator.de/forum/pfsense-hinter-cisco-3212-kabelmodem-dhcp-problem-unitymedia-245354.html
Ausgedruckt am: 03.04.2025 um 23:04 Uhr
15 Kommentare
Neuester Kommentar
Hallo,
um einen Router handelt denn ein Modem macht in der Regel kein DHCP!
Und wenn sich die pfSense ihre IP Adresse am WAN Port via DHCP holt
bzw. diese via DHCP zugeteilt bekommt denke ich eher, dass die Leasetime
dieser IP Adresse nicht lange genug läuft bzw. wenn die IP am WAN Port
wechselt es daher zu Problemen kommt.
weg und vergib dort eine statische also feste IP Adresse.
IP Vergabe und dort kommt es auch nicht zu Problemen, also schließe ich weiter auf
die via DHCP erteilte IP Adresse am WAN Port.
ist es eigentlich schon üblich.
nicht gewechselt hat?
Ich würde einfach am WAN Port der pfSense eine statische (feste) IP Adresse aus dem
IP Adressbereich des Cisco 3212 "Modems" vergeben, also eine IP außerhalb des DHCP
Pools des Cisco 3212 und dann sollte es auch keine Probleme mehr geben!
Gruß
Dobby
Die Pf bezieht ihre WAN Adresse per DHCP vom Cisco 3212 Kabelmodem.
Ich denke das man das zwar als "Modem" anbietet aber es sich in Wirklichkeitum einen Router handelt denn ein Modem macht in der Regel kein DHCP!
Und wenn sich die pfSense ihre IP Adresse am WAN Port via DHCP holt
bzw. diese via DHCP zugeteilt bekommt denke ich eher, dass die Leasetime
dieser IP Adresse nicht lange genug läuft bzw. wenn die IP am WAN Port
wechselt es daher zu Problemen kommt.
Das klappt auch beim ersten Booten, wenn das Modem bereits connected ist.
Lass doch einfach die DHCP Vergabe durch das Cisco 3212 "Modem"weg und vergib dort eine statische also feste IP Adresse.
Wenn nun aber die ext. IP von Unitymedia neu vergeben wird z.B. weil das Modem
neu gestartet wird, oder Unitymedia Lust hat, vor Ablauf der eigentlichen Leasedauer
Das passiert an was weiß ich nicht wie vielen Internetanschlüssen mit dynamischerneu gestartet wird, oder Unitymedia Lust hat, vor Ablauf der eigentlichen Leasedauer
IP Vergabe und dort kommt es auch nicht zu Problemen, also schließe ich weiter auf
die via DHCP erteilte IP Adresse am WAN Port.
eine neue IP zu vergeben (was zwar blöd, aber ihr gutes Recht, wenn auch nicht üblich ist)
Nun ja eventuell nicht für Unitymedia, aber für die allgemeinen privaten Internetanschlüsseist es eigentlich schon üblich.
bekommt die PfSense die neue ext. IP nicht auf den Schirm.
Und Du bist wirklich sicher das die IP am WAN Port der pfSensenicht gewechselt hat?
Ich würde einfach am WAN Port der pfSense eine statische (feste) IP Adresse aus dem
IP Adressbereich des Cisco 3212 "Modems" vergeben, also eine IP außerhalb des DHCP
Pools des Cisco 3212 und dann sollte es auch keine Probleme mehr geben!
Gruß
Dobby
Sorry Dobby, war schludrig formuliert. Natürlich geht es um die externe IP Adresse die von der PfSense durch das Modem vom Provider bezogen wird. Und wenn die wech ist, weil Modem aus z.B. erhält sie keine neue, sondern es steht am WAN Port 0.0.0.0 oder gar nix.
Da es bisher keine feste IP gibt, kann ich da natürlich auch keine eintragen.
Das ist also wirklich kein Router und keine Routerkaskaskade. Evtl. kann das Teil Router (das habe ich noch nicht recherchiert) und man könnte einfach alle Ports weiterleiten, das möchte ich aber aus anderen Gründen nur ungern.
Edit: Das ist definitiv ein reines Kabelmodem.
Klar passiert das Beziehen einer neuen IP bei Standard-DSL Anschlüssen täglich, die Einwahl wird da ja aber technisch vollkommen anders abgewickelt und ein DSL Modem kann ich an der PfSense nicht mit der Einstellung DHCP betreiben.
Hat jemand positive Erfahrungen mit der IP-Adressvergabe per DHCP am WAN Port mit Kabelmodem mit der PfSense? Das scheint doch mittlerweile häufiger im Einsatz zu sein und nicht immer zu solchen Problemen zu führen, sonst würde man im Netz mehr zum Thema finden...
Soweit,
Der Buc
Da es bisher keine feste IP gibt, kann ich da natürlich auch keine eintragen.
Das ist also wirklich kein Router und keine Routerkaskaskade. Evtl. kann das Teil Router (das habe ich noch nicht recherchiert) und man könnte einfach alle Ports weiterleiten, das möchte ich aber aus anderen Gründen nur ungern.
Edit: Das ist definitiv ein reines Kabelmodem.
Klar passiert das Beziehen einer neuen IP bei Standard-DSL Anschlüssen täglich, die Einwahl wird da ja aber technisch vollkommen anders abgewickelt und ein DSL Modem kann ich an der PfSense nicht mit der Einstellung DHCP betreiben.
Hat jemand positive Erfahrungen mit der IP-Adressvergabe per DHCP am WAN Port mit Kabelmodem mit der PfSense? Das scheint doch mittlerweile häufiger im Einsatz zu sein und nicht immer zu solchen Problemen zu führen, sonst würde man im Netz mehr zum Thema finden...
Soweit,
Der Buc
Moin,
ich habe hier einen Business Anschluss von UM mit fünf festen IP's. UM hat mir eine FB 6360 Cable zur Verfügung gestellt. Das Dingens fungiert als reines Modem und macht keinerlei DHCP oder ähnliches Gedöns. Ich habe von UM einen 5er Block an IP's bekommen, den ich manuell an die jeweiligen Endgeräte vergeben muss. Und das hat bis vor kurzem auch mit PfSense wunderbar funktioniert. Jetzt tut es bei mir eine ASA, aber auch damit klappt es problemlos.
Gruß
Uwe
ich habe hier einen Business Anschluss von UM mit fünf festen IP's. UM hat mir eine FB 6360 Cable zur Verfügung gestellt. Das Dingens fungiert als reines Modem und macht keinerlei DHCP oder ähnliches Gedöns. Ich habe von UM einen 5er Block an IP's bekommen, den ich manuell an die jeweiligen Endgeräte vergeben muss. Und das hat bis vor kurzem auch mit PfSense wunderbar funktioniert. Jetzt tut es bei mir eine ASA, aber auch damit klappt es problemlos.
Gruß
Uwe
Die pfSense arbeitet am Kabelmodem also am WAN Port immer als DHCP Client sofern denn dort DHCP Modus aktiviert ist, was immer den Client Modus meint an diesem Port !
Auf dem LAN Port hingegen fungiert sie als DHCP Server (auch nur sofern DHCP Server Mode aktiviert ist hier !), den du ja auch entsprechend so einrichtest wenn gewollt.
Da zwischen LAN und WAN Port geroutet wird kann niemals ein UDP DHCP Broadcast eines Clients vom LAN Port am WAN Port auftauchen. Das ist bei richtiger Konfiguration der FW technisch völlig unmöglich und passiert (nachweislich) auch nicht !
Bei einer Fehlkonfiguration ggf. mit Bridging am WAN usw. aber wäre das denkbar denkbar. Das wäre dann aber ein Fehler im Setup der Firewall und das du solch einen Unsinn machst unterstellen wir dir mal nicht ?!
Mit einem Wireshark am WAN Port solltest du dort nie und nimmer nicht DHCP Client Broadcasts vom lokalen LAN Netzwerk sehen !
Die DHCP Client Broadcasts des WAN Ports wo die pfSense als DHCP Client arbeitet allerdings schon.
Klar, denn sonst würde sie keine Provider IP bekommen wenn du nicht eine feste, statische IP hast vom Provider.
Bedenke auch das bei Kabel TV Netzen die letzte Meile IMMER ein shared medium ist das du dir mit zig hundert (oder tausend) anderen Teilnehmern teilen musst. Es ist also durchaus denkbar das du all die eingehenden DHCP Broadcasts dieser anderen Kabelkunden dort an der WAN Port Firewall siehst als geblockte Pakete ! Das wäre dann zu erwarten.
Klar, xDSL nutzt hier PPPoE, was ein völlig anderes Verfahren ist als DHCP. Das siehst du richtig !
Bist du dir denn ganz sicher das das Cisco 3212 Kabelmodem wirklich nur als reines Modem arbeitet und nicht als NAT Router ??
In der Statusübersicht der Interfaces welche IP Adresse siehst du dort am WAN Port der pfSense ??
Ist das eine private RFC 1918 IP oder bekommst du da was öffentliches vom Provider (was zu erwarten wäre...)
Auf dem LAN Port hingegen fungiert sie als DHCP Server (auch nur sofern DHCP Server Mode aktiviert ist hier !), den du ja auch entsprechend so einrichtest wenn gewollt.
Da zwischen LAN und WAN Port geroutet wird kann niemals ein UDP DHCP Broadcast eines Clients vom LAN Port am WAN Port auftauchen. Das ist bei richtiger Konfiguration der FW technisch völlig unmöglich und passiert (nachweislich) auch nicht !
Bei einer Fehlkonfiguration ggf. mit Bridging am WAN usw. aber wäre das denkbar denkbar. Das wäre dann aber ein Fehler im Setup der Firewall und das du solch einen Unsinn machst unterstellen wir dir mal nicht ?!
Mit einem Wireshark am WAN Port solltest du dort nie und nimmer nicht DHCP Client Broadcasts vom lokalen LAN Netzwerk sehen !
Die DHCP Client Broadcasts des WAN Ports wo die pfSense als DHCP Client arbeitet allerdings schon.
Klar, denn sonst würde sie keine Provider IP bekommen wenn du nicht eine feste, statische IP hast vom Provider.
Bedenke auch das bei Kabel TV Netzen die letzte Meile IMMER ein shared medium ist das du dir mit zig hundert (oder tausend) anderen Teilnehmern teilen musst. Es ist also durchaus denkbar das du all die eingehenden DHCP Broadcasts dieser anderen Kabelkunden dort an der WAN Port Firewall siehst als geblockte Pakete ! Das wäre dann zu erwarten.
Klar, xDSL nutzt hier PPPoE, was ein völlig anderes Verfahren ist als DHCP. Das siehst du richtig !
Bist du dir denn ganz sicher das das Cisco 3212 Kabelmodem wirklich nur als reines Modem arbeitet und nicht als NAT Router ??
In der Statusübersicht der Interfaces welche IP Adresse siehst du dort am WAN Port der pfSense ??
Ist das eine private RFC 1918 IP oder bekommst du da was öffentliches vom Provider (was zu erwarten wäre...)
Hallo aqui,
der TO schreibt doch: Unitymedia Business
da gibt es noch reine öffentliche IPv4-Adressen, das Modem ist auch wirklich nur ein Modem und kein Router. Das ist die einzige Variante, wie man da bei dem Verein noch ein dummes Modem und dazu IPv4 bekommt ;)
der TO schreibt doch: Unitymedia Business
da gibt es noch reine öffentliche IPv4-Adressen, das Modem ist auch wirklich nur ein Modem und kein Router. Das ist die einzige Variante, wie man da bei dem Verein noch ein dummes Modem und dazu IPv4 bekommt ;)
OK, dann sollte er also flglich eine öffentliche IP am pfSense Port sehen !
Was er aber de facto dort nicht sehen darf sind DHCP Client Requests aus dem lokalen LAN !
Was er aber de facto dort nicht sehen darf sind DHCP Client Requests aus dem lokalen LAN !
Nochmal zur Klarstellung: Ich bekomme am WAN Port DHCP Requests aus dem 10.x Netz von genau einem Client im Sekundentakt.
Das interne Netz ist aus einem völlig anderen Range (192.168.x.x) Deshalb hat mich das ja so irritiert.
Die letzte Meile und die Requests eines anderen Kunden sind soweit plausibel, warum der aber nicht mal eine Adresse bekommt und dann aufhört ist schon seltsam... Wenn das Problem unkritisch ist und nichts mit der Erneuerung meiner IP zu tun haben kann, schalte ich das Logging aus und Ruhe ist. (Oder ich ärgere die ein bisschen, indem ich mal DHCP Server spiele und die Requests mit einer netten IP beantworte Wenn man so penetrant gefragt wird, ist es ja schon beinahe unhöflich nicht zu reagieren.... Müsste man nur schauen, dass man den Client dann nicht im eigenen Netz rumwerkeln lässt. )
Das Cisco ist ein Modem. EIN MODEM. NUR EIN MODEM. Das gibts noch. Warum mag mir das keiner glauben? DANKE shadynet!
Am WAN interface sehe ich eine öffentliche IP, wenn ich eine sehe. Mache ich den Cisco aus und wieder an, sehe ich dort nichts, bis ich die PfSense neu starte. Dann sehe ich dort die erneuerte öffentliche IP.
Heute nacht hat er mal was in der Richtung geloggt: "Detected IP Adress Change" am WAN Port alte IP --> alte IP. Also keine Änderung. Die PfSense konfiguriert trotzdem das Routing neu, als hätte sich was geändert. Evtl. ist ja da der Lease abgelaufen und es wurde einfach dieselbe IP wieder zugeteilt. Immerhin: Kein Verbindungsabbruch, die Büchse ist erreichbar. Dazu meine ich aber bereits irgendwo was gelesen zu haben. Ist ja auch erstmal kein problematisches Verhalten. Jetzt würde ich nur noch gerne einmal sehen, dass eine geänderte IP ankommt und ich könnte beruhigt in Urlaub fahren.
Kann man in der PfSense irgendwo die Leasedauer für die am WAN erhaltenen Adressen auslesen?
Thx all!
El Buco
Das interne Netz ist aus einem völlig anderen Range (192.168.x.x) Deshalb hat mich das ja so irritiert.
Die letzte Meile und die Requests eines anderen Kunden sind soweit plausibel, warum der aber nicht mal eine Adresse bekommt und dann aufhört ist schon seltsam... Wenn das Problem unkritisch ist und nichts mit der Erneuerung meiner IP zu tun haben kann, schalte ich das Logging aus und Ruhe ist. (Oder ich ärgere die ein bisschen, indem ich mal DHCP Server spiele und die Requests mit einer netten IP beantworte Wenn man so penetrant gefragt wird, ist es ja schon beinahe unhöflich nicht zu reagieren.... Müsste man nur schauen, dass man den Client dann nicht im eigenen Netz rumwerkeln lässt.
)Das Cisco ist ein Modem. EIN MODEM. NUR EIN MODEM. Das gibts noch. Warum mag mir das keiner glauben? DANKE shadynet!
Am WAN interface sehe ich eine öffentliche IP, wenn ich eine sehe. Mache ich den Cisco aus und wieder an, sehe ich dort nichts, bis ich die PfSense neu starte. Dann sehe ich dort die erneuerte öffentliche IP.
Heute nacht hat er mal was in der Richtung geloggt: "Detected IP Adress Change" am WAN Port alte IP --> alte IP. Also keine Änderung. Die PfSense konfiguriert trotzdem das Routing neu, als hätte sich was geändert. Evtl. ist ja da der Lease abgelaufen und es wurde einfach dieselbe IP wieder zugeteilt. Immerhin: Kein Verbindungsabbruch, die Büchse ist erreichbar. Dazu meine ich aber bereits irgendwo was gelesen zu haben. Ist ja auch erstmal kein problematisches Verhalten. Jetzt würde ich nur noch gerne einmal sehen, dass eine geänderte IP ankommt und ich könnte beruhigt in Urlaub fahren.
Kann man in der PfSense irgendwo die Leasedauer für die am WAN erhaltenen Adressen auslesen?
Thx all!
El Buco
Ich bekomme am WAN Port DHCP Requests aus dem 10.x Netz von genau einem Client im Sekundentakt.
Und genau deshalb die Schlüsselfrage ob die auch ein 10er Netz (also ein RFC 1918 IP Netz !) vom Provider bekommst oder eben eine öffentliche IP....Der 10er DHCP Broadcast kommt dann dort von einem DAU rein der seine Endgeräte oder sein Router nicht richtig konfiguriert hat !!
DHCP ist bekanntermaßen Broadcast wird also an alle geflutet.
Wie gesagt zur Erinnerung: Bei Kabel TV Netzen die letzte Meile IMMER ein shared Medium ist das du dir mit zig hundert (oder tausend) anderen Teilnehmern teilen musst !
Da gehen dann eben Brodcast an alle ! Der gemeine User merkt das aber nicht da er ja keine so guten Diagnosemöglichkeiten wie du hat !
warum der aber nicht mal eine Adresse bekommt und dann aufhört ist schon seltsam...
Deshalb ja die Frage WAS der Provider dort generell vergibt ?? Öffentlich oder RFC 1918 ? Normal ist öffentlich wie du ja auch sagst das er das tut...Er schickt einen Request für ein dediziertes IP Netz. In der Regel hatte das Gerät was sowas macht mal eine solche Adresse. Wenn der Provider dort öffentliche IPs vergibt rennt dieser Request natürlich ins Leere mit einem Timeout. Wäre ja fatal sollte er einen Lease aus dem Bereich kommen sofern der Provider keine 10er Adressen vergibt.
Kann man in der PfSense irgendwo die Leasedauer für die am WAN erhaltenen Adressen auslesen?
Ja das geht aber nur über den Shell Zugriff wenn du dir die /etc/dhclient.conf ansiehst.Der 10er DHCP Broadcast kommt dann dort von einem DAU rein der seine Endgeräte oder sein Router nicht richtig konfiguriert hat !!
Naja, oder als renew von dem, der die IP schon hatte, es aber ein anderes Endgerät ist, als das was vorher am Modem dran war, und deswegen kein ACK von UM kommt ;) ja, leicht unwahrscheinlich, aber man weiß ja nie. Alternativ schiebt man das auf das dreckige TC7200-Routermodem, was der letzte Mist ist.Deshalb ja die Frage WAS der Provider dort generell vergibt ?? Öffentlich oder RFC 1918 ? Normal ist öffentlich wie du ja auch sagst das er das tut...
Er schickt einen Request für ein dediziertes IP Netz. In der Regel hatte das Gerät was sowas macht mal eine solche Adresse. Wenn der Provider dort öffentliche IPs vergibt rennt dieser Request natürlich ins Leere mit einem Timeout. Wäre ja fatal sollte er einen Lease aus dem Bereich kommen sofern der Provider keine 10er Adressen vergibt.
Er schickt einen Request für ein dediziertes IP Netz. In der Regel hatte das Gerät was sowas macht mal eine solche Adresse. Wenn der Provider dort öffentliche IPs vergibt rennt dieser Request natürlich ins Leere mit einem Timeout. Wäre ja fatal sollte er einen Lease aus dem Bereich kommen sofern der Provider keine 10er Adressen vergibt.
Jein, UM vergibt im Privatkundensegment 10er IPs, aber IPv6 öffentlich. Daher dieses geile Dual Stack lite. Schönes zentrales IPv4-NAT, wodurch kein VPN ins eigene Netz mehr geht. im Businesssegment gibts dann eben öffentliche IPv4.
UM ist eben eine Sache für sich.
Da im anderen verlinkten Thread auch steht, dass der TO das Netz 192.168.2.0/24, liegt hier auch keine Falschkonfig seiner Firewall vor
immerhin.
Hab das Logging für die priv. Ip's auf dem WAN erstmal abgestellt. Die 3 Pakte pro Sekunde sollten das Netz nicht lahmlegen.
@aqui Leider gibt es das File etc/dhclient.conf bei mir nicht? Kannste nochmal gucken ob das wirklich da liegen muss? 2.1.4 release
@shadynet Was heisst da "Immerhin"?
Solange das Modem läuft, scheint es keine Probleme zu geben. Keine Auffälligkeiten im Log. Mich irritiert halt nur nach wie vor, dass der Linksys wrt54gl keine Probleme mit einer Änderung der IP hatte, sondern die neue immer brav erkannt hat.
Das wird irgendwo an der PfSense liegen, ob sich das wohl abstellen lässt?
LG
Buco
@aqui Leider gibt es das File etc/dhclient.conf bei mir nicht? Kannste nochmal gucken ob das wirklich da liegen muss? 2.1.4 release
@shadynet Was heisst da "Immerhin"?
Solange das Modem läuft, scheint es keine Probleme zu geben. Keine Auffälligkeiten im Log. Mich irritiert halt nur nach wie vor, dass der Linksys wrt54gl keine Probleme mit einer Änderung der IP hatte, sondern die neue immer brav erkannt hat.
Das wird irgendwo an der PfSense liegen, ob sich das wohl abstellen lässt?
LG
Buco
@shadynet Was heisst da "Immerhin"? face-wink
Na, dass mit deiner FW zumindest in dem Bereich alles in Ordnung ist
gab da ja schon diverse Problemchen am AnfangAber kleiner Tipp: eine kostenlose feste IP ist bei Unitymedia drin. Die kannst du dir ja holen, das Interface dann auf "Static" umstellen und das Problem wäre gegessen. Sowas weiß man zum Glück, wenn man sich die letzten Tage häufig mit UM Business beschäftigt hat
Jein, UM vergibt im Privatkundensegment 10er IPs, aber IPv6 öffentlich. Daher dieses geile Dual Stack lite.
Igitt...DS-Lite mit Provider NAT ! Ein triftiger Grund von dem Provider fernzubleiben !OK, das erklärt dann die jede Menge 10er Broadcasts, passt aber dann nicht zu der Behauptung vom Kollegen Buccaneer das er behauptet an der WAN IP eine öffentliche Provider IP zu bekommen.
DAS würde ja dafür sprechen das an seinem Anschluss kein DS-Lite gemacht wird.... ?!?
Fragt sich nun also wer Recht hat ???
Also, wie ich ja schon geschrieben habe: bei Customer-Anschlüssen DSLite, bei Business IPv4 öffentlich. So läuft das bei UM. Deswegen erwäge ich für meine Richtfunkstrecke (lahmes Dorf-DSL nervt...) einen UM Business...........
Dann hat Kollege Buccaneer also folglich einen Business Anschluss wenn er uns hier die Wahrheit sagt
Da müsste doch dann so oder so ne feste IP möglich sein, weil üblich im Business Bereich und das ganze DHCP "Problem" wäre eh vom Tisch ?!
Da müsste doch dann so oder so ne feste IP möglich sein, weil üblich im Business Bereich und das ganze DHCP "Problem" wäre eh vom Tisch ?!
Wie ich bereits eingangs etwas launig beschrieb:
Ich warte also jetzt geduldig auf den Rückruf der IP-Adressierabteilung.
/ Sarkasmus an /
Evtl. haben die ja meine Telefonnummer verschlampt und die versuchen jetzt mich per DHCP zu kontaktiern...
/Sarkasmus aus/
@aqui Nicht die Wahrheit sagen? das würde ich mir gegenüber dem Herrn der Router und Firewall auf allen Protokollen niemals herausnehmen.
Buc
Ein Anruf bei der Unitymedia Business Hotline hat mich von Hinz zu Kunz verbunden, keiner konnte zu der Frage eine Auskunft geben > und die Frage, ob man für diesen Business Vertrag nicht einfach eine feste IP bekommen könnte, führte zu dem Versprechen, dass mich > jemand aus der "IP-Adress-Abteilung" zurückruft. face-wink Die waren Freitag 16:00 Uhr aber wohl schon alle bei ihren privaten Adressen > eingeloggt und nicht mehr pingbar...
Ich warte also jetzt geduldig auf den Rückruf der IP-Adressierabteilung.
/ Sarkasmus an /
Evtl. haben die ja meine Telefonnummer verschlampt und die versuchen jetzt mich per DHCP zu kontaktiern...
/Sarkasmus aus/
@aqui Nicht die Wahrheit sagen? das würde ich mir gegenüber dem Herrn der Router und Firewall auf allen Protokollen niemals herausnehmen.
Buc
