9
PfSense Zugriff von einem Subnet zum anderen nicht möglich
Hallo zusammen,
ich habe pfSense schon länger am laufen, ich bin nicht der Überflieger, aber das was ich will, bekomme ich halt hin, notfalls mache ich mich schlau.
So haben wir bei unserem Schießstand auch eine pfSense.
Dort wird jetzt eine Meytonanlage aufgebaut und die möchte ich natürlich auch via pfSense mit einbinden.
Gruselig finde ich das Netzwerkmanagement für die paar gerätschaften. 192.168.2.1 ist deren kleinst angegebene IP und das ganze mit 255.255.0.0 Subnet.
Somit habe ich mir ein vlan erstellt, der pfSense die 192.168.0.1 gegeben im 255.255.255.0 Subnet um dem Rest nicht in die Quere zu kommen und das große Subnet mit einzubinden.
Die pfSense selbst läuft im 172.20.1.0/16 Subnet und weitere vlans auch im 172er Bereich.
Dort funktioniert auch alles.
Ich habe ein proxmox aufgesetzt im 172er Bereich, der einen Server der Anlage beherbergt. Das funktioniert auch.
Wenn ich von der pfSense einen der Messrahmen (kleine Embedded Geschichten) pingen will, so geht nichts durch, egal aus welchem Subnet, außer aus dem selbigen Subnet.
Mein Admin Netz hat eine Any/Any Regel und theoretisch müsste das doch rüber gehen.
Dadurch, dass die pfSense über Ping im selben Sourcenetz den Messrahmen oder den Server erreicht, muss ja Switchseitig alles sauber sein, sonst würde das ja grundsätzlich auch nicht gehen.
Was kann das sein? Gibt es das, dass solch kleine Gerätschaften mich blocken? Wo kann mein Fehler liegen?
ich habe pfSense schon länger am laufen, ich bin nicht der Überflieger, aber das was ich will, bekomme ich halt hin, notfalls mache ich mich schlau.
So haben wir bei unserem Schießstand auch eine pfSense.
Dort wird jetzt eine Meytonanlage aufgebaut und die möchte ich natürlich auch via pfSense mit einbinden.
Gruselig finde ich das Netzwerkmanagement für die paar gerätschaften. 192.168.2.1 ist deren kleinst angegebene IP und das ganze mit 255.255.0.0 Subnet.
Somit habe ich mir ein vlan erstellt, der pfSense die 192.168.0.1 gegeben im 255.255.255.0 Subnet um dem Rest nicht in die Quere zu kommen und das große Subnet mit einzubinden.
Die pfSense selbst läuft im 172.20.1.0/16 Subnet und weitere vlans auch im 172er Bereich.
Dort funktioniert auch alles.
Ich habe ein proxmox aufgesetzt im 172er Bereich, der einen Server der Anlage beherbergt. Das funktioniert auch.
Wenn ich von der pfSense einen der Messrahmen (kleine Embedded Geschichten) pingen will, so geht nichts durch, egal aus welchem Subnet, außer aus dem selbigen Subnet.
Mein Admin Netz hat eine Any/Any Regel und theoretisch müsste das doch rüber gehen.
Dadurch, dass die pfSense über Ping im selben Sourcenetz den Messrahmen oder den Server erreicht, muss ja Switchseitig alles sauber sein, sonst würde das ja grundsätzlich auch nicht gehen.
Was kann das sein? Gibt es das, dass solch kleine Gerätschaften mich blocken? Wo kann mein Fehler liegen?
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: 668600
Url: https://administrator.de/contentid/668600
Ausgedruckt am: 05.10.2024 um 22:10 Uhr
9 Kommentare
Neuester Kommentar
Nabend.
Kannst du mal skizzieren, wie was angeschlossen ist?
Also welcher Port der PFSense auf welchem Switchport landet und wie dieser konfiguriert ist.
Gruß
Marc
Kannst du mal skizzieren, wie was angeschlossen ist?
Also welcher Port der PFSense auf welchem Switchport landet und wie dieser konfiguriert ist.
Gruß
Marc
Jetzt adhoc skizzieren ist schwierig.
Aber kurz erklärt.
Die Messrahmen insgesamt 9 sind auf den Switchports 1-9 und liegen untagged in vlan 11, der Rest ist verboten.
Der Server ist ja ein Proxmox, der liegt untagged in vlan 10 und die Server VM tagged in 11.
Das funktioniert, der Server erreichbar die Rahmen, die zum Test an waren.
Die pfsense ist untagged auf vlan 1.
Der Switchport hat alle anderen Vlans tagged, also 10, 11, 50, 110.
Letztere sind hierbei jetzt ja uninteressant.
Ich kann von der pfsense auf den Proxmox zugreifen.
1 auf 10 geht
Ich kann von der pfsense aus vlan11 in vlan 11 Pingen und hantieren
Ich komme jedoch auch nicht aus vlan 1 und 10 in die 11.
Dadurch dass verschiedenste Konstellationen gehen, würde ich das Switch fast ausschließen, da andere Gegentests ja gehen.
Komisch ist halt, dass der Rest nicht geht.
Regeln sind ja ausgehend.
Theoretisch braucht vlan 11 ja gar keine Regel.
Vlan 1 hat eine Any Any Any Regel.
Die müsste doch erlauben von vlan 1 in die 11 zu kommen.
Oder ist da ein Denkfehler?
Aber kurz erklärt.
Die Messrahmen insgesamt 9 sind auf den Switchports 1-9 und liegen untagged in vlan 11, der Rest ist verboten.
Der Server ist ja ein Proxmox, der liegt untagged in vlan 10 und die Server VM tagged in 11.
Das funktioniert, der Server erreichbar die Rahmen, die zum Test an waren.
Die pfsense ist untagged auf vlan 1.
Der Switchport hat alle anderen Vlans tagged, also 10, 11, 50, 110.
Letztere sind hierbei jetzt ja uninteressant.
Ich kann von der pfsense auf den Proxmox zugreifen.
1 auf 10 geht
Ich kann von der pfsense aus vlan11 in vlan 11 Pingen und hantieren
Ich komme jedoch auch nicht aus vlan 1 und 10 in die 11.
Dadurch dass verschiedenste Konstellationen gehen, würde ich das Switch fast ausschließen, da andere Gegentests ja gehen.
Komisch ist halt, dass der Rest nicht geht.
Regeln sind ja ausgehend.
Theoretisch braucht vlan 11 ja gar keine Regel.
Vlan 1 hat eine Any Any Any Regel.
Die müsste doch erlauben von vlan 1 in die 11 zu kommen.
Oder ist da ein Denkfehler?
Wie sind denn die Schnittstellen der PFSense angeschlossen? Wie viele physische Netzwerkkarten hat diese?
Sind die VLANs auf dem Switch-Port entsprechend tagged konfiguriert, welcher zur PFSense geht?
VLAN 1 sollte man nicht unbedingt als Schnittstelle konfigurieren.
Schieß mal bitte ein paar Screenshots der Konfiguration und der Regelwerke der einzelnen Schnittstellen der PFSense.
Gibt es einen Host in dem VLAN? Wie ist der Switch an den beteiligten Ports konfiguriert?
Randbemerkung und hat erstmal nix mit dem eigentlichen Problem zu tun:
Die Wahl der Subnetzmasken klingt nur bedingt sinnvoll. Es sei denn ihr müsst gegen 65.000 Hosts in den 172er und 192er Netzen unterbringen.
Kleinere Subnetze sind da sinnvoller.
Gruß
Marc
Sind die VLANs auf dem Switch-Port entsprechend tagged konfiguriert, welcher zur PFSense geht?
VLAN 1 sollte man nicht unbedingt als Schnittstelle konfigurieren.
Schieß mal bitte ein paar Screenshots der Konfiguration und der Regelwerke der einzelnen Schnittstellen der PFSense.
Zitat von @fnbalu:
Vlan 1 hat eine Any Any Any Regel.
Die müsste doch erlauben von vlan 1 in die 11 zu kommen.
Oder ist da ein Denkfehler?
Vlan 1 hat eine Any Any Any Regel.
Die müsste doch erlauben von vlan 1 in die 11 zu kommen.
Oder ist da ein Denkfehler?
Gibt es einen Host in dem VLAN? Wie ist der Switch an den beteiligten Ports konfiguriert?
Randbemerkung und hat erstmal nix mit dem eigentlichen Problem zu tun:
Die Wahl der Subnetzmasken klingt nur bedingt sinnvoll. Es sei denn ihr müsst gegen 65.000 Hosts in den 172er und 192er Netzen unterbringen.
Kleinere Subnetze sind da sinnvoller.
Gruß
Marc
Nur erstmal zum letzten Hinweis.
Ich habe 172.20.1.0/24 als Admin Netz
10.0/24 für das nächste usw., das ist dann vlan10 zur Übersicht.
Vlan 11 ist dieses Meyton Zeug.
Da gibt der Hersteller das so vor. Absoluter Hammer für unter 20 Geräte.
Aber das ist ja so machbar durch das andere Design.
Screenshots sind heute Abend schwierig. Mein privates OpenVPN kann auf Windows keine Routen mehr setzen. Kurios, von Android geht
Ich habe 172.20.1.0/24 als Admin Netz
10.0/24 für das nächste usw., das ist dann vlan10 zur Übersicht.
Vlan 11 ist dieses Meyton Zeug.
Da gibt der Hersteller das so vor. Absoluter Hammer für unter 20 Geräte.
Aber das ist ja so machbar durch das andere Design.
Screenshots sind heute Abend schwierig. Mein privates OpenVPN kann auf Windows keine Routen mehr setzen. Kurios, von Android geht
Moin,
Hast du die lokalen Windows-Firewall dahingehend angepasst, dass sie Datenverkehr aus den anderen VLANs/ IP-Netzen zulassen?
Hast du die lokalen Windows-Firewall dahingehend angepasst, dass sie Datenverkehr aus den anderen VLANs/ IP-Netzen zulassen?
Moin,
auch mit viel Phantasie ist mir Deine Konfiguration noch nicht klar. Irgendwo wirst Du einen Konfigurationsfehler haben. Deine Beschreibung wiederum kann kaum vollständig sein.
Du sagst, die PfSense habe 172.20.1.0, welches VLAN auch immer. Zugleich ist sie wohl in VLAN 11 aktiv, zu dem ich 192.168.0.x vermute, mit differierenden Subnetz-Masken. Welches Gerät ist denn dann in VLAN 1, mit dem Du testest? Denn die pfSense kann ja wohl zu VLAN 11 pingen. Hat sie denn auch ein Standbein in VLAN 10, damit sie routen kann?
Wie gesagt, das sind einfach zu wenige Informationen.
Gruß
DivideByZero
auch mit viel Phantasie ist mir Deine Konfiguration noch nicht klar. Irgendwo wirst Du einen Konfigurationsfehler haben. Deine Beschreibung wiederum kann kaum vollständig sein.
Du sagst, die PfSense habe 172.20.1.0, welches VLAN auch immer. Zugleich ist sie wohl in VLAN 11 aktiv, zu dem ich 192.168.0.x vermute, mit differierenden Subnetz-Masken. Welches Gerät ist denn dann in VLAN 1, mit dem Du testest? Denn die pfSense kann ja wohl zu VLAN 11 pingen. Hat sie denn auch ein Standbein in VLAN 10, damit sie routen kann?
Wie gesagt, das sind einfach zu wenige Informationen.
Gruß
DivideByZero
Also pfsense ist 172.20.1.1
In dem Netz ist dann noch eine ISDN Anlage beispielsweise.
Vlan 10 hat 172.20.10.1 auf der pfsense, alles 24er Netze, dort sind einige clients.
Vlan 11 ist 192.168.0.0/16
Momentan lese ich gerade wieder viel und muss eine Nacht drüber schlafen.
Folgenden Satz habe ich hier im Forum gefunden.
Wenn VLAN 10 auf VLAN 30 keinen Zugriff haben soll, dann auf VLAN 30 eine Regel setzen. Deny Source VLAN 10 Destination VLAN 30 Port any Protocol any.
Das klingt soweit plausibel, ist aber erschreckend, weil ich es bei mir zu Hause anders herum habe glaube ich.
Da sage ich im vlan 40, dass es nicht in das Home Net Darf.
Das ist also eine Outbound Regel.
Es funktioniert so allerdings.
Oder sehe ich das falsch alles?
Der Screenshot hat jetzt nichts mit der oben genannten pfsense zu tun, jedoch ist das vielleicht das grundsätzliche Verständnisproblem welches ich an der Wurzel packen muss
In dem Netz ist dann noch eine ISDN Anlage beispielsweise.
Vlan 10 hat 172.20.10.1 auf der pfsense, alles 24er Netze, dort sind einige clients.
Vlan 11 ist 192.168.0.0/16
Momentan lese ich gerade wieder viel und muss eine Nacht drüber schlafen.
Folgenden Satz habe ich hier im Forum gefunden.
Wenn VLAN 10 auf VLAN 30 keinen Zugriff haben soll, dann auf VLAN 30 eine Regel setzen. Deny Source VLAN 10 Destination VLAN 30 Port any Protocol any.
Das klingt soweit plausibel, ist aber erschreckend, weil ich es bei mir zu Hause anders herum habe glaube ich.
Da sage ich im vlan 40, dass es nicht in das Home Net Darf.
Das ist also eine Outbound Regel.
Es funktioniert so allerdings.
Oder sehe ich das falsch alles?
Der Screenshot hat jetzt nichts mit der oben genannten pfsense zu tun, jedoch ist das vielleicht das grundsätzliche Verständnisproblem welches ich an der Wurzel packen muss
Vlan 10 hat 172.20.10.1 auf der pfsense, alles 24er Netze, dort sind einige clients.
Vlan 11 ist 192.168.0.0/16
1. pfSense muss natürlich selbst auch eine IP aus dem Netz 192.168.0.0/ 16 haben und auch im VLAN11 stecken.Vlan 11 ist 192.168.0.0/16
Entweder über eine eigene NIC oder über einen Trunk-Port.
2. ihr habt da ernsthaft ein Netz mit einer 16er Maske? Das wären dann 65.534 nutzbare IP-Adressen in dem einen VLAN. Das ist ja Wahnsinn. Wenn, würde ich da 256 einzelne 24er Netze „bauen“…
Also die pfsense hat natürlich die 192.168.0.1 im vlan11
Dass das Subnetz so riesig ist, missfällt mir auch und ist wenn man sich das ansieht auch nicht nötig.
So gibt es halt der Hersteller vor ohne sich da Mal Gedanken gemacht zu haben. Das macht halt viele Netze kaputt, in meinem Fall kommt das aber nicht zum Tragen und ist egal.
Klar, so ist das überall einheitlich und ist für den Support einfach.
Ich könnte es vielleicht anpassen, aber wer kann dann da noch irgendwann mal etwas ändern, bei 95% von uns scheitert es schon daran die Fritzbox über IP-Adresse aufzurufen. Was soll ich denen von vlan und Subnetz erzählen.
Sieh selbst.
Ich glaube ich kann den Fehler eingrenzen.
Ich bin nicht mehr vor Ort, aber ich habe meine ich im vlan11 den Outbound Block in die anderen Subnetze.
Wenn ich aqui aus einem anderen Thread zitiere...
Richtig wäre die folgende Regel am VLAN 30 Interface:
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 10 net, Port: any.
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: ANY (Internet), Port: any.
Das blockt dir den Zugriff in die anderen VLANs und lässt nur das Internet zu.
Das hat jetzt aber den Nachteil, das du von deinem VLAN 20 auch nicht mehr aufs VLAN 30 zugreifen kannst, was du ja nicht willst.
Hier hast du jetzt 2 Optionen:
1.)
Du lässt den Zugriff nur auf bestimmte Dienste und IPs im VLAN 20 zu. Das hat aber dann den gravierenden Nachteil das auch User aus VLAN 30 von sich aus diese Ziele in VLAN 20 erreichen.
Pfiffiger ist dann die Option...
2.)
Du änderst die Regeln etwas:
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 10 net, Port: any.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any. Advanced: Established Bit setzen.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: anyt, Port: any.
Die Option 2 lässt dann nur Antwort Pakete die ein Establised Bit im Layer 4 gesetzt haben durch.
D.h. User aus VLAN 30 kommen so nur ins Internet.
Sessions aber die vom VLAN 20 ins VLAN 30 initiiert werden und damit aus dem VLAN 30 beantwortet werden dürfen auch passieren.
Demnach wäre das mit dem established zu kontrollieren.
Demnach wäre aber auch meine Regel richtig, wenn ich clients aus vlan10 in Richtung vlan20 blocken will, dass die Regel dann in vlan10 mit Source vlan10net zu Destination vlan10net erstellt werden muss.
Dass das Subnetz so riesig ist, missfällt mir auch und ist wenn man sich das ansieht auch nicht nötig.
So gibt es halt der Hersteller vor ohne sich da Mal Gedanken gemacht zu haben. Das macht halt viele Netze kaputt, in meinem Fall kommt das aber nicht zum Tragen und ist egal.
Klar, so ist das überall einheitlich und ist für den Support einfach.
Ich könnte es vielleicht anpassen, aber wer kann dann da noch irgendwann mal etwas ändern, bei 95% von uns scheitert es schon daran die Fritzbox über IP-Adresse aufzurufen. Was soll ich denen von vlan und Subnetz erzählen.
Sieh selbst.
Ich glaube ich kann den Fehler eingrenzen.
Ich bin nicht mehr vor Ort, aber ich habe meine ich im vlan11 den Outbound Block in die anderen Subnetze.
Wenn ich aqui aus einem anderen Thread zitiere...
Richtig wäre die folgende Regel am VLAN 30 Interface:
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 10 net, Port: any.
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: ANY (Internet), Port: any.
Das blockt dir den Zugriff in die anderen VLANs und lässt nur das Internet zu.
Das hat jetzt aber den Nachteil, das du von deinem VLAN 20 auch nicht mehr aufs VLAN 30 zugreifen kannst, was du ja nicht willst.
Hier hast du jetzt 2 Optionen:
1.)
Du lässt den Zugriff nur auf bestimmte Dienste und IPs im VLAN 20 zu. Das hat aber dann den gravierenden Nachteil das auch User aus VLAN 30 von sich aus diese Ziele in VLAN 20 erreichen.
Pfiffiger ist dann die Option...
2.)
Du änderst die Regeln etwas:
BLOCK Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 10 net, Port: any.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: VLAN 20 net, Port: any. Advanced: Established Bit setzen.
PASS Protocol: any, Source: VLAN30 net Port: any, Destination: anyt, Port: any.
Die Option 2 lässt dann nur Antwort Pakete die ein Establised Bit im Layer 4 gesetzt haben durch.
D.h. User aus VLAN 30 kommen so nur ins Internet.
Sessions aber die vom VLAN 20 ins VLAN 30 initiiert werden und damit aus dem VLAN 30 beantwortet werden dürfen auch passieren.
Demnach wäre das mit dem established zu kontrollieren.
Demnach wäre aber auch meine Regel richtig, wenn ich clients aus vlan10 in Richtung vlan20 blocken will, dass die Regel dann in vlan10 mit Source vlan10net zu Destination vlan10net erstellt werden muss.
