5
Pfsense 2.4.4 - 0.0.0.0.68 nicht nachvollziehbar
Hallo zusammen,
wir haben gestern bei uns in der Firma von iptables zu pfsense gewechselt.
Hardware: APU2C4 Legacy BIOS 4.0.18 (4.0.19 hat Probleme gemacht )
pfsense: 2.4.4-Release
Im Netzwerk funktioniert alles wie gewohnt. Beim Logs durchschauen ist mir ein Punkt aufgefallen welcher für mich allerdings nicht nachvollziehbar ist.
In den Logs der pfsense(Status/System Logs/Firewall/Normal View) taucht immer wieder(fast jede Minute) folgender Eintrag auf:
Oct 17 16:04:38 LAN Default deny rule IPv4 (1000000103) 0.0.0.0:68 255.255.255.255:67 UDP
Oct 17 16:04:59 LAN Default deny rule IPv4 (1000000103) 0.0.0.0:68 255.255.255.255:67 UDP
[...]
Das LAN Interface hat eine feste IP Adresse und es läuft kein DHCP-Server auf dem Interface. Per Shell auf der pfsense angemeldet und dort einen tcpdump gestartet:
tcpdump -i igb1 -n port 67 or port 68
16:01:31.029108 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0a:e4:81:61:71, length 300
16:01:39.449708 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0a:e4:81:61:71, length 300
Es ist immer wieder die selbe MAC-Adresse, die hier auftaucht.
Am LAN Anschluss ist direkt ein Server mit Ubuntu angeschlossen welcher für das interne Routing zuständig ist. Dort beim tcpdump sind keine Einträge mit der MAC-Adresse
aufgetaucht.
pfsense wurde bereits neu gestartet, allerdings tauchen die Log Einträge nach wie vor auf.
Hat jemand eine Idee, was es mit diesen DHCP-Requests auf sich hat?
Nachtrag
Wir haben jetzt direkt an das Interface vom Server der am LAN Interface der pfsense hängt einen Laptop gehängt und den Traffic mit Wireshark "eingefangen",
die DHCP Anfragen kommen vom Ubuntu Server. Allerdings kann ich die MAC Adresse auf dem Server nicht finden. Muss ich mal weiter recherchieren.
Auf dem Ubuntu Server ist auch ein DHCP Helper für die diversen Netze eingerichtet.
Nachtrag 2
Der DHCP Helper ist es, wir müssen die Konfig mal prüfen, eigentlich war er auf ein anderes Interface eingeschränkt aber anscheinend, haben wir da was falsch
gemacht.
//Nachtrag 3
Scheint doch nicht am DHCP helper zu liegen... Hat jemand eine Idee in welche Richtung man noch schauen kann?
Grüße
dark.cube
wir haben gestern bei uns in der Firma von iptables zu pfsense gewechselt.
Hardware: APU2C4 Legacy BIOS 4.0.18 (4.0.19 hat Probleme gemacht )
pfsense: 2.4.4-Release
Im Netzwerk funktioniert alles wie gewohnt. Beim Logs durchschauen ist mir ein Punkt aufgefallen welcher für mich allerdings nicht nachvollziehbar ist.
In den Logs der pfsense(Status/System Logs/Firewall/Normal View) taucht immer wieder(fast jede Minute) folgender Eintrag auf:
Oct 17 16:04:38 LAN Default deny rule IPv4 (1000000103) 0.0.0.0:68 255.255.255.255:67 UDP
Oct 17 16:04:59 LAN Default deny rule IPv4 (1000000103) 0.0.0.0:68 255.255.255.255:67 UDP
[...]
Das LAN Interface hat eine feste IP Adresse und es läuft kein DHCP-Server auf dem Interface. Per Shell auf der pfsense angemeldet und dort einen tcpdump gestartet:
tcpdump -i igb1 -n port 67 or port 68
16:01:31.029108 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0a:e4:81:61:71, length 300
16:01:39.449708 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0a:e4:81:61:71, length 300
Es ist immer wieder die selbe MAC-Adresse, die hier auftaucht.
Am LAN Anschluss ist direkt ein Server mit Ubuntu angeschlossen welcher für das interne Routing zuständig ist. Dort beim tcpdump sind keine Einträge mit der MAC-Adresse
aufgetaucht.
pfsense wurde bereits neu gestartet, allerdings tauchen die Log Einträge nach wie vor auf.
Hat jemand eine Idee, was es mit diesen DHCP-Requests auf sich hat?
Nachtrag
Wir haben jetzt direkt an das Interface vom Server der am LAN Interface der pfsense hängt einen Laptop gehängt und den Traffic mit Wireshark "eingefangen",
die DHCP Anfragen kommen vom Ubuntu Server. Allerdings kann ich die MAC Adresse auf dem Server nicht finden. Muss ich mal weiter recherchieren.
Auf dem Ubuntu Server ist auch ein DHCP Helper für die diversen Netze eingerichtet.
Nachtrag 2
Der DHCP Helper ist es, wir müssen die Konfig mal prüfen, eigentlich war er auf ein anderes Interface eingeschränkt aber anscheinend, haben wir da was falsch
gemacht.
//Nachtrag 3
Scheint doch nicht am DHCP helper zu liegen... Hat jemand eine Idee in welche Richtung man noch schauen kann?
Grüße
dark.cube
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: 389767
Url: https://administrator.de/contentid/389767
Ausgedruckt am: 13.11.2024 um 08:11 Uhr
5 Kommentare
Neuester Kommentar
Moin,
die MAC scheint zu Wistron zu gehören, einem Hersteller von Notebooks und Smartphones für Dell, Apple und co.
Vielleicht hast Du eins dieser System und kannst das weiter eingrenzen.
Im DHCP solltest Du die MAC doch auch finden können, oder?
Gruss
die MAC scheint zu Wistron zu gehören, einem Hersteller von Notebooks und Smartphones für Dell, Apple und co.
Vielleicht hast Du eins dieser System und kannst das weiter eingrenzen.
Im DHCP solltest Du die MAC doch auch finden können, oder?
Gruss
1
Moin,
ja danke für den Hinweis mit der MAC Adresse und die Informationen hinsichtlich der möglichen Komponenten.
Im DHCP finde ich die Adresse eben nicht, weil es sich ja um einen andauernenden DHCP Request zu scheinen handelt, sprich
das Device erhält keine IP. Im tcpdump auf dem Server konnte ich die MAC Adresse auch nicht finden. Der Server ist ein Ubuntu
Server welches intern für das Routing zuständig ist. Ich konnte den DHCP Request bisher quasi nur an dem ausgehenden Interface
von dem Server sehen, da ist die pfsense angeschlossen. Wir hatten dann mal die pfsense abgeklemmt und einen Laptop angeschlossen und
auch mit Wireshark konnte ich den Request mit der MAC Adresse sehen. Ist irgendwie etwas seltsam.
Wir werden sobald es möglich ist den Server nochmals durchstarten und dann nochmal beobachten.
Auf dem Server haben wir auch schon geprüft ob ein DHCP Client am Laufen ist, aber dem ist nicht so.
Sonst noch jemand eine Idee?
Gruß
dark.cube
ja danke für den Hinweis mit der MAC Adresse und die Informationen hinsichtlich der möglichen Komponenten.
Im DHCP finde ich die Adresse eben nicht, weil es sich ja um einen andauernenden DHCP Request zu scheinen handelt, sprich
das Device erhält keine IP. Im tcpdump auf dem Server konnte ich die MAC Adresse auch nicht finden. Der Server ist ein Ubuntu
Server welches intern für das Routing zuständig ist. Ich konnte den DHCP Request bisher quasi nur an dem ausgehenden Interface
von dem Server sehen, da ist die pfsense angeschlossen. Wir hatten dann mal die pfsense abgeklemmt und einen Laptop angeschlossen und
auch mit Wireshark konnte ich den Request mit der MAC Adresse sehen. Ist irgendwie etwas seltsam.
Wir werden sobald es möglich ist den Server nochmals durchstarten und dann nochmal beobachten.
Auf dem Server haben wir auch schon geprüft ob ein DHCP Client am Laufen ist, aber dem ist nicht so.
Sonst noch jemand eine Idee?
Gruß
dark.cube
Ist auf dem Ubuntu ggf. eine VM, Docker usw. aktiv im Bridging Mode ?
Ansonsten mal an den Port direkt statt der pfSense einen Wireshark Laptop anschliessen und das komplette Paket mitschneiden um zu checken ob im Paket irgendwelche Infos zu finden sind von wem dieses kommt.
Andere HA oder keepalive Mechanismen (VRRP usw.) nutzen in der Regel keine BOOTP oder DHCP Broadcasts insofern kann das also auch nicht die Ursache sein.
Ansonsten mal an den Port direkt statt der pfSense einen Wireshark Laptop anschliessen und das komplette Paket mitschneiden um zu checken ob im Paket irgendwelche Infos zu finden sind von wem dieses kommt.
Andere HA oder keepalive Mechanismen (VRRP usw.) nutzen in der Regel keine BOOTP oder DHCP Broadcasts insofern kann das also auch nicht die Ursache sein.
1
Brett vor dem Kopf gehabt... Der LAN Port ist auch gleichzeitig der IRMC Port, den wir allerdings schon ewig nicht mehr genutzt haben, da es eine alte Maschine ist. Der Port ist enabled und fordert natürlich fröhlich eine IP Adresse an, die er von der pfSense nicht bekommt. Das erklärt dann auch die MAC Adresse die sonst nirgendwo anders aufgetaucht ist.
Gewusst wo... 
Case closed !
Case closed !
