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?
Please also mark the comments that contributed to the solution of the article
Content-ID: 668600
Url: https://administrator.de/contentid/668600
Printed on: November 4, 2024 at 09:11 o'clock
29 Comments
Latest comment
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
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
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“…
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.
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!
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
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! 😉
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.Was 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.
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.