24
PfSense - Routing zwischen zwei Interfaces
Hallo,
ich bin noch relativ unerfahren mit etwas größeren Netzwerken. Aktuell habe ich das Problem, wie man zwischen zwei Netzen bzw Interfaces routen kann.
Ich beschreibe euch erst einmal meine Konfiguration, damit ihr euch vorstellen könnt, wie mein Netz aussieht:
Folgende Situation:
Ich habe generell erst einmal zwei Netze. Einmal das WLAN-Netz mit dem Netzbereich 172.22.0.0 - 172.22.7.254. Dabei ist PfSense das Gateway für die WLAN-Clienten mit der IP 172.22.0.1 und 172.22.0.10 bis 172.22.7.254 ist der DHCP Pool von pfSense. Die WLAN Clienten müssen sich dabei über ein Captive Portal authentifizieren.
Dann habe ich noch eine Art Verwaltungsnetz (hier liegt unter anderem der RADIUS für das Captive Portal). Der Netzbereich dafür ist 172.21.11.1 - 172.21.11.254. PfSense hat mit seinem Interface im Verwaltungsnetz die 172.21.11.2 und läuft gegen das Gateway 172.21.11.1. Von da aus geht es dann weiter zum ISP.
Nun würde ich allerdings gerne, dass ich aus dem Verwaltungsnetz, sprich 172.21.11.x auf die WLAN-Router zugreifen kann, die ja nun aber im WLAN Netz liegen. Dabei bin ich mir nun unsicher, wie ich die IPs vergebe und ggf. zwischen den beiden Interfaces die Route herstelle.
Mein erster Ansatz war, die IPs der Access Points auch einfach in den Verwaltungsbereich zu legen. Einem AP habe ich die IP 172.21.11.20 gegeben, der war vom Verwaltungsbereich aus nicht erreichbar.
Mein zweiter Ansatz war, einen eigenen Netzbereich für die APs zu nehmen, also 172.22.8.1-20. Allerdings hat auch das nicht funktioniert.
Da dies mein erstes größeres Netz ist, bin ich da etwas überfragt, was hier die best practice für die IP Vergabe wäre und wie ich jetzt von einem Interface auf das andere komme, sprich, wie ich die Access Points aus dem Verwaltungsnetz konfigurieren kann.
Auf der Firewall ist auf der "WAN" Seite fast alles erlaubt, auf der "WAN" Seite blocke ich den Zugriff auf Port 22 und auf Port 8443 (meine Web-Konfigurator Ports auf den Servern) weg.
Vielen Dank im Voraus!
Mark Lukas
EDIT: Das sind meine Firewall-Regeln:
Verwaltungsnetz:
WLAN Netz:
Dazugehörige Aliases:
Floating Rules sind nicht definiert:
Die WLAN APs liegen nun im Netz 172.22.8.0/24
ich bin noch relativ unerfahren mit etwas größeren Netzwerken. Aktuell habe ich das Problem, wie man zwischen zwei Netzen bzw Interfaces routen kann.
Ich beschreibe euch erst einmal meine Konfiguration, damit ihr euch vorstellen könnt, wie mein Netz aussieht:
Folgende Situation:
Ich habe generell erst einmal zwei Netze. Einmal das WLAN-Netz mit dem Netzbereich 172.22.0.0 - 172.22.7.254. Dabei ist PfSense das Gateway für die WLAN-Clienten mit der IP 172.22.0.1 und 172.22.0.10 bis 172.22.7.254 ist der DHCP Pool von pfSense. Die WLAN Clienten müssen sich dabei über ein Captive Portal authentifizieren.
Dann habe ich noch eine Art Verwaltungsnetz (hier liegt unter anderem der RADIUS für das Captive Portal). Der Netzbereich dafür ist 172.21.11.1 - 172.21.11.254. PfSense hat mit seinem Interface im Verwaltungsnetz die 172.21.11.2 und läuft gegen das Gateway 172.21.11.1. Von da aus geht es dann weiter zum ISP.
Nun würde ich allerdings gerne, dass ich aus dem Verwaltungsnetz, sprich 172.21.11.x auf die WLAN-Router zugreifen kann, die ja nun aber im WLAN Netz liegen. Dabei bin ich mir nun unsicher, wie ich die IPs vergebe und ggf. zwischen den beiden Interfaces die Route herstelle.
Mein erster Ansatz war, die IPs der Access Points auch einfach in den Verwaltungsbereich zu legen. Einem AP habe ich die IP 172.21.11.20 gegeben, der war vom Verwaltungsbereich aus nicht erreichbar.
Mein zweiter Ansatz war, einen eigenen Netzbereich für die APs zu nehmen, also 172.22.8.1-20. Allerdings hat auch das nicht funktioniert.
Da dies mein erstes größeres Netz ist, bin ich da etwas überfragt, was hier die best practice für die IP Vergabe wäre und wie ich jetzt von einem Interface auf das andere komme, sprich, wie ich die Access Points aus dem Verwaltungsnetz konfigurieren kann.
Auf der Firewall ist auf der "WAN" Seite fast alles erlaubt, auf der "WAN" Seite blocke ich den Zugriff auf Port 22 und auf Port 8443 (meine Web-Konfigurator Ports auf den Servern) weg.
Vielen Dank im Voraus!
Mark Lukas
EDIT: Das sind meine Firewall-Regeln:
Verwaltungsnetz:
WLAN Netz:
Dazugehörige Aliases:
Floating Rules sind nicht definiert:
Die WLAN APs liegen nun im Netz 172.22.8.0/24
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: 269321
Url: https://administrator.de/contentid/269321
Printed on: April 18, 2024 at 14:04 o'clock
24 Comments
Latest comment
Hallo,
um den größten Lerneffekt zu erzeugen versuche einfach mal aus dem 172.21.11.0/24 Netz auf die APs im 172.22.0.0/24 Netz zugreifen und schau dir dabei die Logfiles der Firewall auf der pfSense an
Dann wirst du sehen wo was genau geblockt wird.
Im Prinzip musst du nur unter den FW Rules auf eth1 gehen und den Zugriff vom WAN Netz erlauben. Bedenke aber, das dann ALLE Clients aus dem 172.21.11.0/24 Netz auf das andere Netz zugreifen können. Du kannst das ganze noch über eine spezielle IP beschränken wenn du magst, dass nur ein bestimmter Client des 172.21.11.0/24 Netz ins andere Netz darf.
Gruß
um den größten Lerneffekt zu erzeugen versuche einfach mal aus dem 172.21.11.0/24 Netz auf die APs im 172.22.0.0/24 Netz zugreifen und schau dir dabei die Logfiles der Firewall auf der pfSense an
Dann wirst du sehen wo was genau geblockt wird.
Im Prinzip musst du nur unter den FW Rules auf eth1 gehen und den Zugriff vom WAN Netz erlauben. Bedenke aber, das dann ALLE Clients aus dem 172.21.11.0/24 Netz auf das andere Netz zugreifen können. Du kannst das ganze noch über eine spezielle IP beschränken wenn du magst, dass nur ein bestimmter Client des 172.21.11.0/24 Netz ins andere Netz darf.
Gruß
Danke, das ist ein gute Idee mit den Firewall Logs. Ich dachte nämlich, dass das statt geblockt nicht geroutet wird.
Auch, wenn ich eigentlich alles freigegeben hab außer Port 22 und 8443.
Ich denke, dass es ein etwas seltsames Setup bei mir ist, da man aus dem WAN Netz kommend mehr darf als im LAN Netz.
Aber zwei Fragen habe ich noch:
1. Sollte ich für den Netzbereich der APs den 172.21.11.0 Bereich oder den 172.22.0.0 Bereich verwenden? Vom administrativen her, liegen sie ja eher im Verwaltungsbereich; vom lokalen her hängen Sie ja am WLAN-Netz.
2. Ich bin mir ehrlich gesagt nicht sicher, wann ich bei der Firewall WAN und wann LAN nehmen muss, wenn ich zwischen beiden Interfaces vermitteln will.
Ich kann ja theoretisch z.B. bei LAN den Traffic-Ausgang auf Port 22 sperren oder bei WAN den Traffic-Eingang auf Port 22 sperren.
Ich denke mal, bei zwei Interfaces ist das relativ gleich oder? Das macht bestimmt erst den Unterschied, wenn man drei oder mehr Interfaces hat, je nachdem, ob man dann Port 22 komfortabel für alle Netz sperren will (dann auf LAN) Seite oder für einzelne Netze (dann jeweils auf der Netz-Eingangsseite), richtig?
Auch, wenn ich eigentlich alles freigegeben hab außer Port 22 und 8443.
Ich denke, dass es ein etwas seltsames Setup bei mir ist, da man aus dem WAN Netz kommend mehr darf als im LAN Netz.
Aber zwei Fragen habe ich noch:
1. Sollte ich für den Netzbereich der APs den 172.21.11.0 Bereich oder den 172.22.0.0 Bereich verwenden? Vom administrativen her, liegen sie ja eher im Verwaltungsbereich; vom lokalen her hängen Sie ja am WLAN-Netz.
2. Ich bin mir ehrlich gesagt nicht sicher, wann ich bei der Firewall WAN und wann LAN nehmen muss, wenn ich zwischen beiden Interfaces vermitteln will.
Ich kann ja theoretisch z.B. bei LAN den Traffic-Ausgang auf Port 22 sperren oder bei WAN den Traffic-Eingang auf Port 22 sperren.
Ich denke mal, bei zwei Interfaces ist das relativ gleich oder? Das macht bestimmt erst den Unterschied, wenn man drei oder mehr Interfaces hat, je nachdem, ob man dann Port 22 komfortabel für alle Netz sperren will (dann auf LAN) Seite oder für einzelne Netze (dann jeweils auf der Netz-Eingangsseite), richtig?
Lass dich durch den Ausdruck WAN nicht irritieren. Das ist bei dir sogar eher der "falsche" Ausdruck. WAN wäre es, wenn du die pfSense direkt am ISP Modem angeschlossen hättest, denn dann hättest du eine öffentliche IP am WAN Anschluss der pfSense.
Du kannst die zwei NICs auch LAN1 und LAN2 nennen.
Was sind das denn für APs (genaue Modellbezeichnung)?
Poste doch mal einen Screenshot deiner Rules der 2 Interfaces damit wir sehen können was du da "angestellt" hast ;)
Warum möchtest du den SSH Port speziell blocken?
Du kannst die zwei NICs auch LAN1 und LAN2 nennen.
Was sind das denn für APs (genaue Modellbezeichnung)?
Auch, wenn ich eigentlich alles freigegeben hab außer Port 22 und 8443.
Grundsätzlich ist auf der pfSense nach einer Standardinstallation erst mal ALLES geblockt auf allen Interfaces.Poste doch mal einen Screenshot deiner Rules der 2 Interfaces damit wir sehen können was du da "angestellt" hast ;)
Warum möchtest du den SSH Port speziell blocken?
Ich dachte immer, WAN bezeichnet man den Port, der am nächsten am Internet hängt. Aber gut zu wissen
PfSense fordert ja bei der Installation einen WAN-Port, da hab ich die NIC im Verwaltungsnetz angegeben.
Die APs sind Linksys WAP300N.
Genau, standardmäßig war auch alles geblockt, und ich kam von der WAN-NIC auch erstmal nicht aufs Interface.
Ich poste dir gegen 16 Uhr noch einmal alle Firewall regeln. Davor bin ich leider noch in der Uni.
SSH habe ich erstmal ganz geblockt, damit man nicht auf die Server im Verwaltungsnetz kommt.
Aber das kann ich noch verfeinern, damit das generell möglich ist, nur nicht ins Verwaltungsnetz rein.
Wie gesagt, gegen 16 Uhr kommen die Screenshots!
PfSense fordert ja bei der Installation einen WAN-Port, da hab ich die NIC im Verwaltungsnetz angegeben.
Die APs sind Linksys WAP300N.
Genau, standardmäßig war auch alles geblockt, und ich kam von der WAN-NIC auch erstmal nicht aufs Interface.
Ich poste dir gegen 16 Uhr noch einmal alle Firewall regeln. Davor bin ich leider noch in der Uni.
SSH habe ich erstmal ganz geblockt, damit man nicht auf die Server im Verwaltungsnetz kommt.
Aber das kann ich noch verfeinern, damit das generell möglich ist, nur nicht ins Verwaltungsnetz rein.
Wie gesagt, gegen 16 Uhr kommen die Screenshots!
Wie gesagt, an der Struktur des Netzes "kann" man vieles ändern wenn man denn möchte oder muss.
Um deine Frage aber zu beantworten reicht wie gesagt einfach wenn du auf eth1 (dein LAN) den Zugriff von deinem WAN Netz erlaubst.
Schon kommst du auf die APs.
Gruß
Um deine Frage aber zu beantworten reicht wie gesagt einfach wenn du auf eth1 (dein LAN) den Zugriff von deinem WAN Netz erlaubst.
Schon kommst du auf die APs.
Gruß
Das hiesige Routing Tutorial gibt dir einen Überblick über Routing Grundlagen zw. 2 und mehr Netzen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
sollte fürs Verständnis helfen und erklärt auch genau dein Szenario mit den entsprechenden ToDos (statische Routen)
Das ist kein Problem !
Wichtig ist hier WO bzw. auf welche Gateway IP zeigt das Default Gateway deines oder deiner Clients von denen du zugreifen willst ???
Auf diesem Gateway MUSS eine statische Route in das WLAN Netz eingetragen sein !!
Ist das die pfSense IP mit der .21.11.2 dann entfällt die statische Route, denn die pfSense "kennt" ja dieses IP Netz !
Ganz anders sieht es aus wenn der Internet Router mit der .21.11.1 das Default Gateway ist !
Wenn der ein Paket mit der Zieladresse 172.22.0.0 /24 sieht, und die statische Route in das WLAN Netzwerk fehlt routet er das zu seiner Default Route und das ist der Internet Provider. Da deine 172er Netze private RFC 1918 IP sind schmeisst der Privider diese Pakete in seinen Filterlisten sofort wech...
Frage also: Hast du diese statische Route gesetzt sollte der Router Default Gateway sein ?
Der pfSense reicht eine Default Route auf die .21.11.1 !
Achtung für den Zugriff auf die APs hinter dem Captive Portal ist das aber nur die halbe Miete, denn dort gelten noch besondere zusätzliche Regeln !!!
Wenn du die Firewall Regeln in der pfSense entsprechend angepasst hast das du aus dem .21.11.0er Netz auf das. .22.0.0er Netz zugreifen kannst ist das schon mal der erste Schritt. Das testest du indem du das Captive Portal einmal temporär im Setup deaktivierst. Wenn der Zugriff klappt stimmen die Regeln.
Ist das Portal aber nun aktiv kommen die Pakete an den APs zwar an aus deinem netz, die Antwortpakete der APs aus dem WLAN Netz bleiben aber logischerweise am Portal hängen weil sie NICHT authentisiert sind ! Logisch....
Das kann man aber schnell fixen....
Notiere dir die Mac Adressen der einzelnen APs. Die findest du aufgedruckt auf dem Typenschild oder auch in der Mac Liste der pfSense.
Dann gehst du ins Cpative Portal Setup und klickst auf den Punkt wo du Mac Adressen eintragen kannst die von der Captive Portal Authentisierung ausgenommen sind. Damit können diese Macs dann das Portal problemlos passieren und alles ist gut.
So einfach ist das
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
sollte fürs Verständnis helfen und erklärt auch genau dein Szenario mit den entsprechenden ToDos (statische Routen)
Nun würde ich allerdings gerne, dass ich aus dem Verwaltungsnetz, sprich 172.21.11.x auf die WLAN-Router zugreifen kann,
Du meinst sicher die WLAN Accesspoints, oder ?Das ist kein Problem !
Wichtig ist hier WO bzw. auf welche Gateway IP zeigt das Default Gateway deines oder deiner Clients von denen du zugreifen willst ???
Auf diesem Gateway MUSS eine statische Route in das WLAN Netz eingetragen sein !!
Ist das die pfSense IP mit der .21.11.2 dann entfällt die statische Route, denn die pfSense "kennt" ja dieses IP Netz !
Ganz anders sieht es aus wenn der Internet Router mit der .21.11.1 das Default Gateway ist !
Wenn der ein Paket mit der Zieladresse 172.22.0.0 /24 sieht, und die statische Route in das WLAN Netzwerk fehlt routet er das zu seiner Default Route und das ist der Internet Provider. Da deine 172er Netze private RFC 1918 IP sind schmeisst der Privider diese Pakete in seinen Filterlisten sofort wech...
Frage also: Hast du diese statische Route gesetzt sollte der Router Default Gateway sein ?
Der pfSense reicht eine Default Route auf die .21.11.1 !
Achtung für den Zugriff auf die APs hinter dem Captive Portal ist das aber nur die halbe Miete, denn dort gelten noch besondere zusätzliche Regeln !!!
Wenn du die Firewall Regeln in der pfSense entsprechend angepasst hast das du aus dem .21.11.0er Netz auf das. .22.0.0er Netz zugreifen kannst ist das schon mal der erste Schritt. Das testest du indem du das Captive Portal einmal temporär im Setup deaktivierst. Wenn der Zugriff klappt stimmen die Regeln.
Ist das Portal aber nun aktiv kommen die Pakete an den APs zwar an aus deinem netz, die Antwortpakete der APs aus dem WLAN Netz bleiben aber logischerweise am Portal hängen weil sie NICHT authentisiert sind ! Logisch....
Das kann man aber schnell fixen....
Notiere dir die Mac Adressen der einzelnen APs. Die findest du aufgedruckt auf dem Typenschild oder auch in der Mac Liste der pfSense.
Dann gehst du ins Cpative Portal Setup und klickst auf den Punkt wo du Mac Adressen eintragen kannst die von der Captive Portal Authentisierung ausgenommen sind. Damit können diese Macs dann das Portal problemlos passieren und alles ist gut.
So einfach ist das
Ich habe im Originalpost meine FW-Konfiguration hinzugefügt.
Es ist wie gesagt alles auf erlaubt gestellt. Einige Regeln habe ich zu Testzwecken deaktiviert, aber es geht dennoch nicht.
@aqui: Muss ich dann im Zentyal (siehe Netzdiagramm) die statische Route setzen? Zentyal ist der DHCP für die Verwaltungsnetzclients.
Es ist wie gesagt alles auf erlaubt gestellt. Einige Regeln habe ich zu Testzwecken deaktiviert, aber es geht dennoch nicht.
@aqui: Muss ich dann im Zentyal (siehe Netzdiagramm) die statische Route setzen? Zentyal ist der DHCP für die Verwaltungsnetzclients.
Zentyal ist der DHCP für die Verwaltungsnetzclients.
Bitte lies den Post genau ! Der DHCP Server bzw. dessen IP ist vollkommen uninteressant, denn der speilt ja fürs Routing sprich die Wegefindung keinerlei Rolle es sei denn er ist gleichzeitig auch Router !Relevant ist NUR das Gateway sprich also das Gerät was die Clients mit denen du ins WLAN Netz willst im Zentyal Netz als Default Gateway eingetragen haben !!
Denn dort muss die statische Route ins 172.22.0.0er Netz konfiguriert sein via next Hop pfSense.
Ist sie das nicht geht sie den Weg der Default Route und dann vermutlich ins Nirwana !
Warum machst du von einem dieser Clients mit demdu zugreifen willst nicht mal ein traceroute 172.22.0.x wobei x eine IP aus dem AP Netzwerk ist ?! (tracert bei Winblows)
Da siehst du dann doch genau die Hops die ein Paket von der Quelle zum Ziel nimmt !
Zitat von @aqui:
Bitte lies den Post genau ! Der DHCP Server bzw. dessen IP ist vollkommen uninteressant, denn der speilt ja fürs Routing
sprich die Wegefindung keinerlei Rolle es sei denn er ist gleichzeitig auch Router !
Relevant ist NUR das Gateway sprich also das Gerät was die Clients mit denen du ins WLAN Netz willst im Zentyal Netz als
Default Gateway eingetragen haben !!
Bitte lies den Post genau ! Der DHCP Server bzw. dessen IP ist vollkommen uninteressant, denn der speilt ja fürs Routing
sprich die Wegefindung keinerlei Rolle es sei denn er ist gleichzeitig auch Router !
Relevant ist NUR das Gateway sprich also das Gerät was die Clients mit denen du ins WLAN Netz willst im Zentyal Netz als
Default Gateway eingetragen haben !!
Das Standardgateway im Zentyal ist eth0, also das Gateway in Richtung ISP.
PfSense kennt zwei Gateways, GW_WAN (Richtung Verwaltungsnetz) und GW_LAN (Richtung WLAN NETZ), wobei GW_WAN das Default Gateway ist.
Da mein Laptop dabei Zentyal (172.21.11.1) als Standard-Gateway hat, muss ich denke ich da ran.
Also muss ich denke ich bei Zentyal aus eth1 ein Gateway machen (ist im Moment nur eine NIC mit statischer IP) und dann eine Statische Route auf 172.22.8.0/24 über eth1 setzen. Wäre mein Gedanke richtig?
Das Standardgateway im Zentyal ist eth0, also das Gateway in Richtung ISP.
OK, sorry das hatte ich missverstanden.OK, wenn der Zentyal der Router ist braucht der natürlich die statische Route !
Ist das Unix oder Winblows ?
Bei Unix ist das dann:
ip route add 172.22.0.0/24 via 172.21.11.2 dev eth1
oder in der alten Notation:
route add -net 172.22.0.0 netmask 255.255.255.0 gw 172.21.11.2 dev eth1
Bei Winblows dann entsprechend:
route add 172.22.0.0 mask 255.255.255.0 172.21.11.2 -p
pfSense hat lediglich ein Default Gateway bzw. default Route eingetragen was du im Menü System --> Routing einträgst und in der Interface -> WAN IP Konfiguration unter IPv4 Upstream Gateway aktivierst.
Das wars....
Da mein Laptop dabei Zentyal (172.21.11.1) als Standard-Gateway hat, muss ich denke ich da ran.
Ja, ganz genau...siehe oben !Also muss ich denke ich bei Zentyal aus eth1 ein Gateway machen
Das ist natürlich Unsinn oder etwas unbeholfen formuliert, denn der Tentyal ist ja schon Gateway durch seine 2 NICs und das aktive Routing Wäre mein Gedanke richtig?
Absolut richtig !Vergiss nicht die Mac Adressen der APs im Captive Portal freizuschalten, sonst ist das der nächste Punkt wo du scheiterst.
1Zitat von @aqui:
> Also muss ich denke ich bei Zentyal aus eth1 ein Gateway machen
Das ist natürlich Unsinn oder etwas unbeholfen formuliert, denn der Tentyal ist ja schon Gateway durch seine 2 NICs und das
aktive Routing
> Also muss ich denke ich bei Zentyal aus eth1 ein Gateway machen
Das ist natürlich Unsinn oder etwas unbeholfen formuliert, denn der Tentyal ist ja schon Gateway durch seine 2 NICs und das
aktive Routing
Das habe ich eigentlich absichtlich gefragt
Ich versuche mal zu beschreiben, wieso:Bei Zentyal (linuxbasiert) ist eth0 das Standardgateway Richtung ISP. Eth1 ist dagegen ja die NIC mit der statischen IP 172.21.11.1 konfiguriert.
Nun kann ich im Zentyal aber keine Statische Route auf eth1 oder auf 172.21.11.1 setzen, sondern muss den Namen eines Gateways angeben.
Will ich ein neues Gateway erstellen und das auf die NIC eth1 mit der gleichen IP 172.21.11.1 setzen, sagt mir Zentyal, dass die IP bereits für eth1 vergeben ist.
Zentyal zwingt mich quasi, die Konfiguration für eth1 auf "unset" zu setzen, damit ich überhaupt aus dem Interface ein Gateway (und darauf dann eine statische Route) machen kann.
Ich könnte es höchstens versuchen, mit SSH und "ip route add ..." Zentyal zu umgehen.
Zentyal unterscheidet also scheinbar explizig explizit zwischen NIC mit IP-Adresse und einem Gateway. Eine NIC lässt sich auch so einfach nicht zu Gateway machen. Hab ich irgendwelche Nachteile daraus, wenn ich aus der NIC ein Gateway mache?
Ein Interface kann ja nie per se ein "Gateway" sein in dem Sinne. Ein Gateway ist ein Router mit n>1 Interfaces.
Aber wollen wir jetzt mal nicht über die Syntax streiten sondern zur Lösung kommen.
Quasi hast du also sowas:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Nur eben am einen Ende noch mit einer Kaskade, sprich pfSense mehr, richtig ?!
Wie gesagt...muss nicht sein !
Oder hast du ein Klicki Bunti Interface und arbeitest gar nicht auf der Unix Shell ?? Dann musst du eben mit dem leben was dein Zenturio da so will.
Du HAST doch schon 3 (drei) Gateways:
Die 2 relevanten Angaben in einer Route (oder bei deinem Zenturio dann eben das "Gateway" wenn er es so unbedingt nennen will) ist IMMER das Zielnetz und der Next Hop dahin ! Fertig.
Bei dir wäre das dann:
Eigentlich doch ganz einfach und logisch, oder ?
Geh doch auf die Unix Shell und mach dem Drama mit einer klassischen statischen Route, so wie es sich gehört unter Admins, ein Ende.
Aber wollen wir jetzt mal nicht über die Syntax streiten sondern zur Lösung kommen.
Quasi hast du also sowas:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Nur eben am einen Ende noch mit einer Kaskade, sprich pfSense mehr, richtig ?!
Nun kann ich im Zentyal aber keine Statische Route auf eth1 oder auf 172.21.11.1 setzen, sondern muss den Namen eines Gateways angeben.
Auch das ist Unsinn, denn statt Namen kann man auch eine IP Adresse nehmen. Ansonsten trägst du halt in die /etc/hosts Datei statisch deinen "Namen" zur IP ein und nimmst dann den Namen wenn du unbedingt willst.Wie gesagt...muss nicht sein !
Oder hast du ein Klicki Bunti Interface und arbeitest gar nicht auf der Unix Shell ?? Dann musst du eben mit dem leben was dein Zenturio da so will.
Will ich ein neues Gateway erstellen und das auf die NIC eth1
Heul...schon wieder diese komische Wortwahl zum Gateway Du HAST doch schon 3 (drei) Gateways:
- Dein Internet ISP Router
- Dein Zentyal der routet und damit Gateway ist
- die pfSense
das auf die NIC eth1 mit der gleichen IP 172.21.11.1 setzen, sagt mir Zentyal, dass die IP bereits für eth1 vergeben ist.
Das ist ja auch klar ! Vermutlich "meint" dein komischer Zentyal Zenturio damit die next Hop IP Adresse oder das Zielnetz. Das kann man jetzt von der Ferne nicht raten.Die 2 relevanten Angaben in einer Route (oder bei deinem Zenturio dann eben das "Gateway" wenn er es so unbedingt nennen will) ist IMMER das Zielnetz und der Next Hop dahin ! Fertig.
Bei dir wäre das dann:
- Ziel: 172.22.0.0 mit der Maske: 255.255.255.0
- Next Hop 172.21.11.2 (die pfSense)
Eigentlich doch ganz einfach und logisch, oder ?
für eth1 auf "unset" zu setzen, damit ich überhaupt aus dem Interface ein Gateway
Das ist doch krank... Aus einem Interface kann man kein Gateway machen....aber egal.Geh doch auf die Unix Shell und mach dem Drama mit einer klassischen statischen Route, so wie es sich gehört unter Admins, ein Ende.
Ich versuch es morgen einfach mal ohne dieses Klickibunti Interface mit "ip route add 172.22.8.0/24 via 172.21.11.2" in der Shell.
Aber ich danke dir für deine Antwort. Die Route wird der ausschlaggebende Punkt gewesen sein
Aber ich danke dir für deine Antwort. Die Route wird der ausschlaggebende Punkt gewesen sein
Nicht nur wird, sie ist es ganz sicher
Ein ip route show oder netstat -r zeigt dir die aktuelle Routing Tabelle der Kiste.
OK, dann harren wir morgen mal der Dinge....
Ein ip route show oder netstat -r zeigt dir die aktuelle Routing Tabelle der Kiste.
OK, dann harren wir morgen mal der Dinge....
Ich hab die statische Route gesetzt und die APs gewhitelistet, allerdings funktioniert es immer noch nicht. pfSense selbst kann nicht mal die APs anpingen.
Ein Ping auf einen AP ergibt:
<code type="plain">
PING 172.22.8.13 (172.22.8.13): 56 data bytes
36 bytes from 172.21.11.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 a476 0 0000 01 01 a9f8 172.21.11.2 172.22.8.13
92 bytes from zentyal.verwaltungsnetz.meinprojekt.de (172.21.11.1): Redirect Host(New addr: 172.21.11.2)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 80ac 0 0000 3f 01 8fc2 172.21.11.2 172.22.8.13
36 bytes from 172.21.11.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 80ac 0 0000 01 01 cdc2 172.21.11.2 172.22.8.13
92 bytes from zentyal.verwaltungsnetz.meinprojekt.de (172.21.11.1): Redirect Host(New addr: 172.21.11.2)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 7a2f 0 0000 3f 01 963f 172.21.11.2 172.22.8.13
36 bytes from 172.21.11.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 7a2f 0 0000 01 01 d43f 172.21.11.2 172.22.8.13
--- 172.22.8.13 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
PfSense sendet also - obwohl die APs direkt am Interface eth1 anliegen - den Ping request über das Default Gateway. Sollte pfSense nicht wenigstens die Route kennen?
Das sind die Gateways:
(WAN_DHCP heißt nur aus historischen Gründen so. Das Interface hat natürlich eine statische IP)
Ein Ping auf einen AP ergibt:
<code type="plain">
PING 172.22.8.13 (172.22.8.13): 56 data bytes
36 bytes from 172.21.11.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 a476 0 0000 01 01 a9f8 172.21.11.2 172.22.8.13
92 bytes from zentyal.verwaltungsnetz.meinprojekt.de (172.21.11.1): Redirect Host(New addr: 172.21.11.2)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 80ac 0 0000 3f 01 8fc2 172.21.11.2 172.22.8.13
36 bytes from 172.21.11.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 80ac 0 0000 01 01 cdc2 172.21.11.2 172.22.8.13
92 bytes from zentyal.verwaltungsnetz.meinprojekt.de (172.21.11.1): Redirect Host(New addr: 172.21.11.2)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 7a2f 0 0000 3f 01 963f 172.21.11.2 172.22.8.13
36 bytes from 172.21.11.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 7a2f 0 0000 01 01 d43f 172.21.11.2 172.22.8.13
--- 172.22.8.13 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
PfSense sendet also - obwohl die APs direkt am Interface eth1 anliegen - den Ping request über das Default Gateway. Sollte pfSense nicht wenigstens die Route kennen?
Das sind die Gateways:
Pingst du die IP 172.22.8.13?? Das ist doch wieder ein komplett anderes Netz das keines deiner Geräte kennt oder täusch ich mich?
Deswegen war ja meine Frage, in welchen IP Bereich ich die APs legen soll. Ich hab sie jetzt in den 172.22.8.0/24er Bereich gesteckt.
Aber du hast Recht.
Ich denke, ich lege die APs sonst in den 172.22.7.240-250er Bereich und reduziere entsprechend den DHCP Pool für den WLAN Clienten. Denn das Netz (172.22.0.0/21) sollte auf jeden Fall bekannt sein.
Ich dachte, pfSense würde alle direkt anliegenden Netze/IPs erkennen, also auch das 172.22.8.0er Netz.
Aber du hast Recht.
Ich denke, ich lege die APs sonst in den 172.22.7.240-250er Bereich und reduziere entsprechend den DHCP Pool für den WLAN Clienten. Denn das Netz (172.22.0.0/21) sollte auf jeden Fall bekannt sein.
Ich dachte, pfSense würde alle direkt anliegenden Netze/IPs erkennen, also auch das 172.22.8.0er Netz.
pfSense selbst kann nicht mal die APs anpingen.
Dann hast du vermutlich wohl wie immer das Default Gateway vergessen auf den APs einzutragen !!Die Default Gateway IP der APs MUSS auf die pfSense IP im Segment zeigen.
Zusätzlich ist möglich das di in den Firewall Rules an diesem Segment vergessen hast ICMP zu erlauben. Ohne das schlägt ein Ping natürlich logischerweise fehl ! (Ping nutzt ICMP !)
ICMP zu blocken ist auf einem Gastnetz durchaus sinnvoll um Spielkindern unter den Gästen nicht gleich die Netzwerkinfrstruktur mit Pingen zu zeigen !
PfSense sendet also - obwohl die APs direkt am Interface eth1 anliegen - den Ping request über das Default Gateway.
Nein, das ist Blödsinn. Die FW versucht einen ICMP Redirect auf den anderen Router aber der schlägt fehl. Vermutlich weil der das blockt oder kein Redirect erlaubt oder sehr wahrscheinlich weil du am Interface ICMP verboten hast ?!Das sind die Gateways:
Das ist ja Schwachsinn, sorry aber WOZU brauchst du 2 Gateways auf der pfSense. Die "sieht" doch nach deiner Zeichnung oben nur ein einziges Gateway den Zentyal mit der IP 172.21.11.1 der ja auch richtigerweise als Default Route eingetragen ist.Die andere Route ist kompletter Blödsinn da "routest" du das WLAN Netz 172.22.0.0 auf sich selber mit next Hop 172.22.0.1.
Den Unsinn muss man wohl nicht weiter kommentieren
Die pfSense KENNT logischerweise alle IP Netze die an ihr selber direkt angeschlossen sind. WOZU also da noch Routen auf sich selbst ??
Kollege michi1983 hat da also genau richtig gedacht !
Fazit: Sofort löschen den Blödsinn ! Es bleibt einzig nur die Default Route auf den Zentyal !
Allerdings.... WIE bitte kommst du auf ein 172.22.7.0 oder 172.22.8.0 Netz ??? WO bitte kommen diese Netze her ? Das WLAN Netz mit den APs ist laut Zeichnung des TOs oben ein 172.22.0.0 Netz mit einer 24 Bit Maske ?! Oder...??
(WAN_DHCP heißt nur aus historischen Gründen so. Das Interface hat natürlich eine statische IP)
Und warum benamst du es dann nicht um in den Interface Beschreibungen ? Das ist in 10 Sekunden mit einem Mausklick erledigt...ok ist ja nur kosmetisch Zitat von @aqui:
> pfSense selbst kann nicht mal die APs anpingen.
Dann hast du vermutlich wohl wie immer das Default Gateway vergessen auf den APs einzutragen !!
Die Default Gateway IP der APs MUSS auf die pfSense IP im Segment zeigen.
> pfSense selbst kann nicht mal die APs anpingen.
Dann hast du vermutlich wohl wie immer das Default Gateway vergessen auf den APs einzutragen !!
Die Default Gateway IP der APs MUSS auf die pfSense IP im Segment zeigen.
Ich glaube, das ist gut möglich. Das Default Gateway wäre für Sie ja die 172.22.0.1 oder? Also das Interface auf der WLAN-Seite.
Aber kennen die APs nicht sowieso pfSense als Default Gateway? Da hängt ja nichts weiter dran.
Zusätzlich ist möglich das di in den Firewall Rules an diesem Segment vergessen hast ICMP zu erlauben. Ohne das
schlägt ein Ping natürlich logischerweise fehl ! (Ping nutzt ICMP !)
ICMP zu blocken ist auf einem Gastnetz durchaus sinnvoll um Spielkindern unter den Gästen nicht gleich die
Netzwerkinfrstruktur mit Pingen zu zeigen !
schlägt ein Ping natürlich logischerweise fehl ! (Ping nutzt ICMP !)
ICMP zu blocken ist auf einem Gastnetz durchaus sinnvoll um Spielkindern unter den Gästen nicht gleich die
Netzwerkinfrstruktur mit Pingen zu zeigen !
Generell ist erstmal alles zugelassen, um zu gucken, dass ich das Netz wie gewünscht zum laufen bringen kann (siehe Screenshots in den allerersten Posts).
Wenn das läuft, werde ich entsprechende Ports und Dienste wie ICMP dicht machen.
> PfSense sendet also - obwohl die APs direkt am Interface eth1 anliegen - den Ping request über das Default Gateway.
Nein, das ist Blödsinn. Die FW versucht einen ICMP Redirect auf den anderen Router aber der schlägt fehl. Vermutlich
weil der das blockt oder kein Redirect erlaubt oder sehr wahrscheinlich weil du am Interface ICMP verboten hast ?!
> Das sind die Gateways:
Das ist ja Schwachsinn, sorry aber WOZU brauchst du 2 Gateways auf der pfSense. Die "sieht" doch nach deiner Zeichnung
oben nur ein einziges Gateway den Zentyal mit der IP 172.21.11.1 der ja auch richtigerweise als Default Route eingetragen ist.
Nein, das ist Blödsinn. Die FW versucht einen ICMP Redirect auf den anderen Router aber der schlägt fehl. Vermutlich
weil der das blockt oder kein Redirect erlaubt oder sehr wahrscheinlich weil du am Interface ICMP verboten hast ?!
> Das sind die Gateways:
Das ist ja Schwachsinn, sorry aber WOZU brauchst du 2 Gateways auf der pfSense. Die "sieht" doch nach deiner Zeichnung
oben nur ein einziges Gateway den Zentyal mit der IP 172.21.11.1 der ja auch richtigerweise als Default Route eingetragen ist.
Hmm das stimmt wohl. pfSense hat bei der Installation direkt ein Gateway draus gemacht. Nach meinem jetztigen Verständnis von Gateway hast du aber Recht, das sollte weg können.
Die andere Route ist kompletter Blödsinn da "routest" du das WLAN Netz 172.22.0.0 auf sich selber mit next Hop
172.22.0.1.
Den Unsinn muss man wohl nicht weiter kommentieren
Die pfSense KENNT logischerweise alle IP Netze die an ihr selber direkt angeschlossen sind. WOZU also da noch Routen auf sich
selbst ??
172.22.0.1.
Den Unsinn muss man wohl nicht weiter kommentieren
Die pfSense KENNT logischerweise alle IP Netze die an ihr selber direkt angeschlossen sind. WOZU also da noch Routen auf sich
selbst ??
Um ein Missverständnis zu vermeiden: Ich habe die Route auf Zentyal gesetzt mit
ip route add 172.22.8.0/24 via 172.21.11.2
Allerdings konnte ich von dort aus die APs immer noch nicht erreichen oder pingen. Deswegen hab ich mit der Diagnosefunktion von pfSense gepingt, ob man wenigstens von da aus die APs erreichen kann, was aber auch nicht der Fall war. Die Route selbst liegt auf Zentyal.
Kollege michi1983 hat da also genau richtig gedacht !
Fazit: Sofort löschen den Blödsinn ! Es bleibt einzig nur die Default Route auf den Zentyal !
Fazit: Sofort löschen den Blödsinn ! Es bleibt einzig nur die Default Route auf den Zentyal !
Also doch die eben genannte Route löschen?
Oder meinst du jetzt noch was anderes, was ich gerade nicht verstehe?
Allerdings.... WIE bitte kommst du auf ein 172.22.7.0 oder 172.22.8.0 Netz ??? WO bitte kommen diese Netze her ? Das WLAN
Netz mit den APs ist laut Zeichnung des TOs oben ein 172.22.0.0 Netz mit einer 24 Bit Maske ?! Oder...?
Netz mit den APs ist laut Zeichnung des TOs oben ein 172.22.0.0 Netz mit einer 24 Bit Maske ?! Oder...?
Nein, das ist eine /21 er Maske. Ich hab gehofft, das geht aus
[...] "Einmal das WLAN-Netz mit dem Netzbereich 172.22.0.0 - 172.22.7.254" [...]
hervor. Sorry, wenn ich da ungenau war
Ich wollte die APs in ein anderes Subnetz legen als die Clienten, damit diese da nicht drauf zugreifen können.
> (WAN_DHCP heißt nur aus historischen Gründen so. Das Interface hat natürlich eine statische IP)
Und warum benamst du es dann nicht um in den Interface Beschreibungen ? Das ist in 10 Sekunden mit einem Mausklick erledigt...ok
ist ja nur kosmetisch
Und warum benamst du es dann nicht um in den Interface Beschreibungen ? Das ist in 10 Sekunden mit einem Mausklick erledigt...ok
ist ja nur kosmetisch
Hast Recht, sollte ich mal überarbeiten. Spätestens, wenn der nächste da reinguckt, weiß der sonst nicht mehr Bescheid
Das Default Gateway wäre für Sie ja die 172.22.0.1 oder?
Bingo !Aber kennen die APs nicht sowieso pfSense als Default Gateway?
Nein, nur wenn du denen auch dynamische IP Adressen per DHCP verteilst. Für die APs in einem Gastnetz erheblich kontraproduktiv.Deren Adressierung sollte immer statisch sein wie allgemein üblich beim Management von Infrastruktur Komponenten. Oder...
Wenn du DHCP nimmst dann vergib ihnen über den pfSense DHCP Server immer eine feste IP auf Basis ihrer Mac Adresse. Der pfSense DHCP Server supportet das !
Infrastruktur Komponenten haben immer statische IPs oder DHCP "nailed" IPs mit der Mac. Für die IP Firewall Rules sind statische IPs da wichtig.
Generell ist erstmal alles zugelassen, um zu gucken, dass ich das Netz wie gewünscht zum laufen bringen kann
Das ist auch genau richtig von der Vorgehensweise, keine Frage.Deine "Deny SSH for WLAN Clients" Regel ist aber unsinnig. Den als Source any und als Desination "WLAN" bringt nix.
Du begehst hier vermutlich einen Denkfehler im Regelwerk.
Die FW Regeln gelt NUR inbound also alles was IN das FW Interface reinläuft. Nicht outbound.
Außerdem gilt "First Match wins!". Greift also in einem Regelwerk einen Regel werden die folgenden NICHT mehr abgearbeitet. In so fern zählt also auch Reihenfolge.
Zurück zum fehlgeschlagenen Ping bedeutet das dann wirklich das das Default Gateway in den APs fehlt dann.
pfSense hat bei der Installation direkt ein Gateway draus gemacht.
Sorry, aber ganz sicher NICHT ! So einen Blödsinn macht die FW von sich aus nicht freiwillig, das hast ganz klar du verbockt beim Setup !! Das sollte nicht nur weg sondern MUSS weg.
Um ein Missverständnis zu vermeiden: Ich habe die Route auf Zentyal gesetzt mit
ip route add 172.22.8.0/24 via 172.21.11.2
Mmmhh...entweder hast du oben FALSCH gezeichnet oder du verar.... uns jetzt hier alle ip route add 172.22.8.0/24 via 172.21.11.2
Oben steht doch ganz klar das dein WLAN Netz das 172.22.0.0 /24 ist ?!
Warum also trägst du dann eine vollkommen falsche Route in den Zentyal ein ? Völlig unverständlich oder hast du dafür eine plausible Erklärung ?
Richtig wäre nach deiner Zeichnung ip route add 172.22.0.0/24 via 172.21.11.2
Also doch die eben genannte Route löschen?
Ruhig Blut... jetzt nichts durcheinanderbringen und bitte einmal logisch nachdenken...- 1.) In der pfSense die WLAN Route auf sich selbst löschen. Nur die Default Route auf die 172.21.11.1 (Zentyal) bleibt.
- 2.)
Zentyal statische Route auf 172.22.8.0/24 löschen, denn das Netz gibts doch nirgendwo, oder ? - 3.)
Zentyal statische Route ip route add 172.22.0.0/24 via 172.21.11.2 einrichten sofern das .0. Netz nun final richtig ist (Verwirrung?)
Nein, das ist eine /21 er Maske. Ich hab gehofft, das geht aus
Oh mann... das hättest aber auch mal eher sagen können Grrrr... >Also dann nochmal von vorne...
- 1.) In der pfSense die WLAN Route auf sich selbst löschen. Nur die Default Route auf die 172.21.11.1 (Zentyal) bleibt.
- 2.) Zentyal statische Route auf 172.22.8.0/24 löschen, denn das Netz gibts doch nirgendwo und auf 172.22.0.0/21 ändern.
- 3.) Zentyal statische Route ip route add 172.22.0.0/21 via 172.21.11.2 einrichten.
- 4.) Achte darauf das auch die pfSense Interface Maske auf /21 eingestellt ist.
ACHTUNG bei der Adressierung mit der 21er Maske !
Das .0.0er Netz geht von 172.22.0.1 bis 172.22.7.254
Das .0.8er Netz geht von 172.22.8.1 bis 172.22.15.254
Pass also auf je nach Host Adressierung in dem WLAN Netz WELCHES Netz du da routest. Sollte es doch das 8.0er Netzsein muss die Route oben natürlich dann
ip route add 172.22.8.0/21 via 172.21.11.2
Dann muss die pfSense Adressierung sowie alle Clients und APs aber im Bereich 172.22.8.1 bis 172.22.15.254 liegen...klar.
Ich wollte die APs in ein anderes Subnetz legen als die Clienten, damit diese da nicht drauf zugreifen können.
Das geht IP routingtechnisch nicht oder nur mit erheblichen Klimmzügen die deine HW nicht supportet und zudem nicht standardkonform ist ! Wie willst du denn auf einem gemeinsamen Draht 2 IP Netze routen ?Vergiss das also...
So nun aber ! Änderungen machen und wenns dann nicht geht kostet es hier aber extra....
Zitat von @aqui:
> pfSense hat bei der Installation direkt ein Gateway draus gemacht.
Sorry, aber ganz sicher NICHT ! So einen Blödsinn macht die FW von sich aus nicht freiwillig, das hast ganz klar du verbockt
beim Setup !!
> pfSense hat bei der Installation direkt ein Gateway draus gemacht.
Sorry, aber ganz sicher NICHT ! So einen Blödsinn macht die FW von sich aus nicht freiwillig, das hast ganz klar du verbockt
beim Setup !!
Sorry, mein Fehler, du hast Recht. Ich hab den Fehler vor drei Jahren gemacht (als das Netz entworfen wurde) und bis dato keine Probleme gehabt, daher ist mir das nie aufgefallen.
Ich hab gerade in meine Doku geguckt und - lach mich jetzt bitte nicht aus - das GW_LAN mit "GW_LAN ist das Gateway, das die WLAN-Clienten nutzen" kommentiert. Ich dachte also, man muss noch einmal ein Gateway definieren, an das alle WLAN Clienten senden. Quasi instream. Dass man natürlich nur ein Upstream Gateway definiert, wird mir gerade klar.
Ich lösche das Gateway einfach und hoffe, dass pfSense nicht gleich die ganze IP-Konfiguration etc. mit wegnimmt.
> Um ein Missverständnis zu vermeiden: Ich habe die Route auf Zentyal gesetzt mit
> ip route add 172.22.8.0/24 via 172.21.11.2
Mmmhh...entweder hast du oben FALSCH gezeichnet oder du verar.... uns jetzt hier alle
> ip route add 172.22.8.0/24 via 172.21.11.2
Mmmhh...entweder hast du oben FALSCH gezeichnet oder du verar.... uns jetzt hier alle
Nein, verarschen will ich hier keinen. Wie beschrieben habe ich gedacht, dass ich das Netz für die Access Points in ein ganz anderes Subnetz packen kann. Mein Denkansatz war quasi:
172.22.0.0/21 -> DHCP Subnetz für WLAN Clienten (von 0.1 bis 7.254)
172.22.8.0/24 -> Statisches Subnetz für Access Points
Ich wusste eben gerade nicht, dass
Wie willst du denn auf einem gemeinsamen Draht 2 IP Netze routen ?
genau das nicht geht. Ich dachte, man kann zwei Subnetze auf einem Interface durch Routing verwalten. Ist aber ok, ich werde einfach das 172.22.0.0/21 Netz nehmen und einen Teil davon für die APs reservieren.Warum also trägst du dann eine vollkommen falsche Route in den Zentyal ein ? Völlig unverständlich oder hast du
dafür eine plausible Erklärung ?
dafür eine plausible Erklärung ?
Eben weil ich das mit den zwei Subnetzen dachte
Also ist jetzt mein Ansatz erstmal:
1. das GW_LAN auf pfSense wegnehmen
2. In die APs 172.22.0.1/21 als Default Gateway eintragen
3. Den DHCP Pool auf z.B. 172.22.0.50 - 172.22.7.254 beschränken und den Bereich172.22.0.10 - 172.22.0.49 für die APs verwenden
3. Auf Zentyal ip route del 172.22.8.0/24 via 172.21.11.2 ausführen
4. Auf Zentyal ip route add 172.22.0.0/21 via 172.21.11.2 ausführen
Aber darf ich noch eine (dumme) Frage stellen?
Was passiert, wenn man das GW_LAN im pfSense lassen würde? An sich sendet pfSense doch alles ans Default Gateway und verwendet das GW_LAN doch gar nicht oder?
Ein schönes Wochenende wünsch ich dir dann und danke für deine Hilfe und Nerven
das GW_LAN mit "GW_LAN ist das Gateway, das die WLAN-Clienten nutzen" kommentiert. Ich dachte also
Arrrgghh... da musste ich das Lachen aber schon stark unterdrücken... Also nicht denken sondern immer "nachdenken"...
Dass man natürlich nur ein Upstream Gateway definiert, wird mir gerade klar.
Das ist gut und der Lerneffekt ist ja eh unbezahlbar Ich lösche das Gateway einfach und hoffe, dass pfSense nicht gleich die ganze IP-Konfiguration etc. mit wegnimmt.
Gut so ! Und nein...natürlich tut es das nicht. Du hast ja eine intelligente Firewall !Also ist jetzt mein Ansatz erstmal:
Und der ist auch richtig mit Ausnahme des etwas irren DHCP Pools aber nundenn...Den DHCP Pool auf z.B. 172.22.0.50 - 172.22.7.254 beschränken
Wow...alter Schwede ! ganze 1974 Clients willst du im WLAN Netz bedienen mit nur einer Handvoll APs... Respekt ?? Sorry, aber das ist in einer L2 Domain schon wieder Blödsinn.Aber natürlich machbar wenn man nicht weiss was man tut
Aber darf ich noch eine (dumme) Frage stellen?
Gibts ja nicht, nur dumme Antworten also muss ICH mich vorsehen Die Antwort lautet: Vermutlich gar nichts. Da du aber nicht wissen kannst wie sich ein Amok laufender Routig Prozess mit sowas mal gebiert gilt: WEG DAMIT !
Ebenso schönes Wochenende
Aqui, ich möchte mich bedanken, mit der Route funktioniert es
Allerdings habe ich noch eine Frage: Ich kann die APs problemlos erreichen und konfigurieren, wenn die Clienten aus dem Verwaltungsnetz eine Adresse via DHCP bekommen haben. Haben Sie eine statische Adresse im Verwaltungsnetz bekommen, kann ich sie zwar anpingen und teilweise mit tracert erreichen, allerdings erreiche ich das Webinterface nicht.
Beispielkonfiguration Latop mit statische IP:
IP: 172.21.11.8
Subnetz: 255.255.248.0
Gateway: 172.21.11.1
Ein Ping auf auf den AP mit der IP 172.22.0.20 geht problemlos durch, ein tracert sieht so aus:
Das ist ehrlich gesagt das erste Mal, dass ich den Fall habe, dass der tracert eine Zeitüberschreitung anzeigt, dennoch aber ankommt.
Von Zentyal aus funktioniert das tracert auf die APs ohne Probleme.
Bei den via DHCP konfigurierten Clients im Verwaltungsnetz ist übrigends der erste Hop direkt 172.21.11.2, obwohl ja das Standardgateway Zentyal ist und der ja die Route ins 172.20.0.0 Netz via 172.21.11.2 kennt.
Leider habe ich vergessen mal nachzuschauen, welches Standardgateway die DHCP Clienten haben, aber theoretisch sollte bei den Clienten mit statischer IP ja 172.21.11.1 als Gateway trotzdem hinhauen oder? Das ist ja Zentyal und der kennt wie gsagt die Route.
Meine Gedanke des Routing war die folgende:
Client -> 172.21.11.1 (Standardgateway) -> Zentyal kennt Route, also: 172.21.11.2 -> Pfsense kennt Netz, also: 172.22.0.20
Kannst du mir dieses Verhalten erklären?
Allerdings habe ich noch eine Frage: Ich kann die APs problemlos erreichen und konfigurieren, wenn die Clienten aus dem Verwaltungsnetz eine Adresse via DHCP bekommen haben. Haben Sie eine statische Adresse im Verwaltungsnetz bekommen, kann ich sie zwar anpingen und teilweise mit tracert erreichen, allerdings erreiche ich das Webinterface nicht.
Beispielkonfiguration Latop mit statische IP:
IP: 172.21.11.8
Subnetz: 255.255.248.0
Gateway: 172.21.11.1
Ein Ping auf auf den AP mit der IP 172.22.0.20 geht problemlos durch, ein tracert sieht so aus:
Das ist ehrlich gesagt das erste Mal, dass ich den Fall habe, dass der tracert eine Zeitüberschreitung anzeigt, dennoch aber ankommt.
Von Zentyal aus funktioniert das tracert auf die APs ohne Probleme.
Bei den via DHCP konfigurierten Clients im Verwaltungsnetz ist übrigends der erste Hop direkt 172.21.11.2, obwohl ja das Standardgateway Zentyal ist und der ja die Route ins 172.20.0.0 Netz via 172.21.11.2 kennt.
Leider habe ich vergessen mal nachzuschauen, welches Standardgateway die DHCP Clienten haben, aber theoretisch sollte bei den Clienten mit statischer IP ja 172.21.11.1 als Gateway trotzdem hinhauen oder? Das ist ja Zentyal und der kennt wie gsagt die Route.
Meine Gedanke des Routing war die folgende:
Client -> 172.21.11.1 (Standardgateway) -> Zentyal kennt Route, also: 172.21.11.2 -> Pfsense kennt Netz, also: 172.22.0.20
Kannst du mir dieses Verhalten erklären?
Aqui, ich möchte mich bedanken, mit der Route funktioniert es
Immer gerne wieder und teilweise mit tracert erreichen, allerdings erreiche ich das Webinterface nicht.
Da hast du dann ICMP erlaubt blockst aber TCP 80 oder TCP 443 ! Ganz sicher zu 98% eine falsche FW Regel !Was das Routing anbetrifft müsstest du dir mal die Routing Tabelle ansehen auf beiden Systemen.
netstat -r erledigt das auf dem Zentral und auf der pfSense ist das Diagnostics --> Routes dort sollten alle beteiligten Netze aufgeführt sein.
Achte auch auf die Masken ! Ein Masken Mismatch kann sowas auch verursachen.
