Zyxel USG60W - DHCP Problem mit Regel
Servus zusammen,
ich habe gestern das erste Mal eine Zyxel USG60W in Betrieb genommen. An einem Glasfaseranschluss der dt. Glasfaser.
Das Problem ist, ich muss an Wan1 oder Wan2 per DHCP eine IP von deren NT beziehen. Feste IP funktioniert nicht. Warum auch immer.
Dies ist an den Firewallregeln gescheitert. Der DHCP-Req ging raus, aber den Reply hat er geblockt.
Nun habe ich eine Regel erstellt, dass Any auf die Zyxel erlaubt ist, damit das Internet dort funktioniert.
Aber wohl fühle ich mich nicht dabei.
Wenn ich PPPOE nutze, dann hat die Box kein Problem sich dort eine IP zu holen. Auch ohne weitere Regel.
Wie löse ich das am schnellsten ?
Einzige Idee:
Als Source deren DHCP-Server freigeben - Ich traue den Brüdern von der dt. Glasfaser nicht, wenn die DHCP-Server-IP sich ändert, dann ist Internet dunkel.
Wie habt ihr das gelöst ? Oder besser, wie kann ich das lösen ?
Grüße, Henere
ich habe gestern das erste Mal eine Zyxel USG60W in Betrieb genommen. An einem Glasfaseranschluss der dt. Glasfaser.
Das Problem ist, ich muss an Wan1 oder Wan2 per DHCP eine IP von deren NT beziehen. Feste IP funktioniert nicht. Warum auch immer.
Dies ist an den Firewallregeln gescheitert. Der DHCP-Req ging raus, aber den Reply hat er geblockt.
Nun habe ich eine Regel erstellt, dass Any auf die Zyxel erlaubt ist, damit das Internet dort funktioniert.
Aber wohl fühle ich mich nicht dabei.
Wenn ich PPPOE nutze, dann hat die Box kein Problem sich dort eine IP zu holen. Auch ohne weitere Regel.
Wie löse ich das am schnellsten ?
Einzige Idee:
Als Source deren DHCP-Server freigeben - Ich traue den Brüdern von der dt. Glasfaser nicht, wenn die DHCP-Server-IP sich ändert, dann ist Internet dunkel.
Wie habt ihr das gelöst ? Oder besser, wie kann ich das lösen ?
Grüße, Henere
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 361033
Url: https://administrator.de/forum/zyxel-usg60w-dhcp-problem-mit-regel-361033.html
Ausgedruckt am: 23.04.2025 um 15:04 Uhr
7 Kommentare
Neuester Kommentar
Mir wurde von meinem "Trainer" abgeraten den Assi zu benutzen.
Hat er auch nicht ganz Unrecht, denn die konfigurieren oft automatisierten (DAU) Blödsinn den man keinesfalls haben will ! (Sicherheit !)Der DHCP-Req ging raus, aber den Reply hat er geblockt.
Vermutlich hast du die falsche Firewall Regel am WAN Port konfiguriert !! Dort wird in Regel im Default ALLES inbound blockiert !Die Firewall sendet am WAN Port wenn sie dort als DHCP Client definiert ist einen DHCP Request mit UDP-Quellport 68 und UDP-Zielport 67 als All Net Broadcast raus (Zieladresse 255.255.255.255, Absender IP 0.0.0.0). Dann antwortet der Provider Server mit einem DHCP Offer mit UDP-Quellport 67 und UDP-Zielport 68 entweder auch als Broadcast oder als Unicast auf die Mac Adresse.
Wenn du am WAN Port dann keine gültige Inbound Firewall Regel konfiguriert hast die any any mit UDP Zielport 68 auf das WAN Interface erlaubt bleiben die DHCP Pakete des Providers logischerweise an der Firewall hängen. Sie macht also genau das was sie soll.
Siehe auch hier:
Cisco 800, 900, ISR1100 Router Konfiguration mit xDSL, Kabel, FTTH Anschluss und VPN
Mit der richtigen Firewall Regel die DHCP Offers passieren lässt sollte das sofort klappen !
Tot ist die Büchse.....
pfSense Firewall beschaffen, damit passiert sowas nicht Zitat von @Henere:
Schön wäre es ja, wenn man ein WAN-IF auf DHCP stellt, dass er die Regel gleich mit anlegt. Aber man kann nicht alles haben.
Schön wäre es ja, wenn man ein WAN-IF auf DHCP stellt, dass er die Regel gleich mit anlegt. Aber man kann nicht alles haben.
Es wird aber keine statische Regel benötigt, denn das erledigt das Connection-Tracking! Letzteres sorgt dafür, dass Traffic zur Zywall, welcher lediglich eine Antwort auf solchen Traffic darstellt, der von der Zywall selbst initiiert wurde, dynamisch zugelassen wird. Bei UDP muss die Zywall hierfür natürlich ein paar Tricks und Annahmen anwenden, denn anders als bei TCP gibt es ja bei UDP bezogen auf diesen Layer eigentlich keinen Verbindungsstatus.
Wenn eine statische Regel in Deinem Einsatzszenario das Problem reproduzierbar behebt (was ich noch nicht glaube - mach mal die Gegenprobe), dann ist etwas faul!
Entweder hat sich in der von Dir verwendeten Firmware-Version ein Bug eingeschlichen oder es liegen hier atypische Bedingungen vor, welche dazu führen, dass die Antwort(en) des/der DHCP-Server nicht der Anfrage durch die Zywall zugeordnet werden können. Denkbar wäre etwa, dass die Antworten so verzögert kommen, dass das konfigurierte UDP-Connectiontimeout überschritten wird.
Mach also bitte mal einen Gegentest und wenn das Problem und der Lösungsweg reproduzierbar sind, dann bitte einen Trafficmitschnitt zwecks genauer Analyse (Menüpunkt Capture unter Maintenance).
Gruß
sk