Verbindungsabbrüche pfSense über Dell-VPN PC

dogfight76

@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 ?

viragomann

@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.

dogfight76

@viragomann

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
```)

viragomann

@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.

dogfight76

@viragomann

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 Tier2

Gruß

viragomann

@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.

dogfight76

@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.

viragomann

@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

@viragomann

Also würdest du den Grund dafür woanders suchen ?
Hättest eine Idee ?

Gruß

viragomann

@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.

dogfight76

@viragomann said in Verbindungsabbrüche pfSense über Dell-VPN PC:

@dogfight76

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ß

viragomann

@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.

dogfight76

@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ß

NOCling

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.