8
Subnet routing pfSense
Hallo Zusammen,
heute muss ich mich mal mit einem Problem an Euch wenden, das:
a) Bestimmt schon diskutiert/erklärt wurde
b) Ich über die Suche aber leider keine Lösung gefunden habe
Auf meiner pfSense - 2.1.4-RELEASE (i386) sind folgende Netze eingerichtet:
ALPHA - 10.0.0.0/24 (vr0)
BRAVO - 10.0.0.1/24 (vr2)
Folgendes funktioniert:
PING Client ALPHA (10.0.0.2) -> Client ALPHA (10.0.0.4)
PING Client BRAVO (10.0.1.2) -> Client ALPHA (10.0.0.2)
PING Client ALPHA (10.0.0.2) -> Client BRAVO (10.0.1.2)
Was nicht funktioniert und wobei ich nun Unterstützung benötige, ist ein:
PING Client BRAVO(10.0.1.2) -> Client ALPHA (10.0.0.4)
In den Firewallrules sind keine Beschränkungen auf Clients eingetragen. Folgerichtig erhalten ich auch bei einem Zugriff von 10.0.1.2 auf 10.0.0.4 keinen Logeintrag in der Firewall.
Offensichtlich scheint also das Routing zu funktionieren.
Hat vielleicht jemand eine Idee, warum nur der PING von 10.0.1.2 auf 10.0.0.4 verloren geht und wo ich anfangen zu suchen soll ?
Danke + viele Grüße,
Andreas
heute muss ich mich mal mit einem Problem an Euch wenden, das:
a) Bestimmt schon diskutiert/erklärt wurde
b) Ich über die Suche aber leider keine Lösung gefunden habe
Auf meiner pfSense - 2.1.4-RELEASE (i386) sind folgende Netze eingerichtet:
ALPHA - 10.0.0.0/24 (vr0)
BRAVO - 10.0.0.1/24 (vr2)
Folgendes funktioniert:
PING Client ALPHA (10.0.0.2) -> Client ALPHA (10.0.0.4)
PING Client BRAVO (10.0.1.2) -> Client ALPHA (10.0.0.2)
PING Client ALPHA (10.0.0.2) -> Client BRAVO (10.0.1.2)
Was nicht funktioniert und wobei ich nun Unterstützung benötige, ist ein:
PING Client BRAVO(10.0.1.2) -> Client ALPHA (10.0.0.4)
In den Firewallrules sind keine Beschränkungen auf Clients eingetragen. Folgerichtig erhalten ich auch bei einem Zugriff von 10.0.1.2 auf 10.0.0.4 keinen Logeintrag in der Firewall.
Offensichtlich scheint also das Routing zu funktionieren.
Hat vielleicht jemand eine Idee, warum nur der PING von 10.0.1.2 auf 10.0.0.4 verloren geht und wo ich anfangen zu suchen soll ?
Danke + viele Grüße,
Andreas
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: 245600
Url: https://administrator.de/contentid/245600
Printed on: April 25, 2024 at 11:04 o'clock
8 Comments
Latest comment
Hallo Andreas,
Grüße Uwe
Hat vielleicht jemand eine Idee, warum nur der PING von 10.0.1.2 auf 10.0.0.4 verloren geht und wo ich anfangen zu suchen soll ?
schau mal in die Client-Firewall auf dem System mit der 10.0.0.4, diese verhindert zu 99% ICMP Requests aus einem anderen Subnetz.Grüße Uwe
Hallo Andreas!
Was liefert denn ein tracert von Client 10.0.1.2 auf Client 10.0.0.4?
Und was ein traceroute von der PfSense auf den Client? (Da kannst du auch das absendende Interface bestimmen...)
Gruss
Buc
Was liefert denn ein tracert von Client 10.0.1.2 auf Client 10.0.0.4?
Und was ein traceroute von der PfSense auf den Client? (Da kannst du auch das absendende Interface bestimmen...)
Gruss
Buc
Auf meiner pfSense - 2.1.4-RELEASE (i386) sind folgende Netze eingerichtet:
ALPHA - 10.0.0.0/24 (vr0)
BRAVO - 10.0.0.1/24 (vr2)
BRAVO - 10.0.0.1/24 (vr2)
Da ist in sich schon ein Fehler !!!
Das sind keine 2 Netze sondern nur ein einziges , nämlich das Netzwerk 10.0.0.0 mit einer 24 Bit Maske !
Ist das nur ein Tippfehler hier im Thread oder hast du das wirklich so falsch eingerichtet ?? Mal abgesehen davon das du an vr0 ein Netzwerk angegeben hast und an vr2 eine Hostadresse was ebenso falsch ist aber an der Tatsache der fehlenden 2 IP Netze auch nichts ändert ?!
Normal kann man die pfSense auch gar nicht so mit 2 Adaptern im gleichen Netz einrichten, denn das meckert sie logischerweise gleich an weil falsch ! Einzige Ausnahme: du konfigurierst ein Bridging zwischen vr0 und vr2 was du aber ja nicht hast.
Interpretiert man deine Ping Versuche und die Angaben dort müsste es eigentlich so sein:
vr0 IP: 10.0.0.1, Maske: 255.255.255.0, Netzwerk: 10.0.0.0 /24
vr2 IP: 10.0.1.1, Maske: 255.255.255.0, Netzwerk: 10.0.1.0 /24
Ist dem so ??
Wenn das stimmt und immer noch
Was nicht funktioniert:
PING Client BRAVO(10.0.1.2) -> Client ALPHA (10.0.0.4)
gilt dann hat einer dieser Clients KEIN Gateway konfiguriert auf die pfSense IP in seinem jeweiligen IP Netz oder...PING Client BRAVO(10.0.1.2) -> Client ALPHA (10.0.0.4)
da ein Ping aus einem fremden Netz kommt blockiert den die lokale Firewall auf einem dieser Clients !!
Letzteres wahrscheinlicher....?!
Klar, das sonst da dann eine Wegefindung (Routing) und somit auch Ping und alles andere fehlschlagen muss wenn die erste Angabe oben stimmen sollte mit einem geminsamen 10.0.0.0er Netz auf den Ports vr0 UND vr2 ?!
Hallo,
erstmal vielen Dank an alle Helfenden.
@aqui
Du hast mich erwischt ! Die Finger waren mal wieder schneller als der Kopf
Natürlich muss es heissen:
ALPHA - 10.0.0.0/24 (vr0)
BRAVO - 10.0.1.0/24 (vr2)
Hintergrund ist der, das vor ein paar Tagen am kompletten Standort Stromausfall gewesen ist.
Danach war die pfSense (ALIX.2D13) nicht mehr erreichbar. Erst ein Neuflashen der CF-Karte brachte die Sache wieder ans laufen.
Vor dem Stromausfall hat die Konfiguration gepasst. Ich hatte die Interfaces und Subnetze danach wieder neu konfiguriert und nun stehe ich vor dem beschriebenen Problem. Ich hatte vermutet, irgendetwas "übersehen" zu haben, aber evtl. hat die Firewall nun auch einen Hardwareschaden, obwohl sie durch eine USV geschützt sein sollte.
Seltsam ist eben, das auf der pfSense:
PING BRAVO_net -> 10.0.0.4 verloren geht
und
PING BRAVO_net -> 10.0.0.2 received wird.
Gruß Andreas
erstmal vielen Dank an alle Helfenden.
ALPHA - 10.0.0.0/24 (vr0)
BRAVO - 10.0.0.1/24 (vr2)
BRAVO - 10.0.0.1/24 (vr2)
Da ist in sich schon ein Fehler !!!
@aqui
Du hast mich erwischt ! Die Finger waren mal wieder schneller als der Kopf
Natürlich muss es heissen:
ALPHA - 10.0.0.0/24 (vr0)
BRAVO - 10.0.1.0/24 (vr2)
da ein Ping aus einem fremden Netz kommt blockiert den die lokale Firewall auf einem dieser Clients !!
Leider handelt es sich bei den Clients um MuFu's (Drucker/Scanner/Fax/Kopierer) die keine eigene Firewall haben.Hintergrund ist der, das vor ein paar Tagen am kompletten Standort Stromausfall gewesen ist.
Danach war die pfSense (ALIX.2D13) nicht mehr erreichbar. Erst ein Neuflashen der CF-Karte brachte die Sache wieder ans laufen.
Vor dem Stromausfall hat die Konfiguration gepasst. Ich hatte die Interfaces und Subnetze danach wieder neu konfiguriert und nun stehe ich vor dem beschriebenen Problem. Ich hatte vermutet, irgendetwas "übersehen" zu haben, aber evtl. hat die Firewall nun auch einen Hardwareschaden, obwohl sie durch eine USV geschützt sein sollte.
Seltsam ist eben, das auf der pfSense:
PING BRAVO_net -> 10.0.0.4 verloren geht
und
PING BRAVO_net -> 10.0.0.2 received wird.
Gruß Andreas
Hallo Andreas !
OK, check aber sicherheitshalber auch nochmal auf der pfSense Adressierung das du da auch nicht denselben Tippfehler begangen hast, das wäre dann fatal
Mit dem Stromausfall ist schon komisch.... Normal übersteht die FW sowas klaglos und geht auch nicht kaputt oder sowas. Ist ja nix anderes als wie ein normales Computer Mainborad und die sterben ja auch nicht wenn nur mal der Strom weggeht. Es sei denn das ist ein Blitzschlag oder sowas da siehts dann natürlich anders aus, klar
Da sie ja einen nicht flüchtigen Flash Speicher hat kommt sie immer wieder sauber hoch. Ein sauberer Kaltstart sollte sie also immer wieder auf die Füsse bringen OHNE ein Neuflashen der CF Karte ?!
Auch "Ich hatte die Interfaces und Subnetze danach wieder neu konfiguriert..." ist natürlich NICHT nötig, denn du solltest immer eine Sicherung der Konfig von der Box ziehen !!!
Das macht man im Menüpunkt "Diagnostics" und dann "Backup/Restore" !
Dann kannst du in einem solchen Fall des Neuflashens ganz einfach immer nur die Sicherungsdatei einspielen et voila so ist das Ding dann in 10 Sekunden neu konfiguriert.
OK, wenn ein Ping von allen Clients am 10.0.1.0/24 auf die 10.0.0.2 im Alpha Netz (10.0.0.0/24) funktioniert wird ICMP (Ping) ja generell sauber durch die pfSense geroutet wie es auch zu erwarten ist sofern keine Blocking Regeln auf den vr0 und vr2 Interfaces der FW definiert sind !
Das 10.0.0.4 nicht pingbar ist liegt dann zu 98% auch an diesem Client selber !
Starke Vermutung: Dort ist KEIN oder ein falsches Gateway eingetragen ?!!
Checke also den 10.0.0.4er Client ob dort ein Gateway eingetragen ist das Gateway dort MUSS die pfSense IP sen 10.0.0.1 ! Oder ein Router der eine Router auf das Netzwerk 10.0.1.0/24 eingetragen hat mit der pfSense IP als Next Hop Gateway !
Mache mal einen Traceroute oder Pathping zur 10.0.0.4 um zu sehen wo es stockt.
Mit
OK, check aber sicherheitshalber auch nochmal auf der pfSense Adressierung das du da auch nicht denselben Tippfehler begangen hast, das wäre dann fatal
Mit dem Stromausfall ist schon komisch.... Normal übersteht die FW sowas klaglos und geht auch nicht kaputt oder sowas. Ist ja nix anderes als wie ein normales Computer Mainborad und die sterben ja auch nicht wenn nur mal der Strom weggeht. Es sei denn das ist ein Blitzschlag oder sowas da siehts dann natürlich anders aus, klar
Da sie ja einen nicht flüchtigen Flash Speicher hat kommt sie immer wieder sauber hoch. Ein sauberer Kaltstart sollte sie also immer wieder auf die Füsse bringen OHNE ein Neuflashen der CF Karte ?!
Auch "Ich hatte die Interfaces und Subnetze danach wieder neu konfiguriert..." ist natürlich NICHT nötig, denn du solltest immer eine Sicherung der Konfig von der Box ziehen !!!
Das macht man im Menüpunkt "Diagnostics" und dann "Backup/Restore" !
Dann kannst du in einem solchen Fall des Neuflashens ganz einfach immer nur die Sicherungsdatei einspielen et voila so ist das Ding dann in 10 Sekunden neu konfiguriert.
OK, wenn ein Ping von allen Clients am 10.0.1.0/24 auf die 10.0.0.2 im Alpha Netz (10.0.0.0/24) funktioniert wird ICMP (Ping) ja generell sauber durch die pfSense geroutet wie es auch zu erwarten ist sofern keine Blocking Regeln auf den vr0 und vr2 Interfaces der FW definiert sind !
Das 10.0.0.4 nicht pingbar ist liegt dann zu 98% auch an diesem Client selber !
Starke Vermutung: Dort ist KEIN oder ein falsches Gateway eingetragen ?!!
Checke also den 10.0.0.4er Client ob dort ein Gateway eingetragen ist das Gateway dort MUSS die pfSense IP sen 10.0.0.1 ! Oder ein Router der eine Router auf das Netzwerk 10.0.1.0/24 eingetragen hat mit der pfSense IP als Next Hop Gateway !
Mache mal einen Traceroute oder Pathping zur 10.0.0.4 um zu sehen wo es stockt.
Mit
Hallo aqui,
so, das Problem ist behoben !
Vielen Dank nochmal an Dich für die kompetente Hilfe und Vorschläge.
Es war tatsächlich so, dass einige Clients aus dem ALPHA Netz keine IP Einstellungen vom DHCP bekommen haben. Vermutlich hat nach dem Stromausfall der Client schneller gebootet als die pfSense.
Obwohl mir versichert wurde, das die fehlerhaften Clients alle mal neu gestartet wurden (Ein- Ausschalten) habe ich bei meinem Besuch am Standort heute. Nochmals die Clients neu gestartet. Naja, was soll ich sagen, mein Neustart war erfolgreicher als der, der Kollegen
Danke + Gruß,
Andreas
so, das Problem ist behoben !
Vielen Dank nochmal an Dich für die kompetente Hilfe und Vorschläge.
Es war tatsächlich so, dass einige Clients aus dem ALPHA Netz keine IP Einstellungen vom DHCP bekommen haben. Vermutlich hat nach dem Stromausfall der Client schneller gebootet als die pfSense.
Obwohl mir versichert wurde, das die fehlerhaften Clients alle mal neu gestartet wurden (Ein- Ausschalten) habe ich bei meinem Besuch am Standort heute. Nochmals die Clients neu gestartet. Naja, was soll ich sagen, mein Neustart war erfolgreicher als der, der Kollegen
Danke + Gruß,
Andreas
das ist ja nun ein hervorragendes beispiel dafür, warum man solche "clients" mit festen ip-adressen ausstatten sollte.
schulligung.
schön, dass es wieder läuft.
el buco
schulligung.
schön, dass es wieder läuft.
el buco
das ist ja nun ein hervorragendes beispiel dafür, warum man solche "clients" mit festen ip-adressen ausstatten sollte.
Da gebe ich Dir absolut recht.Aber als Gegenargument möchte ich anführen, das eine zentrale Administration auch ihre Vorteile hat. Vorallem, wenn jemand einen Client unter den Arm nimmt und im anderen Büro in ein anderes Netz hängt.
