10
PC in DMZ erhält keine IP per DHCP (pfSense)
Guten Abend,
ich möchte mir eine DMZ einrichten und komme nicht weiter, bzw kann mir das aktuelle Problem nicht erklären.
In die DMZ sollen PCs von Bekannten/Freunden für Updates etc ohne diese jedes mal im eigenen LAN zu haben.
Hardware: APU 1D4 Board mit aktueller pfSense-Version (2.3 vom 11.04.2016)
Die pfSense hängt hinter einem Kabelmodem (WAN als DHCP konfiguriert) und es sind keine weiteren Router vorhanden.
Mein privates LAN läuft in 192.168.0.0/24, DMZ soll in 192.168.99.0/24 sein.
Problem: Laptop an DMZ-Port erhält keine IP per DHCP, mit manueller Vergabe funktioniert es wie gewünscht
Was ich bisher gemacht habe:
- Interface DMZ (OPT1) angelegt und aktiviert
- DHCP für DMZ aktiviert
- Firewall Regeln definiert
Selbst mit der Regel 1 erhält der Laptop keine IP per DHCP - getestet unter Win10, Win7 und Knoppix.
Später sollen nur die Regeln 2 und 4 aktiv sein, das sollte soweit korrekt sein, oder?
Im Test mit manuell vergebener IP greifen die Firewall Regeln 1a: ich komme von der DMZ nicht ins LAN, andersherum schon. Und die IP 8.8.8.8 wird geblockt.
Im DHCP-Log taucht kein Request aus dem DMZ-Bereich oder der entsprechende Laptop auf.
Im Firewall-Log wird der Laptop am DMZ-Port geblockt - obwohl Regel 1 alles zulassen sollte.
Die 169.254.29.124 ist die von Win10 automatisch konfigurierte IP.
Wo könnte der Fehler liegen, bzw an welcher Stelle habe ich etwas übersehen?
Viele Grüße
Shape.Shifter
ich möchte mir eine DMZ einrichten und komme nicht weiter, bzw kann mir das aktuelle Problem nicht erklären.
In die DMZ sollen PCs von Bekannten/Freunden für Updates etc ohne diese jedes mal im eigenen LAN zu haben.
Hardware: APU 1D4 Board mit aktueller pfSense-Version (2.3 vom 11.04.2016)
Die pfSense hängt hinter einem Kabelmodem (WAN als DHCP konfiguriert) und es sind keine weiteren Router vorhanden.
Mein privates LAN läuft in 192.168.0.0/24, DMZ soll in 192.168.99.0/24 sein.
Problem: Laptop an DMZ-Port erhält keine IP per DHCP, mit manueller Vergabe funktioniert es wie gewünscht
Was ich bisher gemacht habe:
- Interface DMZ (OPT1) angelegt und aktiviert
- DHCP für DMZ aktiviert
- Firewall Regeln definiert
Selbst mit der Regel 1 erhält der Laptop keine IP per DHCP - getestet unter Win10, Win7 und Knoppix.
Später sollen nur die Regeln 2 und 4 aktiv sein, das sollte soweit korrekt sein, oder?
Im Test mit manuell vergebener IP greifen die Firewall Regeln 1a: ich komme von der DMZ nicht ins LAN, andersherum schon. Und die IP 8.8.8.8 wird geblockt.
Im DHCP-Log taucht kein Request aus dem DMZ-Bereich oder der entsprechende Laptop auf.
Im Firewall-Log wird der Laptop am DMZ-Port geblockt - obwohl Regel 1 alles zulassen sollte.
Die 169.254.29.124 ist die von Win10 automatisch konfigurierte IP.
Wo könnte der Fehler liegen, bzw an welcher Stelle habe ich etwas übersehen?
Viele Grüße
Shape.Shifter
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 304726
Url: https://administrator.de/contentid/304726
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
hm, eigentlich schaut das alles korrekt aus.
Andere Interfaces funktionieren die du konfiguriert hast? LAN z.B.?
Hast du unter Services den DNS Forwarder aktiviert?
Gruß
hm, eigentlich schaut das alles korrekt aus.
Andere Interfaces funktionieren die du konfiguriert hast? LAN z.B.?
Hast du unter Services den DNS Forwarder aktiviert?
Gruß
In der Tat ist soweit alles richtig und der DHCP Server rennt de facto hier an einem identischen Vergleichssystem fehlerlos mit Win 10.
Bekommt der gleiche PC am LAN Port eine IP ?
Du solltest sonst mal unter Diagnostics den Packet Capture anschmeissen und sehen ob der Laptop überhaupt DHCP Requests sendet und die an der FW bzw. DMZ Port ankommen.
Ggf. tuts natürlich auch ein Wireshark auf dem Laptop.
Der fehlende DHCP Request ist schon komisch...der sollte eigentlich zu sehen sein?!
Bekommt der gleiche PC am LAN Port eine IP ?
Du solltest sonst mal unter Diagnostics den Packet Capture anschmeissen und sehen ob der Laptop überhaupt DHCP Requests sendet und die an der FW bzw. DMZ Port ankommen.
Ggf. tuts natürlich auch ein Wireshark auf dem Laptop.
Der fehlende DHCP Request ist schon komisch...der sollte eigentlich zu sehen sein?!
Die Firewall läuft jetzt seit ca 6 Monaten, keine Probleme bisher. LAN läuft einwandfrei.
Services / DNS Forwarder ist nicht aktiviert. Wurde bisher auch in keiner Anleitung erwähnt.
Ist das hier relevant?
Services / DNS Forwarder ist nicht aktiviert. Wurde bisher auch in keiner Anleitung erwähnt.
Ist das hier relevant?
Zitat von @Nidavellir:
Services / DNS Forwarder ist nicht aktiviert. Wurde bisher auch in keiner Anleitung erwähnt.
Ist das hier relevant?
Ich denke nicht zwingend, nein.Services / DNS Forwarder ist nicht aktiviert. Wurde bisher auch in keiner Anleitung erwähnt.
Ist das hier relevant?
Ev ist es dann wirklich ein Hardwaredefekt?
Mal auf Werkeinstellung zurück gesetzt und getestet und die Konfig wieder zurück gespielt?
Gruß
Ich habe den gleichen Laptop an den LAN-Port (hinter Switch) gehangen und er bekommt sofort eine IP aus dem LAN-Bereich.
Hänge ich ihn dann wieder an den DMZ-Port, behält er die IP (inkl Gateway) aus dem LAN.
Das ganze habe ich noch mit einem anderen Laptop getestet, gleiches Ergebnis.
Unter Diagnostics / Packet Capture habe ich das Interface auf DMZ geändert und sonst keine Einstellungen verändert. Richtig so?
Ergebnis:
Während der Aufzeichnung habe ich mehrfach das Kabel gezogen und wieder eingesteckt.
Hänge ich ihn dann wieder an den DMZ-Port, behält er die IP (inkl Gateway) aus dem LAN.
Das ganze habe ich noch mit einem anderen Laptop getestet, gleiches Ergebnis.
Unter Diagnostics / Packet Capture habe ich das Interface auf DMZ geändert und sonst keine Einstellungen verändert. Richtig so?
Ergebnis:
21:21:23.944957 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:21:36.687302 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
21:21:36.795309 ARP, Request who-has 169.254.29.124 tell 0.0.0.0, length 46
21:21:37.795406 ARP, Request who-has 169.254.29.124 tell 0.0.0.0, length 46
21:21:38.804007 ARP, Request who-has 169.254.29.124 tell 0.0.0.0, length 46
21:21:39.800233 ARP, Request who-has 169.254.29.124 tell 169.254.29.124, length 46
21:21:39.820994 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:21:39.878755 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:39.878858 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:39.878995 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:40.579594 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:21:40.643109 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:40.793124 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:40.793139 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:41.347455 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:21:41.400275 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:41.400548 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:41.400652 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:41.693513 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
21:21:42.156652 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:42.156912 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:42.156975 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:45.684547 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
21:21:52.438878 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
21:21:52.798700 ARP, Request who-has 169.254.29.124 tell 0.0.0.0, length 46
21:21:53.798267 ARP, Request who-has 169.254.29.124 tell 0.0.0.0, length 46
21:21:54.794665 ARP, Request who-has 169.254.29.124 tell 0.0.0.0, length 46
21:21:55.797155 ARP, Request who-has 169.254.29.124 tell 169.254.29.124, length 46
21:21:55.815074 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:21:55.875832 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:55.875952 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:55.876046 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:56.575788 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:21:56.638275 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:56.638599 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:56.638797 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:56.763485 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
21:21:57.339393 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:21:57.401943 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:57.402126 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:57.402291 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:58.157881 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:58.158101 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:21:58.158236 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 68
21:22:01.742723 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
21:22:08.008779 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:22:08.781925 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:22:09.546758 IP 169.254.29.124.137 > 169.254.255.255.137: UDP, length 50
21:22:09.593801 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300Während der Aufzeichnung habe ich mehrfach das Kabel gezogen und wieder eingesteckt.
Hardwaredefekt würde ich ausschließen: wenn ich auf dem Laptop die IP-Infos manuell konfiguriere, klappt alles.
Ich kann Websites ansurfen, den PC aus dem LAN anpingen, etc.
Bevor ich meine Frage hier gepostet habe, habe ich meine bisherigen Firewall-Regeln (DMZ) gelöscht, das Interface entfernt und alles nochmal frisch konfiguriert.
Fürs Rücksetzen auf die Werkseinstellungen muss ich sicher wieder mit dem Nullmodem-Kabel ran, oder? Dafür werde ich sicher erst nach dem Urlaub die Ruhe haben, Ende Juni ca.
Ich kann Websites ansurfen, den PC aus dem LAN anpingen, etc.
Bevor ich meine Frage hier gepostet habe, habe ich meine bisherigen Firewall-Regeln (DMZ) gelöscht, das Interface entfernt und alles nochmal frisch konfiguriert.
Fürs Rücksetzen auf die Werkseinstellungen muss ich sicher wieder mit dem Nullmodem-Kabel ran, oder? Dafür werde ich sicher erst nach dem Urlaub die Ruhe haben, Ende Juni ca.
Hänge ich ihn dann wieder an den DMZ-Port, behält er die IP (inkl Gateway) aus dem LAN.
Das ist klar, du musst eine neue DHCP Vergabe erzwingen das geht mit: ipconfig -release
ipconfig -renew
in der Eingabeaufforderung.
Dann wird ein neuer DHCP Request gesendet an den DHCP Server der pfSense.
Oben sieht man auch die DHCP Requests:
21:21:36.687302 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
Leider kann man nicht mit 100% Sicherheit sagen ob die das deines Testrechners sind, denn du hast die Details nicht aufgeklappt. Um ganz sicher zu gehen müsste man die Mac Absender Adresse mal mit der des Rechners vergleichen (ipconfig -all) dann kann man das sicher verifizieren.
Wenn er das ist, dann antwortet der DHCP Server der pfSense nicht
Gehe mal direkt auf die pfSense unter "Diagnostics" und strate da den Paket Sniffer auf dem DMZ Interface und checke mal ob diese Pakete direkt an der pfSense ankommen !
Sorry...wer lesen kann... Sehe gerade das das schon der Diagnostics Output war...
muss ich sicher wieder mit dem Nullmodem-Kabel ran, oder?
Nein, sie kommt dann nur mit den Default Settings wieder hoch. Wenn du vorher eine Sicherung gemacht hast kannst du die dann wieder einspielen und alles ist wie vorher.Eine identische HW rennt hier übrigens mit deinem Setup fehlerlos.
Hast du auch mal einen einfachen Reboot versucht...just in case das sich da was aufgehängt hat evtl. ?
Nachsatz:
Ich habe eben mal ein APU1D jungfräulich mit einer 2.3.er Version bespielt und damit lies sich tatsächlich dein Verhalten reproduzieren !!
Auf einem eingerichteten OPT1 Interface wurden keine IP Adressen vergeben obwohl die Requests am Client gesendet wurden (Wireshark) und auch an der pfSense ankamen (Diagnostics -> Packet Trace).
Dabei war es egal ob die FW Regeln am OPT1 Interface alles, nur OPT1 Source oder sogar zusätzlich 0.0.0.0 UDP 68 an 255.255.255.255 UDP 67 (klassischer DHCP Request) konfiguriert waren.
Kein Reply vom pfSense DHCP Server...
Ein Aktivieren der Lease Time auf Local Time statt UTC brachte ebenfalls keinen Erfolg.
Erst als ich den Status des DHCP Servers angesehen hatte, die Log Reihenfolge auf aktuellstes Zuerst und einen Reset der Logs ausgeführt hatte (dabei wird immer der DHCP Server neu gestartet) gab es sofort einen ACK auf den Client DHCP Request am OPT1 und der Client hatte Zugriff.
Das wurde dann auch im DHCP Log entsprechend angezeigt.
Ein Reproduzieren des Fehlers war danach nicht mehr möglich. Nach einem Client Reboot und auch einen Firewall Reboot funktionierte der DHCP Server dann immer fehlerlos.
Sieht aber so aus als ob der Server eine kleine Macke hat. Ggf. hilft das Update auf die aktuelle 2.3.1 auch damit lies sich das Problem nicht mehr reproduzieren.
Einige User melden im Forum auch dieses Verhalten wenn man z.B. die IP Adresse des Interfaces ändert und den DHCP anpasst. Auch hier stoppt dann die DHCP Vergabe und wird erst wieder nach einem Neustart des Daemons und Reset der Firewall States ausgeführt.
Letzteres sollte auch bei dir den DHCP Server zum Fliegen bringen...
Ich habe eben mal ein APU1D jungfräulich mit einer 2.3.er Version bespielt und damit lies sich tatsächlich dein Verhalten reproduzieren !!
Auf einem eingerichteten OPT1 Interface wurden keine IP Adressen vergeben obwohl die Requests am Client gesendet wurden (Wireshark) und auch an der pfSense ankamen (Diagnostics -> Packet Trace).
Dabei war es egal ob die FW Regeln am OPT1 Interface alles, nur OPT1 Source oder sogar zusätzlich 0.0.0.0 UDP 68 an 255.255.255.255 UDP 67 (klassischer DHCP Request) konfiguriert waren.
Kein Reply vom pfSense DHCP Server...
Ein Aktivieren der Lease Time auf Local Time statt UTC brachte ebenfalls keinen Erfolg.
Erst als ich den Status des DHCP Servers angesehen hatte, die Log Reihenfolge auf aktuellstes Zuerst und einen Reset der Logs ausgeführt hatte (dabei wird immer der DHCP Server neu gestartet) gab es sofort einen ACK auf den Client DHCP Request am OPT1 und der Client hatte Zugriff.
Das wurde dann auch im DHCP Log entsprechend angezeigt.
Ein Reproduzieren des Fehlers war danach nicht mehr möglich. Nach einem Client Reboot und auch einen Firewall Reboot funktionierte der DHCP Server dann immer fehlerlos.
Sieht aber so aus als ob der Server eine kleine Macke hat. Ggf. hilft das Update auf die aktuelle 2.3.1 auch damit lies sich das Problem nicht mehr reproduzieren.
Einige User melden im Forum auch dieses Verhalten wenn man z.B. die IP Adresse des Interfaces ändert und den DHCP anpasst. Auch hier stoppt dann die DHCP Vergabe und wird erst wieder nach einem Neustart des Daemons und Reset der Firewall States ausgeführt.
Letzteres sollte auch bei dir den DHCP Server zum Fliegen bringen...
Vielen Dank für deine Recherche!
Ein Neustart des DHCP-Servers hat bei mir nicht geholfen.
Ich habe dann kurzerhand das Update auf 2.3.1 durchgeführt und jetzt funktioniert es wie es soll.
Wobei ich leider nicht genau sagen kann, ob das Update oder der Reboot geholfen hat.
Ein Neustart des DHCP-Servers hat bei mir nicht geholfen.
Ich habe dann kurzerhand das Update auf 2.3.1 durchgeführt und jetzt funktioniert es wie es soll.
Wobei ich leider nicht genau sagen kann, ob das Update oder der Reboot geholfen hat.
Ja, das war hier im Test auch etwas "unklar"
Gut wenns nun klappt wie es soll.
Gut wenns nun klappt wie es soll.
