PFSense alle paar Wochen nicht erreichbar
-
Schneller als erwartet trat das Problem wieder auf.
Zu meiner Netzwerktopologie:
192.168.2.134 - Zweite VM (Monitoring)
192.168.2.130 - Homeserver sprich VM Host in dem die NIC ist
192.168.2.120 - Workstation
192.168.2.1 - PFSense LAN
192.168.1.2 - PFSense WAN
192.168.1.1 - RouterIch habe zuerst versucht wie du gesagt hast von der PFSense GUI aus 192.168.2.120 zu pingen. Dies schlug fehl.
192.168.2.130 brachte auch keine Antwort.Von der zweiten VM aus konnte ich PFSense nicht erreichen, aber den Homeserver sprich der VM Host ist UP.
Also ging die Verbindung zur zweiten VM von der Workstation aus.Danach habe ich mir in der PFSense GUI die Logs angeschaut. Dort stand nichts bemerkenswertes drin (Ich wusste ja die Uhrzeit und konnte somit genau nachschauen).
Der letzte DHCP Request ging heute um 16:28 Uhr raus.
In der filter.log wurde der letzte Logeintrag um 18:20 Uhr geschrieben, also muss die Verbindung kurz danach abgebrochen sein.Dann habe ich die Kabel mal physisch aus dem Homeserver rausgezogen (BRLAN und BRWAN) und danach konnte ich von der Workstation nichtmehr auf die zweite VM zugreifen (das hat sich geändert) und PFSense ging dann natürlich immer noch nicht.
dmesg brachte auf dem Homeserver ziemlich viele brlan: port 4 vnet 3 entered forwarding state und brlan: port 5 vnet 4 entered disabled state.
Am Ende kamen dann die Meldungen die ich sehen wollte mit link down und link up.Danach habe ich brctl show und ip link show gecheckt. Die Interfaces waren UP und auch richtig eingestellt mit den Namen (p1p1, p1p2).
Weil ich dann PFSense und die zweite VM immer noch nicht erreichen konnte habe ich die PFSense VM neugestartet und schon ging das Internet wieder, aber die zweite VM konnte ich nicht erreichen.
Nach einem Neustart der zweiten VM ging diese dann auch wieder.Ich kann mir eigentlich nur vorstellen, dass es am Routing vom Homeserver liegt.
Nur komisch dass ich den Router 192.168.1.1 erreichen kann von der PFSense VM aus.
ich weiß es auch nicht ^^Hier mal noch ein paar Auszüge:
-
Auf Grund deiner betriebenen Fehlersuche, des Verhaltens der pfSense und der zweiten VM klingen verschiedene Dinge unlogisch. Laut meiner Erfahrung tippe ich auf Probleme mit dem Virtualisierungshost bzw. dessen Netzwerk oder der verwendeten Hardware. Kannst du das ganze mal mit Virtualisierung und anderer Hardware übergangsweise betreiben? Sollte schnell gemacht sein sofern irgendwo noch ein Stück Blech frei ist. Bitte nicht zu alte oder zu billige Komponenten zum testen nehmen.
Ohne das bewerten zu wollen: die DeLock PCIe Karte mit Realtek NIC würde ich versuchen zu ersetzen. Ich hatte das schon mehrmals bei anderen: eine einfache GBit Netzwerkkarte als Erweiterung 'mal eben' eingesteckt. Die laufen nicht lange sauber, werden tlw. sehr heiß (bis hin zur optischen Verfärbung auf dem Plaste), hängen sich auf bzw. blockieren einfach mal so - auch schon unter normalen Desktop Betriebssystem die nicht 24/7 laufen.
-
Ich würde die Hardware des Servers eigentlich ausschließen. Den habe ich vor ein paar Monaten erst selbst zusammengebaut.
Leider habe ich gerade keine halbwegs aktuelle Austauschhardware rumstehen. (Nur noch einen mit DDR2 und da hab ich bedenken wegen dem RAM xD)Ich behalte die Sache mit dem Netzwerk und der NIC mal im Auge.
Welche NIC würdest du denn empfehlen?Danke für die Hilfe
-
Wegen der NICs: ich bevorzuge onboard Geräte, bevorzugt Intel. Das wird dir aber nicht weiterhelfen. Wenn du schon schreibst dass du die Hardware vor nicht allzu langer Zeit zusammengebaut hast: was spricht gegen dessen onboard NIC als LAN Anschluss - auch wenn es nur eine ist?
Für WAN bzw. für die Firewall überhaupt sollten es zwei einzelne 100MBit Karten auch tun. Stabilität vor Geschwindigkeit. Zum Testen reicht das allemal.
Was für Pakete / Dienste laufen denn auf der Firewall? Schon mal eine Neuinstallation mit einem Backup versucht?
Für so eine Testgerät als Firewall oder einen Virtualisierer mit wenig Last (weil nur die pfSense zum testen darauf läuft) braucht es nicht unbedingt aktuelle Hardware. Die sollte heilwegs stabil, nicht zu exotisch sein, keine Gimmicks haben und den RAM kann man ja ausgiebig testen (memtet, prime95).
Habe noch kein Gerät gesehen welches produktiv läuft und einfach mal so aufgibt außer es wird zu heiß, hat Stromversorgungs- / Erdungspotentialprobleme, einen Disk Schaden (leicht korrupte Dateisysteme reichen schon) oder hat einen sonstigen Hardwaretreffer weg. Auf nicht zu exotische Hardware und insbesonders wenn virtualisiert läuft die pfSense lange stabil.
-
Vielen vielen Dank für deine Hilfe.
Ich habe jetzt wieder ein paar Sachen zu testen.
-
Meine PFSense ging grad wieder down
Habe aber jetzt zumindest herausgefunden woran es liegt.
Ein ifconfig em1 down und ifconfig em1 up brachte wieder die Verbindung nach draußen. (Eingegeben in der GUI, da SSH Verbindung ja nicht ging von dem LAN Netz)
Es scheint so zu sein dass mein LAN Interface der PFSense selbst aussteigt. (stand vor dem neustart aber auf active)
Aber warum? Und was kann ich dagegen tun?
PS: Ein Kollege von mir hat fast das gleiche Setup und bei Ihm ist heute der WAN Port abgeschmiert mit genau den selben Symptomen.
-
UPDATE: Gerade ist mein WAN Interface ausgestiegen
root@workstation:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.2.1 icmp_seq=62 Destination Host Unreachable
From 192.168.2.1 icmp_seq=63 Destination Host Unreachable
From 192.168.2.1 icmp_seq=64 Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_seq=65 ttl=63 time=0.838 ms
From 192.168.2.1 icmp_seq=66 Destination Host Unreachable
From 192.168.2.1 icmp_seq=67 Destination Host Unreachable
From 192.168.2.1 icmp_seq=68 Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_seq=69 ttl=63 time=1.65 ms
64 bytes from 192.168.1.1: icmp_seq=70 ttl=63 time=1.74 ms
64 bytes from 192.168.1.1: icmp_seq=71 ttl=63 time=1.00 ms
64 bytes from 192.168.1.1: icmp_seq=72 ttl=63 time=1.10 ms
64 bytes from 192.168.1.1: icmp_seq=73 ttl=63 time=1.01 ms
64 bytes from 192.168.1.1: icmp_seq=74 ttl=63 time=0.832 ms
64 bytes from 192.168.1.1: icmp_seq=75 ttl=63 time=0.844 ms
64 bytes from 192.168.1.1: icmp_seq=76 ttl=63 time=0.780 ms
64 bytes from 192.168.1.1: icmp_seq=77 ttl=63 time=1.04 ms
64 bytes from 192.168.1.1: icmp_seq=78 ttl=63 time=0.859 ms
64 bytes from 192.168.1.1: icmp_seq=79 ttl=63 time=0.938 ms
64 bytes from 192.168.1.1: icmp_seq=80 ttl=63 time=0.980 ms
64 bytes from 192.168.1.1: icmp_seq=81 ttl=63 time=2.02 ms
64 bytes from 192.168.1.1: icmp_seq=82 ttl=63 time=1.11 ms
64 bytes from 192.168.1.1: icmp_seq=83 ttl=63 time=0.933 ms
64 bytes from 192.168.1.1: icmp_seq=84 ttl=63 time=1.34 ms
64 bytes from 192.168.1.1: icmp_seq=85 ttl=63 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=86 ttl=63 time=1.29 ms
64 bytes from 192.168.1.1: icmp_seq=87 ttl=63 time=1.56 ms
64 bytes from 192.168.1.1: icmp_seq=88 ttl=63 time=0.859 ms
64 bytes from 192.168.1.1: icmp_seq=89 ttl=63 time=1.01 ms
^C
–- 192.168.1.1 ping statistics ---
89 packets transmitted, 22 received, +6 errors, 75% packet loss, time 88497ms
rtt min/avg/max/mdev = 0.780/1.128/2.029/0.331 msEin ifconfig em0 down und ifconfig em0 up brachte wieder die Verbindung.
-
Aber warum? Und was kann ich dagegen tun?
Gibt es dort im BIOS eventuell Stromsparfunktionen? Also bei keine verkehr das Interface abschalten?
PS: Ein Kollege von mir hat fast das gleiche Setup und bei Ihm ist heute der WAN Port abgeschmiert mit genau den selben Symptomen.
Wenn da nicht die genau gleiche Konfiguration drauf ist bringt uns das hier bei Deinem Problem aber
recht wenig weiter. Denn vieles ist eher auf die Konfiguration zurück zu führen und nicht auf Probleme
die pfSense selber hat. Ja nachdem wie viel RAM Du verbaut hast, könnte man einmal mit der Größe
der mbuf size experimentieren, halt kleiner oder größere Werte setzen und abwarten. -
Ich schlage vor, die Realtec Nic gegen eine Intel zu tauschen. Was hast Du denn für eine Nic on-board durch die der Traffic des Hostsystems geht? Benutz die vielleicht mal für die Lan Bridge.
Übrigens, falls die on-board Nic und die Bridge Lan Nic im gleichen Netz stecken, kannst Du Dir das mit dem separieren des Traffics des Hostsystems eh sparen. Linux sucht sich in der Regel bei Nics im selben Subnet aus, über welche Nic es IP-technisch geht. Unabhängig davon, welcher Nic Du eine IP zugewiesen hast.
Edit: Link zum Thema: http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html
-
FYI: Mir ist gerade aufgefallen, dass in den Gateway Logs apinger immer den Ausfall des WAN Interfaces meldet.
Mar 8 20:18:51 apinger: alarm canceled: WANGW(192.168.1.1) *** delay ***
Mar 8 20:18:48 apinger: ALARM: WANGW(192.168.1.1) *** delay ***
Mar 8 20:18:41 apinger: Could not bind socket on address(192.168.1.2) for monitoring address 192.168.1.1(WANGW) with error Can't assign requested address
Mar 8 20:18:40 apinger: Could not bind socket on address(192.168.1.2) for monitoring address 192.168.1.1(WANGW) with error Can't assign requested address
Mar 8 20:18:39 apinger: Could not bind socket on address(192.168.1.2) for monitoring address 192.168.1.1(WANGW) with error Can't assign requested address
Mar 8 20:18:39 apinger: alarm canceled: WANGW(192.168.1.1) *** down ***
Mar 8 20:17:43 apinger: ALARM: WANGW(192.168.1.1) *** down *** -
Anbei mal den Trace auf dem WAN Port von pfsense
Kann das 6. Paket ein Problem sein für pfsense?
Weil da ist der wan port down gegangen