29
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/forum/pfsense-zugriff-von-einem-subnet-zum-anderen-nicht-moeglich-668600.html
Ausgedruckt am: 22.12.2024 um 04:12 Uhr
29 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.
Und zur Hardware.
In dem Fall nutze ich keine dedizierte Hardware.
Es ist ein Shuttle PC mit 2 NICs.
Darauf ist Proxmox installiert.
Lan1 ist WAN only
Lan2 ist LAN. Darüber erreiche ich den Proxmox und alle Netze der pfsense laufen darüber.
Untagged mein Admin Netz und alles andere getagged in vlans
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.
Und zur Hardware.
In dem Fall nutze ich keine dedizierte Hardware.
Es ist ein Shuttle PC mit 2 NICs.
Darauf ist Proxmox installiert.
Lan1 ist WAN only
Lan2 ist LAN. Darüber erreiche ich den Proxmox und alle Netze der pfsense laufen darüber.
Untagged mein Admin Netz und alles andere getagged in vlans
Sind denn die Netzwerk-Einstellungen der Gerätschaften fest verdrahtet oder änderbar?
Bezüglich der Regeln ist es ja so, dass zunächst nach der Installation nur das PFSense LAN Interface eine Any-to-Any Regel hat.
Alles andere muss man ja explizit erlauben.
Also ist die PFSense virtualisiert?
Hier und überall gibt es geteilte Meinungen, ob man eine Firewall virtualisieren sollte.
Eine kleine IPU oder Thomas Krenn Kiste wäre sicherlich sinnvoller.
Gruß
Marc
Bezüglich der Regeln ist es ja so, dass zunächst nach der Installation nur das PFSense LAN Interface eine Any-to-Any Regel hat.
Alles andere muss man ja explizit erlauben.
Und zur Hardware.
In dem Fall nutze ich keine dedizierte Hardware.
Es ist ein Shuttle PC mit 2 NICs.
Darauf ist Proxmox installiert.
Lan1 ist WAN only
Lan2 ist LAN. Darüber erreiche ich den Proxmox und alle Netze der pfsense laufen darüber.
In dem Fall nutze ich keine dedizierte Hardware.
Es ist ein Shuttle PC mit 2 NICs.
Darauf ist Proxmox installiert.
Lan1 ist WAN only
Lan2 ist LAN. Darüber erreiche ich den Proxmox und alle Netze der pfsense laufen darüber.
Also ist die PFSense virtualisiert?
Hier und überall gibt es geteilte Meinungen, ob man eine Firewall virtualisieren sollte.
Eine kleine IPU oder Thomas Krenn Kiste wäre sicherlich sinnvoller.
Gruß
Marc
Oha, da sind schwerwiegende Fehler im Subnetz-Design ...
Hat für mich den Eindruck als hätte der TO bei den Subnetting-Grundlagen einen schwerwiegenden Denkfehler, so wie hier mit den Subnetzen hantiert wird... 🤔
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.
Genauso gruselig ist das was du da schreibst. Du erstellst ein 24er Subnetz welches aber schon im großen 16er enthalten ist, schwerer Fehler und kann so routingtechnisch nicht gut gehen! Wenn da bspw. ein Gerät aus dem großen in das kleine will klappt das nicht weil das Gerät erst gar nicht sein Default GW kontaktiert sondern versucht das andere Device per ARP in der selben L2 Domain aufzulösen. Anders herum genauso problematisch. Das ist also ein NoGo sich überschneidende Netze anzulegen.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.
Hat für mich den Eindruck als hätte der TO bei den Subnetting-Grundlagen einen schwerwiegenden Denkfehler, so wie hier mit den Subnetzen hantiert wird... 🤔
Regeln sind ja ausgehend
Firewall Regeln sind in erster Linie immer eingehend am jeweiligen Interface der Firewall zu sehen. Traffic fließt am Interface in die Firewall.
Die pfSense selbst läuft im 172.20.1.0/16 Subnet und weitere vlans auch im 172er Bereich.
Solcherlei falsche Angaben sind in höchstem Maße verwirrend und auch laienhaft.Wenn überhaupt, dann lautet die Netzwerkaddresse zu obigem Netz mit dem 16 Bit Prefix 172.20.0.0 /16. (Netz = alle Hostbits auf 0!) Die dort angegebene Adresse .1.0 wäre dann eine Hostaddresse aus diesem IP Netz. Oder... bezeichnet eine Netzwerkaddresse mit einem 24 Bit Prefix. Was der TO nun mit solchen wirren Angaben meint und konfiguriert hat bleibt damit ein Ratespiel.
Netzmasken lesen und verstehen!!
https://de.wikipedia.org/wiki/Netzmaske
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
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.
Auch solcherlei Aussagen sind völlig verwirrend und zeigen eher ein völlig falsches Subnetting. Man kann keine Hosts mit einer 24er Maske in einem /16er Netz betreiben! Damit hätte man inkonsistente Netzwerkmasken in einer Layer 2 Domain. Ein absolutes NoGo bei einen sauberen IP Adressdesign.Natürlich hat der Hersteller dieser Anlage unsinnig und wenig intelligent gehandelt im Adressdesign seines Produktes. Sowas passiert leider wenn kleine "Klitschen" wenig Ahnung von IP Netzen haben. Das ganze 192.168.0.0 /16er Netz fest vorzugeben ist totaler Unsinn und stürzt Kunden mit bestehender anderer 192.168er Adressierung in große Probleme bzw. zwingt sie aufwändig auf andere Bereich des RFC 1918er IP Adressraumes umzusatteln wenn sie nicht mit komplizierten NAT Verfahren arbeiten wollen.
Sehr unschön und zeigt wenig Praxiserfahrung des Herstellers aber eben auch eine andere Baustelle mit der man dann leben muss. Da die bestehende Adressierung mit Netzen im 172.16.0.0 /12er Bereichs arbeitet tut es ja auch erstmal in dem Falle nicht weh.
Die pfSense selbst läuft im 172.20.1.0/16 Subnet und weitere vlans auch im 172er Bereich.
Nächstes Beispiel einer leider unsinnigen Formulierung. Eine Firewall wie die pfSense (und andere) läuft nicht "selbst" in einem Netz sondern logischerweise immer in ALLEN IP Netzen an die sie direkt angeschlossen ist. Diese IP Netze können natürlich beliebige CIDR Subnetzmasken haben solange diese sich nicht überschneiden. Klassische IP Adressdesignregel die man in der IP Grundschule lernt.Formulierungen des TO wie "im 172.20.1.0/16 Subnet und weitere vlans auch im 172er Bereich" zeigen nicht nur ein völlig falsches Verständnis von Subnetzen und ihren Hostadressen sondern lassen leider auch vermuten das der TO noch im tiefen IP Neandertal von klassenbasierten Netzen lebt und die letzten 30 Jahre sanft verschlafen hat in der die IP Welt mit CIDR IP Netzen arbeitet.
Solcherlei verwirrende Aussagen machen ein Troubleshooting quasi unmöglich oder man muss langwierig nachfragen ob der TO solche grundsätzlichen Adressierungsfehler im Netz begangen hat oder nicht.
Ein kurze Übersichtsskizze welche IP Netze mit welchen Masken an der FW hängen und dem dazu korrespondieren Regelwerk würde eine zielführende Hilfe deutlich beschleunigen. Der Fehler liegt hier sehr wahrscheinlich in falschen oder fehlerhaften Interface Regeln.
Wie man die pfSense sauber und korrekt in einem Proxmox VLAN Umfeld betreibt erklärt u.a. dieses Tutorial.
Zitat von @150704:
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.
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.
Sorry, das ist natürlich ein 16er Subnetz mit 255.255.0.0
Das habe ich hier leider falsch geschrieben.
Wie gesagt meine 24er Netze sind im 172er Bereich
Das eine zusätzliche problematische im 192/16
Entsprechend die pfsense auf der 0.1
Kommt sich nicht in die Quere
So gibt es halt der Hersteller vor ohne sich da Mal Gedanken gemacht zu haben.
Welcher Hersteller? Einer, der von Netzwerken genauso viel Ahnung hat wie ich vom Brückenbauen (und da hab ich 0 Ahnung von 
)Ich glaube, der Hersteller wollte segmentieren, hat aber kein Bock auf Routing und Firewalling…
Stammt das obige Bild mit den IPs von dir oder vom Hersteller?
Kannst du auf die Endgeräte Einfluss nehmen?
Falls ja: mach aus dem großen 16er Netz einfach 3 x 24er in drei VLANs (3002, 3010 und wegen meiner 3011) und gut.
Leg an der pfSense erstmal in jedem Bereich eine IP an. Dann Firewall mit Any2Any für die drei Netze und dann Zug um Zug Netzmaske und Gateway für die Devices ändern. Das sollte den geringsten Ausfallh geben…
Leg an der pfSense erstmal in jedem Bereich eine IP an
Das wäre fatal und eine fehlerhafte Sackgasse wenn der Hersteller von einem einzigen Layer 2 Netzwerk mit einer festen 16 Bit Maske ausgeht und diese vorgibt! Welche logischen "Gruppierungen" er im 3ten Byte "empfiehlt" ist ja lediglich rein kosmetischer Natur. Alle 192.168.x.x Adressen sind in einem /16er Netz gleichbereichtigt sofern man diese Maske nicht ändern kann.Relevant ist also immer welche Maske der Hersteller nutzt und wenn er diese mit /16 fest und unveränderbar vorgibt dann ist das halt so.
Dafür hat die pfSense übrigens einen Paket Sniffer im "Diagnostic" Menü an Bord mit der man sich IP Pakete dieser Komponenten ansehen kann und so sofort auf die vom Hersteller verwendete Subnetzmaske schliessen kann.
Wenn er einen 16er Prefix vorgibt muss das dazu korrespondierende Firewall Interface logischerweise auch immer einen 16er Prefix haben!
Um das auch erstmal zu simulieren reicht es ja auch eine Handvoll Testkomponenten an einen einfachen Layer 2 Switch zu klemmen und einen Test PC mit einer freien 192.168.x.x /16 Adresse die das Firewall Interface simuliert. Kann man in der Konstellation alles pingen und "sieht" alles, ist die Maske korrekt.
Ansonsten ist das Diagnostics Menü und die Paket Capture Funktion immer dein bester Freund!
Also ich bin jetzt nicht vor Ort, komme also nicht an das Regelwerk, versuche aber das IP-Adressdesign noch einmal verständlich darzustellen.
Vorweg sei gesagt, dass selbstredend extra Hardware für eine Firewall gut wäre, aber da das ein Dorfgemeinschaftshaus mit Vereinsheim ist, wollte ich nicht zu viel Hardware verbauen. Ob Virtualisierung sinnvoll ist, ist auch immer eine Glaubensfrage und führt zu unzähligen Diskussionen, die jetzt hier ausarten würden glaube ich.
Der Hersteller der Meyton-Anlage baut das alles auch mit unmanaged Switchen einfach so auf und lässt es autark laufen. Ich jedoch möchte es integrieren um Drucker besser nutzen zu können etc.
Wenn ich bedenke, dass ich 9 Messrahmen habe, wovon 3 die IPs doppelt vergeben haben, jedoch immer nur einer an ist, 6 Displaycomputer und 1 Server, dann ist das Netz für 14 IPs, wenn man den Drucker noch mit einbezieht leicht überdimensioniert.
Das haben wir alle ja so festgestellt und ist nicht Thema. Der Hersteller hat von klein bis groß (groß reizt natürlich immer noch nicht alles aus) das selbe Design und ist für den Support leichter. Herstellerseitig habe ich natürlich ein großes Specktrum, wo ich die Messrahmen bei Auslieferung hinpacken kann und hinterher finde. Aber ich schweife ab.
Also es gibt ein Shuttle PC, auf dem läuft Proxmoxx. In einer VM ist die pfsense, dann läuft da noch ein Freifunk Offloader und (derzeit ungenutzt) ein Adguard Home.
Da das Ganze im Dorgemeinschaftshaus ist und Homegeräte zu 99% FRitzboxen oder Speedports in den vorgegebenen Subnets sind, habe ich gleich von dem weg designed.
Die pfsense ist immer vorne im Netz auf der 1
pfsense:
172.20.1.0/24 Admin-Net darin habe ich das Switch liegen, ISDN Anlage usw.
172.20.10.0/24 vlan10 Vereinsnetz, da sollen vom Verein PC und sonstige Geschichte rein.
172.20.50.0/24 vlan50 Gemeindenetz für Ratssitzungen
192.168.0.0/16 vlan11 Neues Meytonnetz
vlan110 Freifunk Offloader, der ist auch als zweites WAN in die pfsense gezogen, somit können ganze Netze über Freifunk ausgeschleust werden, das funktioniert auch so.
proxmoxx2 für Meyton
Es ist ein zweiter Shuttle, damit ich den Meyton Server virtualisieren kann um Snapshots automatisiert zu fahren und ggf. schnell wiederherstellen zu können. Der Hersteller würde ein Laptop dafür ausliefern, aber ein Wald und Wiesenlaptop und da dann jedes Mal Kabelei dran usw das lebt nicht lange, das wollte ich nicht.
Proxmox selbst läuft auf 172.20.10.3 im vlan10 untagged
Meyton Server auf 192.168.10.200 (wie in der Liste) untagged für das System, aber es kommt im vlan11 aus der proxmox. Das geht, wenn man ein Interface ohne vlan aware im vlan erstellt.
Meytongeraffel
Messrahmen und Co laufen im großen 192er Netz
Switchports zur Übersicht
pfsense ist untagged 1 und vlan 10, 11, 50 tagged
proxmoxx2 untagged 10 und 11 tagged
Meytongeraffel untagged 11
Ich kann vom Meytonserver hinter dem proxmoxx die Messrahmen erreichen. => Schlussfolgerung Vlan und Tagging von Proxmoxx und Switchport ind richtig eingestellt.
Ich kann von der pfSense wenn ich vom Interface vlan11 pinge, auch messrahmen und Co erreichen.
Ping ist nicht das Hauptaugenmerk, ich wollte eigentlich Port 80 HTTP aber das geht auch nicht (zwecks Firewalling bei ping)
Heißt auch da ist beim Switch mit vlan usw alles sauber, denn ich erreiche ja grundsätzlich das Netz.
Was nicht geht ist von vlan10 oder vlan1 in das vlan11
Nun dachte ich, dass aus vlan1 eine any any any dafür ausreicht in vlan11 zu kommen.
Ich muss jedoch mal schauen, ob ich in dem vlan11 nicht schon eine Deny Source vlan11, Destination vlan1 Regel habe.
Das Internet soll für das Meytonnetz generell verboten sein, deshalb ist da kaum Regelwerk. Später mal eine Webseite aber da schaue ich dann gesondert, das ist jetzt gerade kein Thema
Screenshots vom Regelwerk liefere ich sonst nach
Vorweg sei gesagt, dass selbstredend extra Hardware für eine Firewall gut wäre, aber da das ein Dorfgemeinschaftshaus mit Vereinsheim ist, wollte ich nicht zu viel Hardware verbauen. Ob Virtualisierung sinnvoll ist, ist auch immer eine Glaubensfrage und führt zu unzähligen Diskussionen, die jetzt hier ausarten würden glaube ich.
Der Hersteller der Meyton-Anlage baut das alles auch mit unmanaged Switchen einfach so auf und lässt es autark laufen. Ich jedoch möchte es integrieren um Drucker besser nutzen zu können etc.
Wenn ich bedenke, dass ich 9 Messrahmen habe, wovon 3 die IPs doppelt vergeben haben, jedoch immer nur einer an ist, 6 Displaycomputer und 1 Server, dann ist das Netz für 14 IPs, wenn man den Drucker noch mit einbezieht leicht überdimensioniert.
Das haben wir alle ja so festgestellt und ist nicht Thema. Der Hersteller hat von klein bis groß (groß reizt natürlich immer noch nicht alles aus) das selbe Design und ist für den Support leichter. Herstellerseitig habe ich natürlich ein großes Specktrum, wo ich die Messrahmen bei Auslieferung hinpacken kann und hinterher finde. Aber ich schweife ab.
Also es gibt ein Shuttle PC, auf dem läuft Proxmoxx. In einer VM ist die pfsense, dann läuft da noch ein Freifunk Offloader und (derzeit ungenutzt) ein Adguard Home.
Da das Ganze im Dorgemeinschaftshaus ist und Homegeräte zu 99% FRitzboxen oder Speedports in den vorgegebenen Subnets sind, habe ich gleich von dem weg designed.
Die pfsense ist immer vorne im Netz auf der 1
pfsense:
172.20.1.0/24 Admin-Net darin habe ich das Switch liegen, ISDN Anlage usw.
172.20.10.0/24 vlan10 Vereinsnetz, da sollen vom Verein PC und sonstige Geschichte rein.
172.20.50.0/24 vlan50 Gemeindenetz für Ratssitzungen
192.168.0.0/16 vlan11 Neues Meytonnetz
vlan110 Freifunk Offloader, der ist auch als zweites WAN in die pfsense gezogen, somit können ganze Netze über Freifunk ausgeschleust werden, das funktioniert auch so.
proxmoxx2 für Meyton
Es ist ein zweiter Shuttle, damit ich den Meyton Server virtualisieren kann um Snapshots automatisiert zu fahren und ggf. schnell wiederherstellen zu können. Der Hersteller würde ein Laptop dafür ausliefern, aber ein Wald und Wiesenlaptop und da dann jedes Mal Kabelei dran usw das lebt nicht lange, das wollte ich nicht.
Proxmox selbst läuft auf 172.20.10.3 im vlan10 untagged
Meyton Server auf 192.168.10.200 (wie in der Liste) untagged für das System, aber es kommt im vlan11 aus der proxmox. Das geht, wenn man ein Interface ohne vlan aware im vlan erstellt.
Meytongeraffel
Messrahmen und Co laufen im großen 192er Netz
Switchports zur Übersicht
pfsense ist untagged 1 und vlan 10, 11, 50 tagged
proxmoxx2 untagged 10 und 11 tagged
Meytongeraffel untagged 11
Ich kann vom Meytonserver hinter dem proxmoxx die Messrahmen erreichen. => Schlussfolgerung Vlan und Tagging von Proxmoxx und Switchport ind richtig eingestellt.
Ich kann von der pfSense wenn ich vom Interface vlan11 pinge, auch messrahmen und Co erreichen.
Ping ist nicht das Hauptaugenmerk, ich wollte eigentlich Port 80 HTTP aber das geht auch nicht (zwecks Firewalling bei ping)
Heißt auch da ist beim Switch mit vlan usw alles sauber, denn ich erreiche ja grundsätzlich das Netz.
Was nicht geht ist von vlan10 oder vlan1 in das vlan11
Nun dachte ich, dass aus vlan1 eine any any any dafür ausreicht in vlan11 zu kommen.
Ich muss jedoch mal schauen, ob ich in dem vlan11 nicht schon eine Deny Source vlan11, Destination vlan1 Regel habe.
Das Internet soll für das Meytonnetz generell verboten sein, deshalb ist da kaum Regelwerk. Später mal eine Webseite aber da schaue ich dann gesondert, das ist jetzt gerade kein Thema
Screenshots vom Regelwerk liefere ich sonst nach
Ob Virtualisierung sinnvoll ist
Ist absolut OK, solange du den vSwitch des Hypervisors im Layer 2 korrekt konfigurierst so das die entsprechenden (VLAN) Netzsegmente auch immer genau da ankommen an der Firewall wo sie sollen! (Siehe Tutorial)wovon 3 die IPs doppelt vergeben haben
Gruselig und nicht gerade professionell! Aber wer mit russischem (IP) Roulette leben kann..nur zu. Die pfSense Segmentierung ist soweit absolut OK.
Meyton Server auf 192.168.10.200 (wie in der Liste) untagged für das System, aber es kommt im vlan11 aus der proxmox.
Klingt etwas wirr, denn normalerweise aktiviert man auf dem vSwitch das Tagging, weist die 11 zu damit das sauber ist. (Tutorial oben)Aber egal, solange du das pfSense Interface im 192.168.0.0/16er VLAN pingen kannst und die 16 Bit Maske im 11er VLAN konsistent ist ist alles OK.
Deine Pingchecks zeigen ja letztlich auch das das alles OK ist und die Netz Infrastruktur damit vermutlich nicht das Problem ist sondern eher das Regelwerk.
Ohne die Regeln kann man aber nur im freien Fall raten.
⚠️ Bedenke immer das hier 2 wichtige Grundregeln gelten:
- Regeln wirken immer nur INBOUND! Also VOM Netzwerk Draht IN das Firewall Interface hinein! (Wichtig für die Source und Destination Adressen)
- Es gilt "First match wins"! Sprich beim ersten positiven Hit im Regelwerk wir der Rest nicht mehr abgearbeitet. Reihenfolge zählt also!
Im Zweifel erstmal an den betroffenen Interfaces ein Protokoll: IPv4, Source: Interface_LAN, Destination: ANY setzen und die FW öffenen, Funktion checken und danach dann sukkzessive das Regelwerk anpassen und explizit nur das zulassen was man möchte.
Die übliche strategische Vorgehensweise damit man sicher sein kann das evtl. Fehler einzig nur am Regelwerk liegen.
Also ich bin jetzt nicht vor Ort
Ooops...dafür hat man doch immer ein VPN auf der pfSense?? PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
So, das Ganze lässt mir natürlich auch keine Ruhe, also bin ich noch mal hingefahren.
wovon 3 die IPs doppelt vergeben haben
Gruselig und nicht gerade professionell! Aber wer mit russischem (IP) Roulette leben kann..nur zu. face-wink
Die pfSense Segmentierung ist soweit absolut OK.
Zu dem Thema: Ein Messrahmen hat beispielsweise die 192.168.11.6 (Stand 6) und das dazugehörige Tablet, was auch immer soll laut deren Design die 192.168.10.6 haben.
Am Tablet wird ein Browser aufgerufen mit eben der StandIP. Soweit so einfach.
Wir haben aber bei Stand 1-3 Luftgewehr und KK hintereinander in einer Schießbahn. Es kann natürlich nur eins von Beiden laufen und das wird auch technisch Stromseitig gesperrt, weil das eine auch weg fährt und verriegelt.
Das ist ja auch nicht das Thema, jedoch kann ich so das Display ohne zu grabbeln automatisch auch für den anderen Rahmen nehmen. Sonst müsste man ja was umstellen und erkläre mal den Herrschaften was eine IP ist usw. Es ist somit vereinfacht.
Nun aber zu dem Regelwerk und Co.
Ich habe nun für das LAN Netz und Meyton entsprechende Screenshots. VLAN10 ist analog dazu.
Das LAN-Netz
Die dazugehörigen Regeln, erstmal alles offen
Das Meyton Megasubnet
Die dazugehörigen Regeln (temporär oben ein Scheunentor zum Test eben)
Die Ping-Versuche
Vom LAN
von der Meytonschnittstelle.
So, da ich von der Meytonschnittstelle pingen kann, gehe ich davon aus, dass Switch, proxmox Meyton und alles dazwischen passend konfiguriert ist, da ich mit vlan11 ja passend raus komme und alles andere routet ja wenn intern die pfsense
wovon 3 die IPs doppelt vergeben haben
Gruselig und nicht gerade professionell! Aber wer mit russischem (IP) Roulette leben kann..nur zu. face-wink
Die pfSense Segmentierung ist soweit absolut OK.
Zu dem Thema: Ein Messrahmen hat beispielsweise die 192.168.11.6 (Stand 6) und das dazugehörige Tablet, was auch immer soll laut deren Design die 192.168.10.6 haben.
Am Tablet wird ein Browser aufgerufen mit eben der StandIP. Soweit so einfach.
Wir haben aber bei Stand 1-3 Luftgewehr und KK hintereinander in einer Schießbahn. Es kann natürlich nur eins von Beiden laufen und das wird auch technisch Stromseitig gesperrt, weil das eine auch weg fährt und verriegelt.
Das ist ja auch nicht das Thema, jedoch kann ich so das Display ohne zu grabbeln automatisch auch für den anderen Rahmen nehmen. Sonst müsste man ja was umstellen und erkläre mal den Herrschaften was eine IP ist usw. Es ist somit vereinfacht.
Nun aber zu dem Regelwerk und Co.
Ich habe nun für das LAN Netz und Meyton entsprechende Screenshots. VLAN10 ist analog dazu.
Das LAN-Netz
Die dazugehörigen Regeln, erstmal alles offen
Das Meyton Megasubnet
Die dazugehörigen Regeln (temporär oben ein Scheunentor zum Test eben)
Die Ping-Versuche
Vom LAN
von der Meytonschnittstelle.
So, da ich von der Meytonschnittstelle pingen kann, gehe ich davon aus, dass Switch, proxmox Meyton und alles dazwischen passend konfiguriert ist, da ich mit vlan11 ja passend raus komme und alles andere routet ja wenn intern die pfsense
Zitat von @aqui:
Also ich bin jetzt nicht vor Ort
Ooops...dafür hat man doch immer ein VPN auf der pfSense?? Noch nicht, kommt noch und soll auch diesmal ipsec mit ikev2 werden und nicht opensense.
Aktuell käme ich von zu Hause WAN-seitig auf das GUI. Die inbound Regel ist auf meine öffentliche IP eingeschränkt.
Zu Hause habe ich OpneVPN, das spackt aber seit kurzem und ich muss das mal tiefer durchleuchten.
Ich habe da letztens von 2.52 geupdatet. Das Konstrukt läuft eigentlich auch, selbst mit der Cloud pfSense um mein CG-Nat zu umgehen.
Am Android verbindet es sich weiterhin ohne Probleme, weshalb es mir erstmal nicht aufgefallen ist.
Bei Windows meckert er.
Er sagt er sei verbunden, bekommt auch seine IP zugewiesen, dann der Fehler. Ich habe da die Vermutung, dass eher Windows das Problem ist nach einem Update oder so, da 2 Laptops identisch reagieren und Android geht.
Das ist aber ein Nebenschauplatz und nicht das eigentliche Thema
Die dazugehörigen Regeln (temporär oben ein Scheunentor zum Test eben)
Das Meyton Interface Regelwerk ist so nicht korrekt aber ggf. zum Test erstmal so gewollt?!- Das erste Statement ist fehlerhaft. Keinesfalls sollte man als Source hier "any" definieren sondern IMMER, wie ja auch beim Admin LAN, das Netzwerk VLAN11_Meyton_subnets. An diesem Interface kann und dürfen prinzipbedingt ja niemals andere Absender IPs als solche vom 192.168.x.x Netz auftreten! Wenn dem so wäre will man die nicht dort haben! Also als Source so setzen wie am LAN mit der Netzwerk Adresse.
- Das erste Regelwerk führt als Scheunentorregel so immer IMMER zu einem positiven Hit, weil es alles überall hin erlaubt. Die beiden folgenden Blocking Regeln werden also NICHT mehr abgearbeitet und sind damit obsolet. REIHENFOLGE zählt!! Nur das du das auf dem Radar hast. Gut, ist ggf. ja erstmal so gewollt?!?
gehe ich davon aus, dass Switch, proxmox Meyton und alles dazwischen passend konfiguriert ist
Wenn du die zusätzlich zur .11.6 auch mit der VLAN 11 IP als Absender pingen kannst ist dem so! Denke dran das du ggf. TCP/UDP 53 später bei strikterem Regelwerk auch aus dem Meyton Segment passieren lässt, ansonsten scheitert die DNS Auflösung!
auch diesmal ipsec mit ikev2 werden und nicht opensense.
Du meintest sicher das gruselige und antike OpenVPN, oder? Aber Nebenschauplatz und andere Baustelle. Mit IKEv2 oder L2TP ist das kein Thema mehr. Erstmal dein Regelwerk fixen! 😉
1
Das von oben nach unten abgearbeitet wird, ist bekannt. First Match Winns ist ein Begriff.
Ziel war es erstmal die Verbindung hinzubekommen, deshalb oben um alles andere auszuschließen die Scheunentore.
Ich habe als Source jetzt das meyton Subnet. Das war jetzt im Test ein Schönheitsfehler, das kann ja keine Besserung hervorrufen.
Nur was kann es noch sein?
Eine Art Firewall im Gerät, die alles ausserhalb 192.168.0.0/16 abblockt?
Der Ping kommt ja quasi aus dem Netz von der pfsense über 192.168.0.1
Edit: Ich habe eben beim "Server" mal geschaut, da ist alles was Internet ist ausgetragen, das ist wohl auch so gewollt steht da. ich habe Gateway und DNS mal manuell gesetzt. Das alles natürlich wieder in der pfSense geblockt. Aber wenn man Internet benötigt, kann man es sich freischalten.
Aber ist das ursächlich, dass ich die Messrahmen nicht erreiche über Ping?
Ziel war es erstmal die Verbindung hinzubekommen, deshalb oben um alles andere auszuschließen die Scheunentore.
Ich habe als Source jetzt das meyton Subnet. Das war jetzt im Test ein Schönheitsfehler, das kann ja keine Besserung hervorrufen.
Nur was kann es noch sein?
Eine Art Firewall im Gerät, die alles ausserhalb 192.168.0.0/16 abblockt?
Der Ping kommt ja quasi aus dem Netz von der pfsense über 192.168.0.1
Edit: Ich habe eben beim "Server" mal geschaut, da ist alles was Internet ist ausgetragen, das ist wohl auch so gewollt steht da. ich habe Gateway und DNS mal manuell gesetzt. Das alles natürlich wieder in der pfSense geblockt. Aber wenn man Internet benötigt, kann man es sich freischalten.
Aber ist das ursächlich, dass ich die Messrahmen nicht erreiche über Ping?
Was auffällt, die Messrahmen als solches haben nur eine IP hinterlegt, kein Gateway oder DNS
Kann das der Grund sein, warum die Rückroute nicht klappt?
Wobei ja die pfsense die Schnittstelle dort hat und das eigentlich Routen müsste
Kann das der Grund sein, warum die Rückroute nicht klappt?
Wobei ja die pfsense die Schnittstelle dort hat und das eigentlich Routen müsste
Zitat von @fnbalu:
Was auffällt, die Messrahmen als solches haben nur eine IP hinterlegt, kein Gateway oder DNS
Kann das der Grund sein, warum die Rückroute nicht klappt?
Jepp, wenn die kein DefaultGW haben, musst du dafür sorgen, dass du den Traffic auf die IP der pfSense in diesem Subnetz SRC-NATest (Masquerade) (Abschnitt Outbound NAT), dann sieht es für die Geräte so aus als komme der Traffic aus ihrem eigenen Subnetz und sie schicken die Antwortpakete an die pfSense zurück.Was auffällt, die Messrahmen als solches haben nur eine IP hinterlegt, kein Gateway oder DNS
Kann das der Grund sein, warum die Rückroute nicht klappt?
Wobei ja die pfsense die Schnittstelle dort hat und das eigentlich Routen müsste
Nee, ein Client der kein Default GW hat weiß nicht wohin er die fremden Pakete schicken soll, außer du hast Einfluss auf die Einstellungen an den Geräten und kannst dort entweder ein DefaultGW oder alternativ auch eine statische Route nachtragen.2
Puh, da muss ich Neuland betreten.
Ich dachte das geht dann sonst über die pfsense Schnittstelle in dem Subnetz zurück
Ich dachte das geht dann sonst über die pfsense Schnittstelle in dem Subnetz zurück
Ist ja kein Hexenwerk. Outbound NAT auf "Hybrid" stellen. Dann neue SRC-NAT Regel mit Interface = Gerätenetz und Source = dem Netz von dem aus du die Geräte erreichen willst, Destination = Gerätenetz, Aktion = Umschreiben auf Interface-Adresse (Masquerade), schon lüppt dat.
2Was auffällt, die Messrahmen als solches haben nur eine IP hinterlegt, kein Gateway oder DNS
Aber dann ist es doch klar das das Erreichen aus Fremdnetzen zu mindestens bei den Komponenten fehlschlägt!!Wie sollte das auch gehen wenn denen das Gateway fehlt und sie nicht wissen wie sie das Absender IP Netz erreichen!? Du solltest ggf. HIER nochmal bei einem Paket Flow deine Routing Kenntnisse etwas "auffrischen"! 🧐 Kollege @150704 hat ja schon alles dazu gesagt.
Puh, da muss ich Neuland betreten.
Einfach mal das o.a. Routing Tutorial lesen!! 😉Wenn du ein Gateway eintragen kannst löst das sofort das Problem. Kannst du es nicht hilft der NAT Workaround des Kollegen oben.
Ich danke Euch und werde nach dem Test berichten.
Da theoretisch 2 Netze rüber sollen, denke ich 2 Regeln.
Kurios ist, dass die Messrahmen eine statische IP haben.
Aber für eine neue Funktion Internet benötigen und ein zweites Netz aufspannen, das wiederum nutzt DHCP.
Ich muss mal testen, ob dann alles darüber geht, aber ich denke, dass die Standard IP nur über den oben genannten Weg geht.
Da theoretisch 2 Netze rüber sollen, denke ich 2 Regeln.
Kurios ist, dass die Messrahmen eine statische IP haben.
Aber für eine neue Funktion Internet benötigen und ein zweites Netz aufspannen, das wiederum nutzt DHCP.
Ich muss mal testen, ob dann alles darüber geht, aber ich denke, dass die Standard IP nur über den oben genannten Weg geht.
Kurios ist, dass die Messrahmen eine statische IP haben.
Da solltest du dem Hersteller mal gehörig heimleuchten. Solche rumpelige und dillettantische IP Einrichtung geht gar nicht wenn man viel Geld für so ein Produkt bezahlt. Der 2te Marktführer bei diesen Anlagen hat sowas "Krankes" zu mindestens nicht. Aber für eine neue Funktion Internet benötigen und ein zweites Netz aufspannen, das wiederum nutzt DHCP.
Was willst du uns mit dem kryptischen Rumpelsatz sagen? 🤔aber ich denke, dass die Standard IP nur über den oben genannten Weg geht.
Mit der Standard IP hat das ja wenig zu tun wie dir schon gesagt wurde. Es ist einzig das fehlende Gateway was die Einbindung in geroutete IP Netze verhindert. Der NAT Workaround oben kompensiert das aber sowas sollte man keinem Kunden aufzwingen der die Anlage wie in deinem Falle in ein bestehendes Netzwerk integriert. Es ist ja von einem Hersteller ziemlich naiv und weltfremd davon auszugehen das er ITtechnisch überall grüne Wiese hat. Wie ein Hersteller so schludrig und dillettantisch arbeiten kann diesbezüglich wirft kein gutes Licht auf deren Produktqualität. Der Mitbewerber in dem Umfeld kann das, wie bereits gesagt, deutlich besser.
Sodele, es war nicht anders zu erwarten, das TUT von Ted funktioniert.
Ihr seid echt der Hammer. Es ist auch als Lösung markiert.
Es ist halt ein unterschied, wenn man sich etwas aneignet und so der einäugige unter den Blinden ist, oder so etwas mal gelernt hat.
Das schöne ist, die Messrahmen können tatsächlich Internet herstellen.
Aber nicht, dass das über die bisherige IP-Geschichte von oben geschieht, man kann tatsächlich nur die IP einstellen und nichts anderes.
Nein, man aktiviert einen DHCP Button und dort wird zusätzlich ein zweites Netz mit Internet aufgespannt.
Das ist dann dafür, dass man Ergebnisse auf deren Server laden kann. Das heißt man lässt einen QR-Code als Link generieren und kann dann die Ergebnisse abrufen. Für Kinder recht nice.
Ihr seid echt der Hammer. Es ist auch als Lösung markiert.
Es ist halt ein unterschied, wenn man sich etwas aneignet und so der einäugige unter den Blinden ist, oder so etwas mal gelernt hat.
Das schöne ist, die Messrahmen können tatsächlich Internet herstellen.
Aber nicht, dass das über die bisherige IP-Geschichte von oben geschieht, man kann tatsächlich nur die IP einstellen und nichts anderes.
Nein, man aktiviert einen DHCP Button und dort wird zusätzlich ein zweites Netz mit Internet aufgespannt.
Das ist dann dafür, dass man Ergebnisse auf deren Server laden kann. Das heißt man lässt einen QR-Code als Link generieren und kann dann die Ergebnisse abrufen. Für Kinder recht nice.
