PfSense vergibt auf VLAN1 per DHCP IP-Adressen, auf VLAN2 nicht
Hallo pfSense-Profis,
nach dem Gewitter gestern ist bei uns im örtlichen Pfarrhaus das Netzwerk abgeraucht. Stromausfall und nachdem der wieder da war, ging gar nichts mehr. Ich habe keine Ahnung was da passiert ist. Die Netzteile sind okay, aber sowohl bei der pfSense als auch beim Cisco SG300 sind die Konfigurationen futsch bzw. nicht mehr existent. Von der Cisco-Konfig hatte ich ein Backup liegen, das BU der pfSense ist leider nicht existent, da ich von OPNSense auf pfSense wechseln wollte. Letzteres soll ja stabiler laufen.
So weit so gut. Ich lege also zwei VLANs an (VID 3000 Office, VID 3200 Guest), dazu die passenden DHCP-Server und pro VLAN eine Scheunentor-Regel. Das Gastnetz funktioniert DHCP-technisch tadellos, aber das Büronetz, welches im Moment noch genauso konfiguriert ist, verteilt per DHCP keine Adressen. Gebe ich dem Client eine Statische aus dem Adressbereich, passiert auch nix.
Ich sollte noch dazu sagen, dass ich im Büro ein W30AP dran habe. Der Aufbau ist wie folgt (um es noch mal grafisch darzustellen):
www ----- Fritzbox 7390 ----- pfSense ----- Cisco SG300 ----- W30AP (Wifi mit OfficeWLAN und GuestWLAN)
Der W30AP hat die SSIDs schon der jeweiligen VID zugeordnet; ist mit dem Cisco auf Port 2 verbunden. Dieser ist für VID 3000 und VID 3200 getagged und läuft als Trunk. Gleiches gilt für Port 1 am Cisco, welcher dann in die pfSense geht.
Wie gesagt. Das "Gast-Netz" geht. Die Einstellungen zum "Office-Netz" sind identisch. Habe ich irgendwas übersehen, bzw. was hab ich übersehen?
Beste Grüße
Chris
nach dem Gewitter gestern ist bei uns im örtlichen Pfarrhaus das Netzwerk abgeraucht. Stromausfall und nachdem der wieder da war, ging gar nichts mehr. Ich habe keine Ahnung was da passiert ist. Die Netzteile sind okay, aber sowohl bei der pfSense als auch beim Cisco SG300 sind die Konfigurationen futsch bzw. nicht mehr existent. Von der Cisco-Konfig hatte ich ein Backup liegen, das BU der pfSense ist leider nicht existent, da ich von OPNSense auf pfSense wechseln wollte. Letzteres soll ja stabiler laufen.
So weit so gut. Ich lege also zwei VLANs an (VID 3000 Office, VID 3200 Guest), dazu die passenden DHCP-Server und pro VLAN eine Scheunentor-Regel. Das Gastnetz funktioniert DHCP-technisch tadellos, aber das Büronetz, welches im Moment noch genauso konfiguriert ist, verteilt per DHCP keine Adressen. Gebe ich dem Client eine Statische aus dem Adressbereich, passiert auch nix.
Ich sollte noch dazu sagen, dass ich im Büro ein W30AP dran habe. Der Aufbau ist wie folgt (um es noch mal grafisch darzustellen):
www ----- Fritzbox 7390 ----- pfSense ----- Cisco SG300 ----- W30AP (Wifi mit OfficeWLAN und GuestWLAN)
Der W30AP hat die SSIDs schon der jeweiligen VID zugeordnet; ist mit dem Cisco auf Port 2 verbunden. Dieser ist für VID 3000 und VID 3200 getagged und läuft als Trunk. Gleiches gilt für Port 1 am Cisco, welcher dann in die pfSense geht.
Wie gesagt. Das "Gast-Netz" geht. Die Einstellungen zum "Office-Netz" sind identisch. Habe ich irgendwas übersehen, bzw. was hab ich übersehen?
Beste Grüße
Chris
Please also mark the comments that contributed to the solution of the article
Content-ID: 338808
Url: https://administrator.de/contentid/338808
Printed on: October 4, 2024 at 05:10 o'clock
14 Comments
Latest comment
Hallo,
Dann hast du diese dort (im Cisco) nicht gespeichert gehabt. Unwahrscheinlich das eine Blitzentladung nur die Running Config löscht, die gespeicherte Config ebenfalls löscht und alles auf Werkseinstellung setzt
Gruß,
Peter
Dann hast du diese dort (im Cisco) nicht gespeichert gehabt. Unwahrscheinlich das eine Blitzentladung nur die Running Config löscht, die gespeicherte Config ebenfalls löscht und alles auf Werkseinstellung setzt
Das Gastnetz funktioniert DHCP-technisch tadellos, aber das Büronetz, welches im Moment noch genauso konfiguriert ist,
Wirklich genauso Konfiguriert?verteilt per DHCP keine Adressen. Gebe ich dem Client eine Statische aus dem Adressbereich, passiert auch nix.
Da fehlen dir dann ein paar Regeln.Wie gesagt. Das "Gast-Netz" geht. Die Einstellungen zum "Office-Netz" sind identisch.
Wirklich Identisch?Gruß,
Peter
Gebe ich dem Client eine Statische aus dem Adressbereich, passiert auch nix.
Zeigt das es keinerlei Verbindung vom Switch VLAN 3000 auf das pfSense Interface VLAN 3000 gibt.Da ist dann wohl irgendwas schiefgelaufen bei der Konfig bzw. der VLAN Konfig der pfSense ?!
Das entsprechende Tutorial dazu hast du gelesen ??
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Da du es leider versäumt hast mal einen Screenshot der Konfig zu posten kann man hier nur mutmaßen das du einen Tippfehler bei der IP Adresse oder Maske oder in der Adresspool Definition gemacht hast ?!
Dann geht logischerweise nix mehr beim DHCP.
Dieser ist für VID 3000 und VID 3200 getagged und läuft als Trunk. Gleiches gilt für Port 1 am Cisco, welcher dann in die pfSense geht.
Alles richtig gemacht !Kann also nur ein Tippfehler sein...
OK,
1. Fehler in den Regeln aber eher kosmetisch.
Du solltest nie eine solch wirklich vollkomm offenen Scheunentorregel dort definieren !
Als Absender (Source) solltest du das schon auf Office_LAN network einschränken, denn dort können ja niemals Pakete mit einer anderen Absender IP als dem Office-LAN Netzwerk auftauschen. Und wenn doch....dann willst du die da mit Sicherheit NICHT haben !
Die Konfigs sehen soweit erstmal richtig aus.
Verwiirend ist allerdings die Portangabe "OP" und "M" am Firewall Port. Da sist nicht normal, denn normal müsste da stehen "1U, 3000T, 3200T"
Also U=untagged und T=tagged. Möglich aber das das durch die grusilige Übersetzung im deutschen GUI passiert. Normal ist das aber nicht.
Ggf. wäre nochmal ein Screenshot der dedizierten Port Einstellungen (Trunk, tagged etc.) vom Firewall Port 1 hier hilfreich.
Weitere hilfreiche ToDos um weiterzukommen:
Damit schneidest du dann alle UDP Pakete am Port VLAN 3000 mit (DHCP ist UDP Port 67 und 68)
Jetzt lässt du wieder einen PC per DHCP ins Netz und checkst ob an der pfSense die DHCP Requests ankommen !!
Ist das der Fall ??
Hier ein DHCP Capture Beispiel auf einem tagged Port der pfSense:
Du kannst hier wunderbar den DHCP Prozess beobachten: (wie übrigens auch am Wireshark !)
Entsprechend dann auch die Überprüfung des DHCP Logs auf der pfSense:
Auf diese sehr einfache und wasserdichte Diagnosemöglichkeit kommt man eigentlich mit dem gesunden Menschenverstand von selber. Spätestens aber wenn man mal ins pfSense Diagnostics Menü sieht !!
1. Fehler in den Regeln aber eher kosmetisch.
Du solltest nie eine solch wirklich vollkomm offenen Scheunentorregel dort definieren !
Als Absender (Source) solltest du das schon auf Office_LAN network einschränken, denn dort können ja niemals Pakete mit einer anderen Absender IP als dem Office-LAN Netzwerk auftauschen. Und wenn doch....dann willst du die da mit Sicherheit NICHT haben !
Die Konfigs sehen soweit erstmal richtig aus.
Verwiirend ist allerdings die Portangabe "OP" und "M" am Firewall Port. Da sist nicht normal, denn normal müsste da stehen "1U, 3000T, 3200T"
Also U=untagged und T=tagged. Möglich aber das das durch die grusilige Übersetzung im deutschen GUI passiert. Normal ist das aber nicht.
Ggf. wäre nochmal ein Screenshot der dedizierten Port Einstellungen (Trunk, tagged etc.) vom Firewall Port 1 hier hilfreich.
Weitere hilfreiche ToDos um weiterzukommen:
- Schiesse einen Wireshark Laptop statt Firewall an den Port 1 an und starte den Wireshark. Dann steckst du einen PC oder Endgerät in VLAN 3000 und lässt den DHCP machen. Am Firewall Port 1 müsste jetzt eine eingehenden DHCP Request mit einem VLAN 3000 Tag zu sehen sein !! Ist das der Fall ??
- Alternativ ohne Wireshark PC nutzt du den Whireshark direkt auf der Firewall !! Hier gehst du unter Diagnostics --> Paket Capture und wählst dort das VLAN 3000 Office LAN Interface aus so das sich die pfSense alle eingehenden Pakete auf diesem VLAN 3000 Interface ansieht.
Damit schneidest du dann alle UDP Pakete am Port VLAN 3000 mit (DHCP ist UDP Port 67 und 68)
Jetzt lässt du wieder einen PC per DHCP ins Netz und checkst ob an der pfSense die DHCP Requests ankommen !!
Ist das der Fall ??
Hier ein DHCP Capture Beispiel auf einem tagged Port der pfSense:
Du kannst hier wunderbar den DHCP Prozess beobachten: (wie übrigens auch am Wireshark !)
- Paket 1 vom Client mit dem Request UDP Port 68 hat als Absender IP die 0.0.0.0. Klar, denn der Client hat ja noch keine IP Adresse ! Schickt einen All Net Broadcast 255.255.255.255 Zielport UDP 67 ins Netz nach einem DHCP Server
- Paket 2 antwortet der pfSense DHCP Server 10.10.7.1 mit DHCP Reply UDP Absenderport 68 und Zuweisung der .14 (Zielport UDP 67) als Client IP Adresse... DHCP Vorgang erforlgreich.
- Paket 3 dann der DNS Request des Clients.
Entsprechend dann auch die Überprüfung des DHCP Logs auf der pfSense:
Auf diese sehr einfache und wasserdichte Diagnosemöglichkeit kommt man eigentlich mit dem gesunden Menschenverstand von selber. Spätestens aber wenn man mal ins pfSense Diagnostics Menü sieht !!
Aber an der pfSense kommt so gar nichts an. Das Paket 1 bleibt also irgendwo hängen.
Dann ist dein Problem auch definitiv NICHT an der pfSense bzw. dessen Firewall für VLAN 3000 !Wenn kein Request ankommt kann der Server auch nix senden...logisch
Check mal deine Switch Uplinks. Da ist vermutlich irgendwo noch der Wurm drin das das VLAN 3000 nicht überall transparent an den 3000er Ports durchgeleitet wird.
Ein Client DIREKT am Switch an dem die Firewall dranhängt sollte aber DHCP Traffic erzeugen an der FW.
Was die Screenshots nur an diesem Switch in der Konfig zeigten war soweit OK.
Ansonsten wie gesagt nochmal den Wireshark bemühen.
Die Switch Firmware ist auf dem aktuellsten Stand ??
https://software.cisco.com/download/find.html?q=sg300&task=default&a ...
Oha...das hört sich nicht gut an. Da ist irgendwas mit dem Update schiefgegangen !
Das solltest du unbedingt korrigieren bevor du weitermachst, das der Switch auch wirklich das Image bootet was er anzeigt.
Hast du es mal mit einem TFTP Update versucht ??
Lade dir einen TFTP Server runter und starte den.
Die Klassiker sind TFTP32:
http://tftpd32.jounin.net
oder Pumpkin:
http://kin.klever.net/pumpkin/
Die startest du und packst die Firmware Image Datei in die entsprechenden TFTP Verzeichnisse der o.a. Server.
Dann gehst du ins File Management Menü und Firmware Upgrade:
Hier wählst du dann die IP Adresse des TFTP Servers und darunter den Image Dateinamen.
Der Upgrade mit TFTP sollte in jedem Falle fehlerfrei durchlaufen !
Achtung:
Lade dir von der Cisco Seite auch den entsprechenden Bootcode zum Image und date den entsprechend up !!!
Ebenso lies dir zwingend die Release Notes zur aktuellen 1.4.7.6 Version durch !!
Da du von einer uralten Version kommst ist es gut möglich das du einen Zwischenschritt beim Update machen musst !
Das solltest du unbedingt korrigieren bevor du weitermachst, das der Switch auch wirklich das Image bootet was er anzeigt.
Hast du es mal mit einem TFTP Update versucht ??
Lade dir einen TFTP Server runter und starte den.
Die Klassiker sind TFTP32:
http://tftpd32.jounin.net
oder Pumpkin:
http://kin.klever.net/pumpkin/
Die startest du und packst die Firmware Image Datei in die entsprechenden TFTP Verzeichnisse der o.a. Server.
Dann gehst du ins File Management Menü und Firmware Upgrade:
Hier wählst du dann die IP Adresse des TFTP Servers und darunter den Image Dateinamen.
Der Upgrade mit TFTP sollte in jedem Falle fehlerfrei durchlaufen !
Achtung:
Lade dir von der Cisco Seite auch den entsprechenden Bootcode zum Image und date den entsprechend up !!!
Ebenso lies dir zwingend die Release Notes zur aktuellen 1.4.7.6 Version durch !!
Da du von einer uralten Version kommst ist es gut möglich das du einen Zwischenschritt beim Update machen musst !
tftpd auf der davor hängenden pfsense würdest du abraten?
Es ist vollkommen egal wo der TFTP Server rennt. Mit dem pfSense TFTP hast du es intuitiv genau richtig gemacht Gebe ich dem Computer manuell eine IP-Adresse aus dem VLAN, dann sieht er nach wie vor kein Netzwerk
Du meinst aus dem Office VLAN wo du sonst keine DHCP IP bekommst, richtig ?!Wenn du auch mit einer statischen IP Adresse nichts erreichst zeigt das schon das grundsätzlich an deiner VLAN Konfig ein Fehler ist !
Du solltest dann mal strategisch vorgehen und einen 2ten Laptop oder anderes Endgerät mit einer statischen Office_VLAN IP in eines der VLAN Ports stecken und versuchen den zu pingen.
Denk dran wenn es ein aktuelles Winblows ist das Ping (ICMP Protokoll) in der Firewall deaktiviert ist und du es erst erlauben musst !!
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
So kannst du dann erstmal live testen ob das Office VLAN durchgängig ist.
Im Zweifel setzt du den oder die Switches auf den Wwerkszustand zurück und fängst nochmal sauber von vorne an:
- VLANs einrichten
- Tagged Uplink Ports zuweisen
- Untagged Endgeräteports zu weisen
- Switches über tagged Uplink koppeln
- VLAN Erreichbarkeit mit Clients testen wie oben beschrieben
- Tagged pfSense Port anschliessen und testen
Jetzt zieht sich der Computer die richtigen IPs für sich, DNS und das Std.GW. Doch ich kann weder die pfSense anpingen, noch komme ich ins www.
Das sieht schonmal gut aus. Hier hast du dann wenigstens VLAN Connectivity und DHCP funktioniert dann auch wie erwartet. Zeigt das das Konzept generell richtig ist.Auch hier wieder schrittweise Troubleshooten !!!
- Zuerst immer ins Menü Diagnostics --> Ping gehen auf der pfSense !!!
- Hier pingst du dann einmal mit Source Adress xxLAN (Gast VLAN) einen der Clients in dem Segment an und checkst ob das geht. ACHTUNG:!!! An die Windows Firewall in ICMP blocking denken wie oben bereits beschrieben !! Ggf. immer einen AP oder Endgerät OHNE Firewall pingen um sicherzugehen.
- Dann pingst du immer die 8.8.8.8 mit Source Adress WAN um die Internet Verbindung zu testen !!
- Dann am Client die Firewall bzw. korrespondierenden LAN Anschluss pingen.
- Klappt das danach dann die 8.8.8.8
Möchte ich vom Cisco aus die pfSense anpingen, so kann ich das gar nicht im VLAN 3000
Das ist auch sonnenklar das das nicht geht !! Denk mal bitte etwas nach !Der Cisco hat seine Management IP defaultmässig im VLAN 1 ! VLAN 1 ist der Parent Port an der pfSense !!
Wenn du dort keine IP konfiguriert hast bzw. auch keine Regel kann ein Zugriff aus diesem VLAN 1 vom Switch nicht ins Office VLAN und andersrum...logisch, denn die pfSense muss ja vom Office VLAN ins VLAN 1 routen.
Wenn du das Default Management VLAN 1 des Switches nicht über die Firewall routen willst dann musst du es dediziert in eins deiner VLANs setzen.
Hier mal am Beispiel des VLANs 11 an einem Cisco Switch:
Das hast du vermutlich auch vergessen zu bedenken und zu konfigurieren und dann ist es logisch das so ein Ping Versuch fehlschlägt.
Zudem ist es auch sinnlos zu pingen denn wenn du im Office VLAN keinerlei Verbindung hast besteht ja die Gefahr das das fehlkonfiguriert ist. Dann zu denken das ein Ping dann daraus klappen sollte wäre Unsinn !
Gehe also strategisch Schritt für Schritt vor über das Diagnostics Menü und Ping der Firewall.
Im Zweifel resette den Switch auf den Werkszustand und fange nochmal genau Schritt für Schritt an.
Dann kommt das auch sofort zum Fliegen !
Nun habe ich einen virt. Win10 Rechner direkt ans LAN-Interface gehangen und dem die IP 192.168.176.20 verpasst.
Das wäre ja völliger Unsinn und kann niemals funktionieren.Das LAN Interface ist das Parent Interface auf der pfSense und hat die IP Zitat:
LAN (Static) - hat die IP 10.10.0.1; es gibt keinen DHCP-Server fürs LAN
Wie bitte willst du es bewerkstelligen mit einer 192.168.176er Absender IP auf eine 10er IP im gleichen Layer 2 netz zuzugreifen ??Das weisst du vermutlich selber das das Blödsinn ist das kann ja niemals gehen.
Wenn überhaupt dann musst der Test PC im LAN ja logischerweise eine 10.10.0.x IP haben damit es Sinn macht.
Weisst du aber ja sicher auch selber ?!
LAN und Office_LAN liegen ja an der pfSense auf einem physischen Interface !! Wobei das LAN Interface das sog. Parent Interface ist also das grundlegende Interface wenn man so will an das alle untagged Pakete geforwardet werden.
Sprich wenn man also einen PC direkt auf das LAN Interface steckt, damit ungetaggte Pakte an das LAN Interface sendet, muss dieser PC zwangsweise eine IP im 10.10.0.x IP Netz haben um damit kommunizieren zu können.
Das Office_VLAN Interface das auf diesem physischen LAN Interface liegt, ist über die pfSense Konfig fest an ein VLAN Tag gebunden !!! Nehmen wir mal an die VLAN ID 10
Das bewirkt jetzt das alle eingehenden Pakete am LAN Interface die ein VLAN Tag 10 am Paket haben dann dem virtuellen Office_LAN Interface zugeordent werden.
Also müssen Geräte im VLAN 10 des Switches einen 192.168.176.x IP Adresse haben...logisch !
Dein "Test" musste also wegen falscher IP Adressierung in die Hose gehen.
Also nochmal neu und diesmal richtig !!!
- Switch resetten
- Auf dem Switch ein VLAN 10 anlegen
- 2 oder 3 Ports dem VLAN 10 untagged als Access Ports zuweisen
- auf dem Switch einen Trunk Port anlegen bei dem das VLAN 1U (=untagged) und VLAN 10T (=tagged) aufliegt
- Diesen Trunk Port in das LAN Interface der pfSense stecken
- pfSense natürlich IP seitig entsprechen konfigurieren und dem Offive_LAN Port die VLAN ID 10 zuweisen gem. VLAN Tutorial.
- pfSense fürs LAN IP Netz und fürs Office IP Netz einen DHCP Server konfigurieren.
Steckst du den dann um auf einen Port im VLAN 10 bekommt der PC eine 192.168.176.x IP
So wie es auch sein soll !!!
Fazot: Wenn testen dann richtig und vor allem mit richtiger IP die zum Interface passt