WAN nicht erreichbar

Owly

Hallo, meine Netgate ist vom WAN einige Zeit nach einem Neustart nicht mehr erreichbar. Ich kann sie dann weder via OpenVPN sowie übers Web nicht erreichen. Hat jemand eine Ahnung woran das liegen kann? In den Logs kann ich nicht wirklich etwas finden und da ich nicht weiß wann genau das passiert, ist es schwierig. Vom LAN kann ich ganz normal zugreifen, auch INET funktioniert ganz normal. Lediglich der Zugriff von außen ist dann weg.
LGO

viragomann

@Owly
Wenn sonst alles funktioniert, würde mein Verdacht auf deinen Internet-Zugang fallen. Was da das Problem sein kann, hängt davon ab, wie der zustande kommt.

Auf der pfSense kannst du am WAN Gateway das Monitoring einer externen IP aktivieren. Standardmäßig wird das Gateway selbst gemonitort. Wenn das aber der lokale ISP Router ist, bringt das nicht viel.
System > Routing > Gateways
Da kannst du das WAN Gateway editieren und ein andere IP für das Monitoring setzen, bspw. 81.91.170.12 (nic.de).

Wenn die Verbindung nach draußen ausfallen sollte, findet sich dann jedenfalls im Gateway-Log ein Eintrag. Damit hast du dann den Zeitpunkt des Ausfalls für den Fall, dass du im System-Log nach Ursachen suchen möchtest (falls es doch an pfSense selbst liegen sollte).

Owly

@viragomann Am Internet liegt es nicht. Das ist völlig stabil. Komme ja auch zu jeder Zeit raus und ein Dauerping ergibt keinerlei ausfälle oder verzögerungen. - wie gesagt, wenn ich die Netgate neu starte ist dann alles wieder normal. dann komme ich wieder drauf.

Owly

Ergänze, nach einiger Zeit erscheint

504 Gateway Time-out
nginx

JeGr

@Owly 504 ist meistens dann wenn sich PHP verabschiedet hat. Konsole PHP FPM neustarten wirds wahrscheinlich richten in dem Moment. Bleibt die Frage warum, da ist dann definitiv was falsch oder fehl-konfiguriert, denn wenn nach ein paar Stunden einfach mal system Prozesse abfaulen liegt das an irgendwas. Das kann man aber nicht erspüren oder hellsehen ;)

Owly

habe jetzt alle logs aktiviert… kann mir jemand sagen was das bedeutet?
es versucht sich definitiv niemand zu verbinden… woher kommt das im minutentakt


Mar 07 15:47:09 ASI openvpn MANAGEMENT: Client connected from /var/etc/openvpn/server1/sock
Mar 07 15:47:09 ASI openvpn MANAGEMENT: CMD 'status 2'
Mar 07 15:47:09 ASI openvpn MANAGEMENT: CMD 'quit'
Mar 07 15:47:09 ASI openvpn MANAGEMENT: Client disconnected

auf meiner anderen kommt das nicht obwohl gleich konfiguriert

viragomann

@Owly
Das ist der Health Check eines OpenVPN Servers. Das wird im Default Verbosity Level nicht geloggt.

JeGr

@Owly Was hat denn OpenVPN jetzt mit dem Nginx und dem Web Kram zu tun? :)

Owly

@JeGr Insofern geht dann nicht nur VPN sondern gar nichts mehr von aussen.
Habe SSH, Web und VPN versucht. Nach draussen geht alles… Logge zum Beispiel auf meinen Server damit ich alles mitbekomme sowie im LAN und ins WAN funktioniert auch alles
Es hat jetzt wieder Tagelang funktioniert un zack seit gestern komme ich wieder nicht drauf. stellt sich tot. in den logs finde ich nur das übliche

micneu

@Owly auf was für einer hardware läuft deine Sense?
Bitte mehr informationen:

Welcher Provider?
Einwahl über PPPoE?
Internet über xDSL, Glas, oder Kabel?
Feste IP oder dyndns?

Gerne auch einen Grafischen Netzwerkplan

Owly

@micneu

hardware netgate 1100+
Provider A1 Business (habe bei denen aber bereits 3Stk im Einsatz und die passen alle mit fast der selben Konfig)
Feste Ip durchgeroutet

JeGr

@Owly Wenn es zur gleichen Zeit von intern geht, kann man da leider relativ wenig sagen. Wenn es von extern nicht mehr geht wäre es am Einfachsten, wenn man dann von intern mal den Packet Capture anwirft und sich anschaut, ob von extern wirklich überhaupt was ankommt. Also bspw. nen Handy mit OVPN Client via LTE versucht connecten zu lassen. Oft stellt sich dann nämlich raus - nanu! da kommt gar nichts an. Dann wäre das Problem beim Provider/Modem davor zu suchen, nicht bei der Firewall, darum sollte man erstmal eingrenzen wo es herkommt. Wenn nach langem Warten via HTTPS der 504 kommt wie oben - nunja der kommt wie gesagt von einem Timeout von PHP - dann sind wohl alle Worker ausgelastet und können keine Antwort geben. Das sollte aber bspw. dann den OVPN nicht tangieren, der hat da kaum Abhängigkeiten zu und wenn der sich trotzdem nicht connecten will, dann scheints andere Probleme zu geben. Wenn das Problem Richtung PHP liegt, könnte die Kiste auch einfach überlastet/ausgelastet sein, das kann dann auch an Fehlkonfiguration oder einem schieflaufenden Paket liegen. Kann man leider alles nicht so einfach hellseherisch debuggen :)

Cheers
\jens