7
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 361033
Url: https://administrator.de/contentid/361033
Printed on: April 25, 2024 at 01:04 o'clock
7 Comments
Latest comment
Moin Henere,
bei der USG 60W kannst Du doch den Einrichtungsassi laufen lassen, der die Verbindung zum WAN herstellt. Wenn Du dort DHCP auswählst, könnte es klappen.
Gruß
Uwe
bei der USG 60W kannst Du doch den Einrichtungsassi laufen lassen, der die Verbindung zum WAN herstellt. Wenn Du dort DHCP auswählst, könnte es klappen.
Gruß
Uwe
Mir wurde von meinem "Trainer" abgeraten den Assi zu benutzen. Daher habe ich darauf verzichtet.
Nun steht das Ding 220km weiter, ich komme nur per Umwege von hinten (VPN noch über alte 2MBit/s Leitung) an die Büchse dran.
Wenn ich die mit dem Assi jetzt abschiesse, habe ich ein Problem.
Das ist so ähnlich, wenn wenn man die FW 4.30 aufspielt, und als Standby noch die 4.11 läuft. Wenn man dann die Standby von 4.11 (Auslieferungszustand) auf 4.20 anhebt, dann bootet er neu mit der Standny-FW und will die 4.30er Cond lesen...... Tot ist die Büchse.....
Nun steht das Ding 220km weiter, ich komme nur per Umwege von hinten (VPN noch über alte 2MBit/s Leitung) an die Büchse dran.
Wenn ich die mit dem Assi jetzt abschiesse, habe ich ein Problem.
Das ist so ähnlich, wenn wenn man die FW 4.30 aufspielt, und als Standby noch die 4.11 läuft. Wenn man dann die Standby von 4.11 (Auslieferungszustand) auf 4.20 anhebt, dann bootet er neu mit der Standny-FW und will die 4.30er Cond lesen...... Tot ist die Büchse.....
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 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
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 
Danke Dir. Die Auswahl der Hardware lag nicht an mir. Muss das nehmen was da ist.
Ich komme ja aus der Checkpoint-Welt, muss mich mit dem Zyxel ein wenig umgewöhnen.
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.
Ich habe jetzt mal angelegt:
So sollte ich mich trauen können, die Büchse zu rebooten ?
Grüße, Henere
Ich komme ja aus der Checkpoint-Welt, muss mich mit dem Zyxel ein wenig umgewöhnen.
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.
Ich habe jetzt mal angelegt:
So sollte ich mich trauen können, die Büchse zu rebooten ?
Grüße, Henere
Sie hat den Reboot überlebt und ist wieder erreichbar. Danke für die Hilfe, hätte ich eigentlich selbst drauf kommen können SIC!
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
1
Servus, die Gegenprobe hatte ich ja. Bis zum einfügen dieser Regel hat die USG nachweislich keine IP bekommen. Erst wenn die Regel aktiv war, bekam sie auf Wan1 die IP zugewiesen.
Es ist die 4.30(AAKZ.0) 2017-11-28 06:20:56
Wenn das Problem in der FW wäre, hätte das nicht mittlerweile seit November jemandem auffallen müssen ? Bin ja wohl nicht der einzige der die USG als DHCP-Client betreibt.
Ich weiß auch nicht, was die deutsche Glasfaser da treibt, denn wenn ich die IP static eingebe, dann bekomme ich auch keine Verbindung. IP, Mask und GW kann ich ja auslesen, nach der Zuweisung.
Im Moment funktioniert es ja so. Ich kann das remote nicht nachvollziehen, denn dann komme ich nicht mehr dran. Das kann ich wenn dann nur vor Ort machen. Aber ich denke aus security-Gründen kann UDP68 auf die USG nicht wirklich Schaden anrichten. Auch wenn es von any kommt. Oder Denkfehler ?
Grüße, Henere
Es ist die 4.30(AAKZ.0) 2017-11-28 06:20:56
Wenn das Problem in der FW wäre, hätte das nicht mittlerweile seit November jemandem auffallen müssen ? Bin ja wohl nicht der einzige der die USG als DHCP-Client betreibt.
Ich weiß auch nicht, was die deutsche Glasfaser da treibt, denn wenn ich die IP static eingebe, dann bekomme ich auch keine Verbindung. IP, Mask und GW kann ich ja auslesen, nach der Zuweisung.
Im Moment funktioniert es ja so. Ich kann das remote nicht nachvollziehen, denn dann komme ich nicht mehr dran. Das kann ich wenn dann nur vor Ort machen. Aber ich denke aus security-Gründen kann UDP68 auf die USG nicht wirklich Schaden anrichten. Auch wenn es von any kommt. Oder Denkfehler ?
Grüße, Henere
