Verbindungsabbrüche pfSense über Dell-VPN PC
-
@dogfight76
Vermutlich bricht die Internetverbindung weg. Was findet sich bezüglich WAN Gateway im Gateway Log?
Und was im System Log zu diesem Zeitpunkt? -
@viragomann
System Gateway log zeigt dies hier an für alle VPN-Verbindugnen:Oct 19 22:04:36 dpinger 61539 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% alarm_hold 10000ms dest_addr 2606:4700:4700::1111 bind_addr 2a02:xxxxxxxxxxxxxxxxxxxxxxxxxxfbd identifier "WAN_DHCP6 "Kannst da was mit anfangen ?
Kann man in der FRITZ!Box kucken ob sie die Verbindung verliert zu der Uhrzeit ?
-
@dogfight76
Das ist der Eintrag fürs IPv6 Gateway, aber vermutlich gibt es so ziemlich denselben auch fürs IPv4, nachdem es im Monitoring Widget mit derselben Loss-Rate angezeigt wird. Das dürfte hier relevanter sein, nachdem deine VPNs über v4 gehen.Gibt es was im System Log dazu?
Die FritzBox sollte auch Zustandsänderungen ihrer Verbindung loggen. Die kenne ich aber nicht und kann damit nichts dazu sagen.
-
System-Log sollte das hier sein, 23:08 Uhr ist gerade wieder keine Verbindung;
In meiner Gateway-Group habe ich 5 unterschiedliche Interface nach Tier 1 -5 gelistet !
Als Backup-Gedanke falls mal ein Interface down ist. (Keine Ahnung ob es an der Gateway-Group liegen kann)Erkennst du was ?
Oct 19 23:08:00 php-fpm 10562 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP' Oct 19 23:08:00 php-fpm 10562 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6' Oct 19 23:08:00 php-fpm 10562 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed IP addresses. Reloading endpoints that may use WAN_DHCP. Oct 19 21:59:33 root 12556 Bootup complete Oct 19 21:58:32 rtsold 12841 <rtsock_input_ifannounce> interface tun1 removed Oct 19 22:49:00 sshguard 22527 Now monitoring attacks. Oct 19 23:06:00 sshguard 22527 Exiting on signal. Oct 19 22:37:04 rc.gateway_alarm 2524 >>> Gateway alarm: VPN_NL853_VPNV4 (Addr:1.0.0.1 Alarm:0 RTT:32.265ms RTTsd:26.584ms Loss:5%) Oct 19 22:55:39 rc.gateway_alarm 27024 >>> Gateway alarm: WAN_DHCP (Addr:8.8.4.4 Alarm:1 RTT:19.243ms RTTsd:2.661ms Loss:21%) Oct 19 21:58:32 rtsold 27316 Received RA specifying route xxxxx::1212:ff:xxxxx:yyyyy for interface wan(em0) Oct 19 21:58:32 rtsold 27634 RTSOLD Lock in place - sending SIGHUP to dhcp6c Oct 19 22:55:39 rc.gateway_alarm 28675 >>> Gateway alarm: VPN_DE827_VPNV4 (Addr:84.200.69.80 Alarm:1 RTT:29.652ms RTTsd:3.744ms Loss:21%) Oct 19 22:55:40 rc.gateway_alarm 30151 >>> Gateway alarm: WAN_DHCP6 (Addr:xxxx:yyyyy:xxxx::1111 Alarm:1 RTT:24.272ms RTTsd:2.549ms Loss:22%) Oct 19 22:55:40 rc.gateway_alarm 32429 >>> Gateway alarm: VPN_NL853_VPNV4 (Addr:1.0.0.1 Alarm:1 RTT:28.101ms RTTsd:3.770ms Loss:22%) Oct 19 22:55:40 rc.gateway_alarm 32983 >>> Gateway alarm: VPN_DE978_VPNV4 (Addr:8.8.8.8 Alarm:1 RTT:29.425ms RTTsd:3.946ms Loss:22%) Oct 19 23:02:15 rc.gateway_alarm 34367 >>> Gateway alarm: VPN_DE950_VPNV4 (Addr:9.9.9.9 Alarm:1 RTT:30.761ms RTTsd:4.210ms Loss:22%) Oct 19 22:55:40 rc.gateway_alarm 35939 >>> Gateway alarm: VPN_DE950_VPNV4 (Addr:9.9.9.9 Alarm:1 RTT:30.148ms RTTsd:4.134ms Loss:22%) Oct 19 21:58:30 php-fpm 369 /rc.linkup: Ignoring link event during boot sequence ```) -
@dogfight76
Nein, da ist nichts zu finden.
Interessant finde ich aber die zeitliche Reihenfolge. Offenbar hast du die Liste nach der Quelle sortiert. Da könnten wichtige Information abgetaucht sein und in der Liste nun fehlen. -
Ne, einfach rauskopiert !
Kann es denn an der Gateway-Group liegen ?
Soll ich mal die jetzige Tier1-3 alle auf Tier1 setzen (Lastenausgleich) und die restlichen 2 interfaces auf Tier2Gruß
-
@dogfight76
Normalerweise werden die Ereignisse in zeitlicher Reihenfolge aufgelistet. Deine Liste scheint nach PID sortiert zu sein. Das passiert, wenn du auf die Spaltenüberschrift klickst. Das kann unbeabsichtigt passiert sein.
Wichtige Infos in diesem zeitlichen Zusammenhang können damit ans Ende der Liste verschwunden sein. -
@viragomann
23:47 Uhr ein Abbruch:Oct 19 23:19:52 php-fpm 369 /rc.start_packages: Restarting/Starting all packages. Oct 19 23:47:14 rc.gateway_alarm 25313 >>> Gateway alarm: VPN_DE828_VPNV4 (Addr:1.1.1.1 Alarm:1 RTT:28.480ms RTTsd:4.232ms Loss:21%) Oct 19 23:47:14 check_reload_status 407 updating dyndns VPN_DE828_VPNV4 Oct 19 23:47:14 check_reload_status 407 Restarting IPsec tunnels Oct 19 23:47:14 check_reload_status 407 Restarting OpenVPN tunnels/interfaces Oct 19 23:47:14 check_reload_status 407 Reloading filter Oct 19 23:47:14 rc.gateway_alarm 26709 >>> Gateway alarm: VPN_DE950_VPNV4 (Addr:9.9.9.9 Alarm:1 RTT:29.006ms RTTsd:4.238ms Loss:21%) Oct 19 23:47:14 check_reload_status 407 updating dyndns VPN_DE950_VPNV4 Oct 19 23:47:14 check_reload_status 407 Restarting IPsec tunnels Oct 19 23:47:14 check_reload_status 407 Restarting OpenVPN tunnels/interfaces Oct 19 23:47:14 check_reload_status 407 Reloading filter Oct 19 23:47:14 rc.gateway_alarm 29026 >>> Gateway alarm: VPN_DE978_VPNV4 (Addr:8.8.8.8 Alarm:1 RTT:28.724ms RTTsd:4.078ms Loss:22%) Oct 19 23:47:14 rc.gateway_alarm 30879 >>> Gateway alarm: WAN_DHCP (Addr:8.8.4.4 Alarm:1 RTT:17.842ms RTTsd:2.442ms Loss:22%) Oct 19 23:47:14 rc.gateway_alarm 32793 >>> Gateway alarm: VPN_NL853_VPNV4 (Addr:1.0.0.1 Alarm:1 RTT:27.659ms RTTsd:3.968ms Loss:22%) Oct 19 23:47:14 rc.gateway_alarm 35913 >>> Gateway alarm: VPN_DE827_VPNV4 (Addr:84.200.69.80 Alarm:1 RTT:28.915ms RTTsd:4.199ms Loss:22%) Oct 19 23:47:14 rc.gateway_alarm 36079 >>> Gateway alarm: WAN_DHCP6 (Addr:xxxx:yyyy:xxxx::1111 Alarm:1 RTT:23.028ms RTTsd:2.981ms Loss:22%) Oct 19 23:47:15 php-fpm 369 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP' Oct 19 23:47:15 php-fpm 369 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6' Oct 19 23:47:15 php-fpm 10562 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP' Oct 19 23:47:15 php-fpm 369 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed IP addresses. Reloading endpoints that may use VPN_DE828_VPNV4. -
@dogfight76
Nein, da findet sich kein Hinweis auf ein Hardware-Problem.Und nachdem das WAN Gateway auch immer zu selben Zeit wegbricht, denke ich nicht, dass es etwas mit den VPNs zu tun hat bzw. mit der Gateway Gruppe.
-
-
@dogfight76
Ich würde einen Fehler auf der pfSense nicht gänzlich ausschließen, aber es sieht nicht danach aus.
Ich würde also Richtung Internet weiter suchen.Das Problem kann aber auch das Netzwerkkabel zum Modem sein oder auch das Modem oder auch außerhalb deines Bereichs.
Auf der pfSense selbst könntest du mal die WAN Gateway Monitoring IP ändern. Könnte sein, dass es genau mit der aktuellen ein Problem gibt. Wenn die pfSense das Gateway als offline einstuft aufgrund fehlender Responses, geht natürlich auch alles andere offline.
Das oder die Kabel auszutauschen wäre wohl das einfachste.
Wenn du auf die FritzBox Zugriff hast, natürlich dann mal deren Logs checken.
Das Problem kann aber auch beim Provider liegen.
-
@viragomann said in Verbindungsabbrüche pfSense über Dell-VPN PC:
Auf der pfSense selbst könntest du mal die WAN Gateway Monitoring IP ändern. Könnte sein, dass es genau mit der aktuellen ein Problem gibt. Wenn die pfSense das Gateway als offline einstuft aufgrund fehlender Responses, geht natürlich auch alles andere offline.
Welche Monitor-IP ist zu empfehlen ?
Und wo ändere ich die Monitor IP vom WAN-GW?
Gruß -
@dogfight76
Jede IP im WAN, die verlässlich antwortet, bspw. 81.91.170.12 (nic.de). Aber achte darauf, dass du keine für mehrere Gateways verwendest.Zu setzen ist das in den Gateway Settings in System > Routing. Alle deine Gateways haben eine individuelle Monitoring-IP, also hattest du das wohl schon mal gesetzt.
-
@viragomann
Also die Monitor IP vom WAN habe ich mal geändert !
Aber ich denke tatsächlich das es ein FRITZ!Box Problem ist.
Denn auch Geräte die nicht über VPN laufen haben dann keine Verbindung !
Protokoll der FRITZ!Box sagt:Es besteht keine Verbindung mehr zu den verschlüsselten DNS-Servern.Kurze Zeit später kommt dann das:
Es wurde erfolgreich eine Verbindung - samt vollständiger Validierung - zu den verschlüsselten DNS-Servern aufgebaut.DNS over TLS (DoT) habe ich mal in der Fritte deaktiviert. DNS ist dort eh schon die von cloudflare drin (1.1.1.1 und alternativ die 1.0.0.1)
Könnte es daran liegen ?
Gruß
-
Lasse die Fritzbox doch mit den Provider DNS Servern arbeiten.
pfSense nutz per default Unbound im Resolver Modus und löst über die jeweiligen root DNS alles selber auf.
DNS Ausfälle führen zwar für die Clients zu Problemen, sollten aber keinen Einfluss auf den ICMP Echo Monitor der pfSense haben. Hier lag wohl dann generell eine Störung beim Provider vor, wenn du so viele Gateways hast und alle nutzen andere IPs fürs Monitoring, aber alle sind gleichzeitig gestört.
