the-buccaneer
Goto Top

PfSense Installationsproblem (Ping Timeouts LAN-Port)

Schon die Überschrift war nicht leicht, knackig zu formulieren, das war strange...

Hatte heute folgendes Problem bei einer PfSense Installation:

Vorhandenes Netzwerk 192.168.2.0. Bisheriger Router Linksys WRT 54 GL: 192.168.2.1 Dahinter Cisco Kabelmodem (Unitymedia).

Internetzugang funktioniert aktuell prima via DHCP, der Linksys bekommt die externe IP von Unitymedia.

Ich sitze am Server (192.168.2.2) und will die frisch angeschlossene PfSense (192.168.2.3) konfigurieren.

PfSense hängt dazu noch an einem freien Port des Linksys. Ursprünglich komme ich auf die WebGUI und fange an, die Einstellungen vorzunehmen. (WAN per DHCP etc.). Dann Test: Cisco-Modem Kabel im WAN Port. Geht nicht. Keine IP auf WAN. (0.0.0.0)

O.K. hätte das Kablemodem neu starten müssen...
Nun aber: ("Ich hab ehrlich nix gemacht!" face-wink ) Pfsense vom Server nicht mehr erreichbar. (Keine WebGUI, kein Ping)

PfSense Interfaces neu konfiguriert, WAN und LAN getauscht, keine Abhilfe. Linksys neu gestartet. Nix.

192.168.2.2 hat keine Verbindung mehr zu 192.168.2.3. Kabel gewechselt, Ports getauscht. TOT.

Tracert liefert auch nix. (Server-->Linksys>PfSense)

Mitarbeiter neben mir gefragt, bitte geh doch mal auf 192.168.2.3 und siehe da: Die Login Seite.
Ich also an einen mittlerweile frei gewordenen Arbeitsplatz gewechselt und ich komme auf die PfSense und bekomme die soweit konfiguriert, dass die externe IP auf dem WAN Interface erscheint. (Den Modem Neustart nicht vergessen face-wink )

Einträge auf dem SBS 2003 angepast (Router, Standardgateway im DHCP und die DNS Weiterleitung)

Gejubelt, aber zu früh:

Denn: Wieder nix. Pings liefern Packet Loss von ca. 50%.

Also langsam richtig genervt auf dem PfSense LAN Interface mit der Speed and Duplex Einstellung experimentiert.

Linksys kann offenbar nur Auto Negotiation (habe keine Config gefunden) trotzdem mal ohne Besserung auf der pfSense verschiedene (nicht alle) Einstellungen probiert. Wieder keine Abhilfe. Also hatte ich die Ports des Linksys im Verdacht, da ich etwas ähnliches vor kurzem mit einem defekten Siemens Router hatte. (Spricht aber dagegen, dass er in der original Konfig. ja lief und aktuell läuft.)

Neuen (Consumer-)Switch aus dem Auto geholt und alles dort angeschlossen: Keine Änderung. Paketverlust ca. 50 %

Kunde hat Feierabend, ich keine Idee mehr, ausser, dass die PfSense auf den Netzwerkports ein Problem haben könnte. (Neue Hardware!)
PfSense wieder eingepackt, Netzwerk wieder umgestellt, Kunde hat intern und extern mit dem Linksys Zugriff, keine Zeit für weitere Tests.

PfSense in der Werkstatt angeschlossen: Läuft stabil. Keine Paketverluste.

WAS in Gottes Namen habe ich da übersehen? Ich habe ein solches Prozedere mittlerweile zigmal gemacht, auch mit dieser Hardware.

Es geht nie zu 100% glatt, irgendwo hakt es immer, aber das ist i.A. lösbar und gehört dazu.

Alles, was ich finden konnte, waren Hinweise in Richtung Speed / Duplex Einstellungen. Da der Linksys nun aber keine manuelle Auswahl gestattet, sollte da doch "Auto" auf PfSense Seite in Ordnung gehen. Und warum kann der eine Client zugreifen, der andere aber nicht?

Und was erklärt die Paketverluste zur PfSense, wenn gleichzeitig ein Ping auf einen anderen Client absolut stabil läuft?

Ich werde morgen versuchen, das extrem systematisch anzugehen, aber evtl. hat ja ein Frühaufsteher oder Nachtarbeiter ne Idee? Ich bin grade etwas ratlos...

Der Buco

Content-Key: 245123

Url: https://administrator.de/contentid/245123

Printed on: April 19, 2024 at 19:04 o'clock

Member: aqui
Solution aqui Jul 31, 2014 updated at 17:48:49 (UTC)
Goto Top
Eine ganz entscheidende Frage hast du leider nicht beantwortet ! face-sad
Auf welcher Hardware rennt denn die pfSense ???

Zum Testen der verwendeten Hardware immer erstmal strategisch vorgehen:
  • pfSense auf die Factory Defaults setzen und rebooten
  • WAN Port und LAN Port isoliert auf 2 Switches anschliessen oder ein Switch mit 2 VLANs. pfSense Hardware also allein und vollkommen isoliert betreiben und testen
  • Testrechner am LAN anschliessen und pfSense auf dem WAN Port eine statische IP geben.
  • Pingtests am LAN Port machen
  • Pingtests am WAN Port machen
