14
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
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: 338808
Url: https://administrator.de/contentid/338808
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
14 Kommentare
Neuester Kommentar
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...
Gutsten Morgen! Ich hoffe ihr habt euer verlängertes Wochenende gut überstanden. Danke für eure fleißigen Rückmeldungen. Ich hab mich mal bei gemacht und von meinen Einstellungen Screenshots gemacht. Bestimmt seht ihr meinen Fehler. Ich sehe nach wie vor den Wald vor Bäumen nicht.
Bild 1-3 ist die Konfig der pfSense.
Bild 4-8 ist der Cisco und
Bild 9 der IP-COM Accesspoint
Zitat von @aqui:
Das entsprechende Tutorial dazu hast du gelesen ??
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Jap. Damals schon, weshalb die Konfiguration erst funktionierte.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 ?!
Hab ich nachgeholt.Dann geht logischerweise nix mehr beim DHCP.
Kann also nur ein Tippfehler sein...
Ich hoffe der findet sich. Wahrscheinlich habe ich wo anders einen Schusselfehler gemacht.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...
Bild 1-3 ist die Konfig der pfSense.
Bild 4-8 ist der Cisco und
Bild 9 der IP-COM Accesspoint
Hallo Peter,
erstmal sorry für den Doppelpost. Kann man auch irgendwie die Zitatsfunktion nutzen und den Vorgänger des letzten Kommentators zitieren?
Oh! Ähhh, welche denn? Ich hab doch die "Scheunentor-Regel", wonach im Moment alles erlaubt ist. Oder welche Regeln meinst du?
Naja. Jein. Der Ablauf der Netzerstellung war identisch. =) Wie oben schon gesagt: VLAN-ID + IP-Adressbereich und die Namen sind anders. Die Firewall-Regel ist identisch. Also diesmal mein ich tatsächlich identisch 
Auch auf dem Cisco. Ich vermute den Fehler ja fast dort.
Habe Bilder von meinen Einstellungen gepostet hab. Vielleicht springt dich da gleich mein Fehler an. Ich hab alles nochmals am Wochenende überprüft, ob es nicht nur ein dusseliger Zahlendreher ist. Bin wahrscheinlich einfach nur betriebsblind.
Gruß zurück
erstmal sorry für den Doppelpost. Kann man auch irgendwie die Zitatsfunktion nutzen und den Vorgänger des letzten Kommentators zitieren?
Zitat von @Pjordorf:
Hallo,
Naja. Von der VLAN-ID und dem IP-Adressbereich schon. Der Ablauf der Konfiguration war identisch. Das trifft wohl eher als korrekte Aussage zu.Hallo,
Zitat von @sirhc4022:
Das Gastnetz funktioniert DHCP-technisch tadellos, aber das Büronetz, welches im Moment noch genauso konfiguriert ist,
Wirklich genauso Konfiguriert?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.
Da fehlen dir dann ein paar Regeln.Wie gesagt. Das "Gast-Netz" geht. Die Einstellungen zum "Office-Netz" sind identisch.
Wirklich Identisch?Auch auf dem Cisco. Ich vermute den Fehler ja fast dort.
Habe Bilder von meinen Einstellungen gepostet hab. Vielleicht springt dich da gleich mein Fehler an. Ich hab alles nochmals am Wochenende überprüft, ob es nicht nur ein dusseliger Zahlendreher ist. Bin wahrscheinlich einfach nur betriebsblind.
Gruß zurück
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 !!
Zitat von @aqui:
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 !
Danke für den Tipp! Hab ich mal gleich geändert.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.
Sieht wirklich nach verunglimpfter Übersetzung aus. So wie du es geschrieben hast, ist es eingestellt.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:
- 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:
Danke für den kleinen Exkurs! Hab das jetzt direkt auf der Firewall probiert. Muss ich morgen noch mal mit Wireshark machen. Aber an der pfSense kommt so gar nichts an. Das Paket 1 bleibt also irgendwo hängen.
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 !!
Najaaaa Aqui. Immer halblang mit mir Greenhorn. Ich will nicht sagen, dass ich keinen gesunden Menschenverstand habe. Ich lese mich in den ganzen shit rein und klemme mich so gut es geht dahinter. Du bist mir ein guter Lehrer und eine super Hilfe. I try my very best. Klar ist das Paket-Capture Tool genial. Man muss es zu nutzen wissen. Auch wenn das die Basics sind. Genau dafür bin ich hier. Ein Fehler, den ich nicht behoben komme; Aqui sagt: "Junge da gibts ein Tool. Schau, so nutzt man das!"; Chris macht das so und liest sich weiter ein und versucht zu verstehen.Das eine Bohrmaschine zum Löcher bohren da ist, ist klar. Wie man sie aber richtig benutzt muss gezeigt werden. =) Du weißt wie ich meine.
Meinst du, dass ich mit Wireshark noch weitere (bessere bzw. genauere) Diagnose-Ergebnisse bekomme? Wenn der Rechner die Firewall bzw. den darauf laufenden DHCP-Server nicht erreichen kann, dann würde ich am anderen Ende der Kette anfangen zu suchen. Kann ich die Pakete nicht direkt am Accesspoint capturen?
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 ...
Hey,
also ich bin dabei den Cisco zu checken. Die Firmware ist die 1.4.7.6. Die hat der Cisco auch drauf. Jetzt kommt das Problem: Allerdings als inaktives Image. Ich kann das nicht umstellen. Versuche ich das und starte den neu, dann nimmt er sich immer wieder das alte 1.3.7.18er Image. Ich kann auch das aktuellste Image, welches ich bei Cisco heruntergeladen habe nicht auf den Switch schieben, da ihm die Datei zu groß ist. Der bricht da immer ab.
Was nun?
also ich bin dabei den Cisco zu checken. Die Firmware ist die 1.4.7.6. Die hat der Cisco auch drauf. Jetzt kommt das Problem: Allerdings als inaktives Image. Ich kann das nicht umstellen. Versuche ich das und starte den neu, dann nimmt er sich immer wieder das alte 1.3.7.18er Image. Ich kann auch das aktuellste Image, welches ich bei Cisco heruntergeladen habe nicht auf den Switch schieben, da ihm die Datei zu groß ist. Der bricht da immer ab.
Was nun?
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 !
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 !
tftpd auf der davor hängenden pfsense würdest du abraten?
EDIT:
Meine Frage hat sich grad erübrigt. Dank 16GB SSD ist ausreichend Platz auf der pfSense um da temporär die Updates abzulegen und per TFTP bereit zu stellen. Mal sehen wie das läuft. Das 1. Upgrade des Bootcodes hab ich. Ist eine .rob Datei gewesen. Was ich mit den .zip-Dingern anfangen soll ist mir schleierhaft. Da sind zu viele Dateien drin. Ist dann wohl eher was fürs CLI?
EDIT:
Meine Frage hat sich grad erübrigt. Dank 16GB SSD ist ausreichend Platz auf der pfSense um da temporär die Updates abzulegen und per TFTP bereit zu stellen. Mal sehen wie das läuft. Das 1. Upgrade des Bootcodes hab ich. Ist eine .rob Datei gewesen. Was ich mit den .zip-Dingern anfangen soll ist mir schleierhaft. Da sind zu viele Dateien drin. Ist dann wohl eher was fürs CLI?
So. Die Kiste ist auf dem aktuellsten Stand und wieder so wie o.g. eingestellt. Auf der pfSense läuft nur der DHCP-Server auf dem Office-VLAN.
Gebe ich dem Computer manuell eine IP-Adresse aus dem VLAN, dann sieht er nach wie vor kein Netzwerk. Wenn er sich per DHCP eine IP-Adresse nehmen soll, dann bekommt er eine physische!? Wie geht denn das? Ich habe nur die pfSense dran und dort nur diesen einen DHCP-Server. Der Server auf dem Cisco ist aus und der Alfa-Switch ist bloß ein "dummer" PoE-Switch. Die APs haben auch einen DHCP-Server, aber der ist ebenfalls deaktiviert. Es wird immer kurioser.
Ich habe zudem das VLAN für die Gäste angelegt. Das lief ja am Anfang problemlos. 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. Trotz "Scheunentor-Regel".
Möchte ich vom Cisco aus die pfSense anpingen, so kann ich das gar nicht im VLAN 3000. Ich kann nur das VLAN 1 auswählen. Ist das normal? Hängt das mit dem DHCP-Server auf dem Cisco zusammen?
Gebe ich dem Computer manuell eine IP-Adresse aus dem VLAN, dann sieht er nach wie vor kein Netzwerk. Wenn er sich per DHCP eine IP-Adresse nehmen soll, dann bekommt er eine physische!? Wie geht denn das? Ich habe nur die pfSense dran und dort nur diesen einen DHCP-Server. Der Server auf dem Cisco ist aus und der Alfa-Switch ist bloß ein "dummer" PoE-Switch. Die APs haben auch einen DHCP-Server, aber der ist ebenfalls deaktiviert. Es wird immer kurioser.
Ich habe zudem das VLAN für die Gäste angelegt. Das lief ja am Anfang problemlos. 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. Trotz "Scheunentor-Regel".
Möchte ich vom Cisco aus die pfSense anpingen, so kann ich das gar nicht im VLAN 3000. Ich kann nur das VLAN 1 auswählen. Ist das normal? Hängt das mit dem DHCP-Server auf dem Cisco zusammen?
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 !
Hey,
ich habe mir jetzt mal die pfSense und den SG300 ausm Gemeindebüro mitgenommen und da das Netz erstmal an einer Fritzbox. Ich kann da nicht ständig hin, da der Hauswirtschaftsraum, in dem auch das Netzwerkgerödel hängt in den Privaträumen der Pfarrfamilie ist. Total blöd.
Jetzt hab ich alles auf meinem Schreibtisch und kann schalten und walten wie ich will.
Als erstes hab ich mir den Switch vorgenommen. Ich hab genau das gemacht, was du gesagt hast @aqui. Ich hab noch einmal von vorn angefangen. Switch zurückgesetzt, pfSense zurückgesetzt und letztere konfiguriert.
Ich glaube jetzt auch den Übeltäter gefunden zu haben, weiß allerdings nicht, was da ganz genau schief läuft.
Die pfSense ist das Problem bzw. die Konfiguration:
- WAN (DHCP) - hängt grad hinter meiner Fritzbox und bekommt von da eine IP. Im Interface-Menü habe ich das Häkchen "Block private network" entfernt.
- LAN (Static) - hat die IP 10.10.0.1; es gibt keinen DHCP-Server fürs LAN
- Office_LAN - läuft über das LAN-Interface; hat die IP 192.168.176.1; hier gibt es einen DHCP-Server der von 192.168.176.50 - 192.168.176.80 IPs verteilt.
Nun habe ich einen virt. Win10 Rechner direkt ans LAN-Interface gehangen und dem die IP 192.168.176.20 verpasst. Auf der pfSense ist wieder einen "Scheunentor-Regel" für das Office_LAN konfiguriert. Sende ich nun ein Ping an die 192.168.176.1 (Office_LAN Interface pfSense), dann kommt davon nichts an.
Ein Packetcapture auf Office_LAN bleibt leer. Ein Packetcapture auf LAN bringt folgendes Ergebnis:
15:37:44.479140 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:44.479486 IP 192.168.176.20.53063 > 224.0.0.252.5355: UDP, length 24
15:37:44.487608 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:44.487872 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:44.488011 IP 192.168.176.20.64737 > 224.0.0.252.5355: UDP, length 24
15:37:44.488197 IP 192.168.176.20.63760 > 224.0.0.252.5355: UDP, length 24
15:37:44.492768 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:44.493174 IP 192.168.176.20.62903 > 224.0.0.252.5355: UDP, length 24
15:37:44.540172 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:44.540249 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:44.540427 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:44.889894 IP 192.168.176.20.53063 > 224.0.0.252.5355: UDP, length 24
15:37:44.897825 IP 192.168.176.20.64737 > 224.0.0.252.5355: UDP, length 24
15:37:44.898808 IP 192.168.176.20.63760 > 224.0.0.252.5355: UDP, length 24
15:37:44.903891 IP 192.168.176.20.62903 > 224.0.0.252.5355: UDP, length 24
15:37:45.229717 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.237696 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.237800 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.243602 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.290709 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:45.290805 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:45.290827 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:45.865666 IP 10.10.0.25.59343 > 17.130.74.5.443: tcp 0
15:37:45.876507 IP 17.130.74.5.443 > 10.10.0.25.59343: tcp 0
15:37:45.912663 IP 17.130.74.5.443 > 10.10.0.25.59343: tcp 0
15:37:45.980748 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.987704 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.987797 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.995453 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:46.040724 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.040801 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.040822 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.488401 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:46.488755 IP 192.168.176.20.53197 > 224.0.0.252.5355: UDP, length 22
15:37:46.790786 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.790888 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.791113 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.898931 IP 192.168.176.20.53197 > 224.0.0.252.5355: UDP, length 22
15:37:47.237589 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:47.490336 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:47.490460 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:47.490762 IP 192.168.176.20.61796 > 224.0.0.252.5355: UDP, length 25
15:37:47.490852 IP 192.168.176.20.62117 > 224.0.0.252.5355: UDP, length 27
15:37:47.491034 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:47.491330 IP 192.168.176.20.63821 > 224.0.0.252.5355: UDP, length 31
15:37:47.900785 IP 192.168.176.20.61796 > 224.0.0.252.5355: UDP, length 25
15:37:47.901103 IP 192.168.176.20.62117 > 224.0.0.252.5355: UDP, length 27
15:37:47.902604 IP 192.168.176.20.63821 > 224.0.0.252.5355: UDP, length 31
15:37:47.988623 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.241821 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.241941 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.241963 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.991758 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.991882 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.991904 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:49.742610 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:49.742733 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:49.743012 IP 192.168.176.20.64515 > 224.0.0.252.5355: UDP, length 25
15:37:49.743135 IP 192.168.176.20.60924 > 224.0.0.252.5355: UDP, length 27
15:37:49.743549 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:49.743828 IP 192.168.176.20.61218 > 224.0.0.252.5355: UDP, length 31
15:37:50.153204 IP 192.168.176.20.64515 > 224.0.0.252.5355: UDP, length 25
15:37:50.153326 IP 192.168.176.20.60924 > 224.0.0.252.5355: UDP, length 27
15:37:50.154744 IP 192.168.176.20.61218 > 224.0.0.252.5355: UDP, length 31
15:37:50.492777 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:50.492900 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:50.493722 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.243773 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.243897 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.243919 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.258151 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.258918 IP 192.168.176.20.62574 > 224.0.0.252.5355: UDP, length 24
15:37:51.669043 IP 192.168.176.20.62574 > 224.0.0.252.5355: UDP, length 24
15:37:52.007737 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:52.758825 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:55.491663 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:55.492059 IP 192.168.176.20.52682 > 224.0.0.252.5355: UDP, length 22
15:37:55.902007 IP 192.168.176.20.52682 > 224.0.0.252.5355: UDP, length 22
15:37:56.241882 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:56.991916 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
Es wird also fröhlichst geNETBiost. Mehr passiert nicht. Wo hab ich jetzt den Bock in meiner Config drin?!
ich habe mir jetzt mal die pfSense und den SG300 ausm Gemeindebüro mitgenommen und da das Netz erstmal an einer Fritzbox. Ich kann da nicht ständig hin, da der Hauswirtschaftsraum, in dem auch das Netzwerkgerödel hängt in den Privaträumen der Pfarrfamilie ist. Total blöd.
Jetzt hab ich alles auf meinem Schreibtisch und kann schalten und walten wie ich will.
Als erstes hab ich mir den Switch vorgenommen. Ich hab genau das gemacht, was du gesagt hast @aqui. Ich hab noch einmal von vorn angefangen. Switch zurückgesetzt, pfSense zurückgesetzt und letztere konfiguriert.
Ich glaube jetzt auch den Übeltäter gefunden zu haben, weiß allerdings nicht, was da ganz genau schief läuft.
Die pfSense ist das Problem bzw. die Konfiguration:
- WAN (DHCP) - hängt grad hinter meiner Fritzbox und bekommt von da eine IP. Im Interface-Menü habe ich das Häkchen "Block private network" entfernt.
- LAN (Static) - hat die IP 10.10.0.1; es gibt keinen DHCP-Server fürs LAN
- Office_LAN - läuft über das LAN-Interface; hat die IP 192.168.176.1; hier gibt es einen DHCP-Server der von 192.168.176.50 - 192.168.176.80 IPs verteilt.
Nun habe ich einen virt. Win10 Rechner direkt ans LAN-Interface gehangen und dem die IP 192.168.176.20 verpasst. Auf der pfSense ist wieder einen "Scheunentor-Regel" für das Office_LAN konfiguriert. Sende ich nun ein Ping an die 192.168.176.1 (Office_LAN Interface pfSense), dann kommt davon nichts an.
Ein Packetcapture auf Office_LAN bleibt leer. Ein Packetcapture auf LAN bringt folgendes Ergebnis:
15:37:44.479140 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:44.479486 IP 192.168.176.20.53063 > 224.0.0.252.5355: UDP, length 24
15:37:44.487608 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:44.487872 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:44.488011 IP 192.168.176.20.64737 > 224.0.0.252.5355: UDP, length 24
15:37:44.488197 IP 192.168.176.20.63760 > 224.0.0.252.5355: UDP, length 24
15:37:44.492768 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:44.493174 IP 192.168.176.20.62903 > 224.0.0.252.5355: UDP, length 24
15:37:44.540172 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:44.540249 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:44.540427 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:44.889894 IP 192.168.176.20.53063 > 224.0.0.252.5355: UDP, length 24
15:37:44.897825 IP 192.168.176.20.64737 > 224.0.0.252.5355: UDP, length 24
15:37:44.898808 IP 192.168.176.20.63760 > 224.0.0.252.5355: UDP, length 24
15:37:44.903891 IP 192.168.176.20.62903 > 224.0.0.252.5355: UDP, length 24
15:37:45.229717 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.237696 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.237800 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.243602 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.290709 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:45.290805 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:45.290827 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:45.865666 IP 10.10.0.25.59343 > 17.130.74.5.443: tcp 0
15:37:45.876507 IP 17.130.74.5.443 > 10.10.0.25.59343: tcp 0
15:37:45.912663 IP 17.130.74.5.443 > 10.10.0.25.59343: tcp 0
15:37:45.980748 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.987704 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.987797 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:45.995453 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:46.040724 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.040801 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.040822 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.488401 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:46.488755 IP 192.168.176.20.53197 > 224.0.0.252.5355: UDP, length 22
15:37:46.790786 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.790888 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.791113 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 68
15:37:46.898931 IP 192.168.176.20.53197 > 224.0.0.252.5355: UDP, length 22
15:37:47.237589 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:47.490336 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:47.490460 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:47.490762 IP 192.168.176.20.61796 > 224.0.0.252.5355: UDP, length 25
15:37:47.490852 IP 192.168.176.20.62117 > 224.0.0.252.5355: UDP, length 27
15:37:47.491034 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:47.491330 IP 192.168.176.20.63821 > 224.0.0.252.5355: UDP, length 31
15:37:47.900785 IP 192.168.176.20.61796 > 224.0.0.252.5355: UDP, length 25
15:37:47.901103 IP 192.168.176.20.62117 > 224.0.0.252.5355: UDP, length 27
15:37:47.902604 IP 192.168.176.20.63821 > 224.0.0.252.5355: UDP, length 31
15:37:47.988623 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.241821 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.241941 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.241963 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.991758 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.991882 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:48.991904 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:49.742610 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:49.742733 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:49.743012 IP 192.168.176.20.64515 > 224.0.0.252.5355: UDP, length 25
15:37:49.743135 IP 192.168.176.20.60924 > 224.0.0.252.5355: UDP, length 27
15:37:49.743549 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:49.743828 IP 192.168.176.20.61218 > 224.0.0.252.5355: UDP, length 31
15:37:50.153204 IP 192.168.176.20.64515 > 224.0.0.252.5355: UDP, length 25
15:37:50.153326 IP 192.168.176.20.60924 > 224.0.0.252.5355: UDP, length 27
15:37:50.154744 IP 192.168.176.20.61218 > 224.0.0.252.5355: UDP, length 31
15:37:50.492777 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:50.492900 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:50.493722 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.243773 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.243897 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.243919 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.258151 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:51.258918 IP 192.168.176.20.62574 > 224.0.0.252.5355: UDP, length 24
15:37:51.669043 IP 192.168.176.20.62574 > 224.0.0.252.5355: UDP, length 24
15:37:52.007737 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:52.758825 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:55.491663 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:55.492059 IP 192.168.176.20.52682 > 224.0.0.252.5355: UDP, length 22
15:37:55.902007 IP 192.168.176.20.52682 > 224.0.0.252.5355: UDP, length 22
15:37:56.241882 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
15:37:56.991916 IP 192.168.176.20.137 > 192.168.176.255.137: UDP, length 50
Es wird also fröhlichst geNETBiost. Mehr passiert nicht. Wo hab ich jetzt den Bock in meiner Config drin?!
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