Das dient dazu um erstmal zu klären ob die pfSense HW generell OK ist oder das o.a. Verhalten von externen Komponenten verursacht wird !!
Es sieht in der Tat ein bischen nach einem Autonegotiation Problem aus zw. den pfSense NICs und dem oder den Switches. Hier hilft insbesondere mal ein Kabeltausch oder testweise mal ein Crossover Kabel zu verwenden wenn Autonegotiation Parameter nicht beidseitig konfigurierbar sind.
Könnte aber auch Spanning Tree sein oder Duplicate IP Adressen...das kann man so mit "lesender" Ferndiagnose in einem Forum natürlich nicht sagen und erfordert etwas mehr Infos...
Wichtig ist aber erstmal der isolierte Test um generell zu klären ob die HW in Ordinung ist.
Member: the-buccaneer
the-buccaneer Jul 31, 2014 at 08:49:48 (UTC)
Goto Top
Moin!
Läuft auf einem Intel Board D2500CC mit 2 GB RAM und HDD als Full Installation face-wink

In meinem Netz ist sie auf dem LAN Port problemlos erreichbar. (Auto Negotiation) Kann auch das WAN mal verbinden um zu sehen, ob sie routet bzw. der Port dann auch pingbar ist.

Spanning Tree lässt sich da nirgends konfigurieren. (das ist doch was für managed Switches in grösseren Umgebungen?)

Doppelte IP-Adresse hatte ich auch schon im Verdacht, da ist aber sonst nix auf der .3. Trotzdem hatte ich auch andere IP's ausprobiert mit dem beschriebenen (Miss-)Erfolg.

Crossover Kabel habe ich noch nicht verwendet. Das bliebe zu versuchen. Werde weiter berichten, irgendwo muss ja die Lösung sein...

Der Buc
Member: aqui
Solution aqui Jul 31, 2014 updated at 17:48:52 (UTC)
Goto Top
Läuft auf einem Intel Board D2500CC mit 2 GB RAM und HDD als Full Installation
Noch wichtiger: Welche NICs und werden diese NICs bzw. deren Chipsätze von FreeBSD offiziell supportet, denn das ist das unterliegende OS ?!
Gehe in die Shell Konsole der pfSense und gib mal dmesg ein, dann siehst du die Bootmeldungen des Systems und ob die NIC HW sauber erkannt wurde.
Da ja isoliert alles sauber funktioniert können wir aber mal sicher davon ausgehen das dem so ist !
das ist doch was für managed Switches in grösseren Umgebungen?
Nöö, gibts auch auf kleinen (managed) 8 Port Switches und auch in kleinen Umgebungen und ist ein Muss immer im Falle von redundanten Netzwerk Designs. Wenn du keinerlei redundante Netzwerke hast oder nur dumme, unmanaged Switches ist das natürlich kein Thema, keine Frage.

Wenn aber die isolierten Tests wie du sagst eine absolut fehlerfreie Funktion der Hardware ergeben haben, dann liegt es ja ganz klar an den im Produktiv Umfeld verwendeten Switch Komponenten.
Auch hier solltest du dann mal strategisch Schritt für Schritt vorgehen und...
  • ...erstmal nach dem Factory Reset nur einzig den LAN Port auf die verwendete neue IP umstellen und die Firewall Regel entsprechend anpassen, denn die verschwindet mit neuer IP !!
  • Dann nur einzig den LAN Port einbeinig ins lokale LAN hängen ! Checke vorher das die verwendete IP nicht benutzt wird, das es keine DHCP Server Konflikte gibt usw. STP ist im Default inaktiv auf der pfSense.
  • Dann den Ping Test wiederholen. Schliesst man Autonegotiation Probleme am LAN Port auf NIC und Switch aus, dann sollte so ein Ping Test dann fehlerfrei verlaufen. Wenn ja teste den Ping auch mit größeren Paket Größen bis 512 Byte um ganz sicher zu gehen !
  • Klappt es dennoch nicht ists vermutlich Autonegotiation. Dann versuche andere Kabel und ggf. ein Crossover Kabel.
Member: the-buccaneer
the-buccaneer Jul 31, 2014 at 17:48:22 (UTC)
Goto Top
Dank Dir aqui für deinen unermüdlichen Einsatz.

Jetzt kommt aber die Lösung des Problems. Es gibt überhaupt kein Problem. Zumindest nicht mehr heute Mittag. face-wink

PfSense angeschlossen und alles läuft, wie es soll. In der Zwischenzeit wurde nichts rebooted oder resetted. Es sind dieselben Ports und Kabel im Einsatz. An der PfSense wurde ebenfalls bis auf die Anpassungen für die LAN-IP wg. des Tests nichts geändert.

Habe gestern natürlich alle beteiligten Komponenten mehrfach neu gestartet, wie beschrieben ohne Effekt.

WAS war das um Himmels willen? Hat heute die heilige Jungfrau Maria ein Wunder vollbracht, oder hatte gestern Beelzebub die Hand im Spiel? Oder hat der Linksys seinen Schluckauf verloren, weil ihn nachts ein Mäuschen erschreckt hat?

Wahrscheinlich gehört es aber einfach zu den Dingen im Leben, die man hinnehmen muss. (Oder der Linksys verabschiedet sich als Hauptverdächtiger doch in naher Zukunft....) Jedenfalls vorerst gelöst.

Viele Grüße

Der Buck
Member: aqui
aqui Aug 01, 2014 at 07:59:10 (UTC)
Goto Top
hatte gestern Beelzebub die Hand im Spiel?
Genau DAS war es !!
Klasse wenn nun alles rennt wie es soll face-wink