7
OpenVPN Verbindung ausgehend vom Server zu manchen Clients nach einer gewissen Zeit nicht mehr nutzbar
Guten Morgen,
einige meiner Kunden habe ich mit einer VPN-Verbindung via OpenVPN bei uns an den Server in der Firma angeschlossen. Meistens benutze ich hierfür die UDP-Verbindung (sofern kundenseitig möglich).
Nun ist es so, dass bei manchen Kunden (scheinbar nur die UDP-Varianten) die Verbindung vom Server zum Kunden nach einer gewissen Ruhezeit (also ohne eine aktive Verbindung zwischen Server und Client) nicht mehr richtig besteht bzw. irgendwie verloren geht. Angeblich ist sie noch da - aber ich kann keinerlei Verbindung ausgehend vom Server mehr etablieren.
Beispiel.
Auf dem Client habe ich folgenden Zustand:
Also das Interface ist vorhanden und die IP ist gesetzt. Der Client hat die IP 172.31.16.16 und der Server die 172.31.16.1.
Auf dem Server sieht das so aus:
Interface ist vorhanden. Andere Kunden sind darüber auch erreichbar. Nun schaue ich mir den aktuellen Verbindungszustand an:
KundeXY ist in diesem Fall die 'defekte' Verbindung.
Setze ich nun vom Server einen Ping auf die 172.31.16.16 ab, erhalte ich keine Antwort:
Erst wenn ich die Verbindung von der Gegenstelle aus quasi 'auffrische' (man sieht hier auch ganz gut, dass die ersten Pakete noch unbeantwortet bleiben):
Kann ich vom Server aus auch wieder die Gegenstelle erreichen:
Warte ich jetzt ein paar Minuten, ist die Verbindung wieder nicht mehr nutzbar. Es seit denn ich habe eine aktive Verbindung zum Client bestehen (z.B. einen offnen SSH-Kanal). Dann bleibt die Verbindung stabil.
Das stört ganz schön, denn was bringt mir die VPN-Verbindung, wenn ich doch immer wieder per Teamviewer zum Client verbinden muss, um diese erst wieder zu 'reaktivieren'.
Clientseitig hatte ich, um dies zu vermeiden, extra die Option „keepalive 10 120“ in die Konfiguration aufgenommen. Das scheint aber nicht das gewünschte Ergebnis zu bringen.
Um diese Situation zu entschärfen, habe ich bei diesen Kunden schon einen Cronjob angelegt, der jede Minute einen Ping auf den Server absetzt. Aber das kanns doch irgendwie nicht sein...?
Hat hier jemand eine Idee an welcher Schraube ich da drehen muss?
Vielen Dank und beste Grüße
Martin
einige meiner Kunden habe ich mit einer VPN-Verbindung via OpenVPN bei uns an den Server in der Firma angeschlossen. Meistens benutze ich hierfür die UDP-Verbindung (sofern kundenseitig möglich).
Nun ist es so, dass bei manchen Kunden (scheinbar nur die UDP-Varianten) die Verbindung vom Server zum Kunden nach einer gewissen Ruhezeit (also ohne eine aktive Verbindung zwischen Server und Client) nicht mehr richtig besteht bzw. irgendwie verloren geht. Angeblich ist sie noch da - aber ich kann keinerlei Verbindung ausgehend vom Server mehr etablieren.
Beispiel.
Auf dem Client habe ich folgenden Zustand:
# ifconfig
[...]
tap0 Link encap:Ethernet HWaddr 56:69:a4:f0:48:47
inet addr:172.31.16.16 Bcast:172.31.31.255 Mask:255.255.240.0
inet6 addr: fe80::5469:a4ff:fef0:4847/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:246368 errors:0 dropped:0 overruns:0 frame:0
TX packets:185050 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:27034167 (25.7 MiB) TX bytes:83652314 (79.7 MiB)
Auf dem Server sieht das so aus:
# ifconfig
[...]
vpnudp Protokoll:Ethernet Hardware Adresse de:91:a9:73:46:a6
inet Adresse:172.31.16.1 Bcast:172.31.255.255 Maske:255.255.0.0
inet6 Adresse: fe80::dc91:a9ff:fe73:46a6/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2031448 errors:0 dropped:0 overruns:0 frame:0
TX packets:2197593 errors:0 dropped:1117 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX bytes:480032322 (457.7 MiB) TX bytes:698991016 (666.6 MiB)
# cat /etc/openvpn/server-udp-status.log
OpenVPN CLIENT LIST
Updated,Wed Sep 10 09:33:46 2014
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
[...]
KundeXY,<öffentliche IP>:52642,80977892,44402202,Sat Aug 16 12:12:10 2014
[...]
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
[...]
56:69:a4:f0:48:47,KundeXY,<öffentliche IP>:52642,Mon Sep 8 18:18:19 2014
[...]
GLOBAL STATS
Max bcast/mcast queue length,13
END
KundeXY ist in diesem Fall die 'defekte' Verbindung.
Setze ich nun vom Server einen Ping auf die 172.31.16.16 ab, erhalte ich keine Antwort:
# ping 172.31.16.16
PING 172.31.16.16 (172.31.16.16) 56(84) bytes of data.
From 172.31.16.1: icmp_seq=2 Destination Host Unreachable
From 172.31.16.1: icmp_seq=3 Destination Host Unreachable
From 172.31.16.1: icmp_seq=4 Destination Host Unreachable
^C
--- 172.31.16.16 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4001ms
Erst wenn ich die Verbindung von der Gegenstelle aus quasi 'auffrische' (man sieht hier auch ganz gut, dass die ersten Pakete noch unbeantwortet bleiben):
# ping 172.31.16.1
PING 172.31.16.1 (172.31.16.1) 56(84) bytes of data.
64 bytes from 172.31.16.1: icmp_req=5 ttl=64 time=1050 ms
64 bytes from 172.31.16.1: icmp_req=6 ttl=64 time=54.7 ms
64 bytes from 172.31.16.1: icmp_req=7 ttl=64 time=43.7 ms
64 bytes from 172.31.16.1: icmp_req=8 ttl=64 time=52.0 ms
^C
--- 172.31.16.1 ping statistics ---
8 packets transmitted, 4 received, 50% packet loss, time 7003ms
# ping 172.31.16.16
PING 172.31.16.16 (172.31.16.16) 56(84) bytes of data.
64 bytes from 172.31.16.16: icmp_req=1 ttl=64 time=57.6 ms
64 bytes from 172.31.16.16: icmp_req=2 ttl=64 time=55.8 ms
^C
--- 172.31.16.16 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
Warte ich jetzt ein paar Minuten, ist die Verbindung wieder nicht mehr nutzbar. Es seit denn ich habe eine aktive Verbindung zum Client bestehen (z.B. einen offnen SSH-Kanal). Dann bleibt die Verbindung stabil.
Das stört ganz schön, denn was bringt mir die VPN-Verbindung, wenn ich doch immer wieder per Teamviewer zum Client verbinden muss, um diese erst wieder zu 'reaktivieren'.
Clientseitig hatte ich, um dies zu vermeiden, extra die Option „keepalive 10 120“ in die Konfiguration aufgenommen. Das scheint aber nicht das gewünschte Ergebnis zu bringen.
Um diese Situation zu entschärfen, habe ich bei diesen Kunden schon einen Cronjob angelegt, der jede Minute einen Ping auf den Server absetzt. Aber das kanns doch irgendwie nicht sein...?
Hat hier jemand eine Idee an welcher Schraube ich da drehen muss?
Vielen Dank und beste Grüße
Martin
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 248773
Url: https://administrator.de/contentid/248773
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
7 Kommentare
Neuester Kommentar
Hi
Mit freundlichen Grüßen
Cthluhu
Zitat von @mfernau:
Clientseitig hatte ich, um dies zu vermeiden, extra die Option „keepalive 10 120“ in die Konfiguration aufgenommen.
Und serverseitig? Da gibts auch eine keepalive Option.Clientseitig hatte ich, um dies zu vermeiden, extra die Option „keepalive 10 120“ in die Konfiguration aufgenommen.
Hat hier jemand eine Idee an welcher Schraube ich da drehen muss?
Was sagt eigentlich das log des Verbindsaufbaus? Gibts da irgendwelche Warnungen, z.B. bzgl unterschiedlicher Konfiguration von Server und Client?Mit freundlichen Grüßen
Cthluhu
Serverseitig habe ich diese Option ebenfalls gesetzt:
keepalive 10 120
In den Logs sind keine Auffälligkeiten zu sehen. Aktuell ist die Verbindung z.B. mal wieder im Eimer. Serverseitig sind keine Informationen zu dieser Gegenstelle seit dem letzten Verbindungsaufbau im Log zu sehen:
Clientseitig kann ich gerade keine Logs zur Verfügung stellen, da der Log-Daemon seinen Dienst verweigert. Das muss ich erstmal korrigieren.
keepalive 10 120
In den Logs sind keine Auffälligkeiten zu sehen. Aktuell ist die Verbindung z.B. mal wieder im Eimer. Serverseitig sind keine Informationen zu dieser Gegenstelle seit dem letzten Verbindungsaufbau im Log zu sehen:
Sep 10 13:50:17 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 CRL CHECK OK: <Zertifikatsinfos der CA>
Sep 10 13:50:17 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 VERIFY OK: : <Zertifikatsinfos der CA>
Sep 10 13:50:17 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 CRL CHECK OK: : <Zertifikatsinfos vom Kunden>
Sep 10 13:50:17 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 VERIFY OK: : <Zertifikatsinfos vom Kunden>
Sep 10 13:50:18 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sep 10 13:50:18 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sep 10 13:50:18 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sep 10 13:50:18 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sep 10 13:50:18 jupiter openvpn[2349]: kundeXY/<externe IP>:52642 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Clientseitig kann ich gerade keine Logs zur Verfügung stellen, da der Log-Daemon seinen Dienst verweigert. Das muss ich erstmal korrigieren.
Hi mfernau,
ich kann Dir von meiner pfSense, auf der 2 OpenVPN-Server laufen, die mit 2 DD-WRT Routern als OpenVPN-Clients verbunden sind, wohl gleiches bestätigen.
Die Tunnel bleiben bestehen und die Client-Router sind weiter problemlos vom Server-LAN über die VPN-IP erreichbar.
Sporadisch fällt aber die Verbindung zum remoten Netz aus, so das ich darüber weder die Router, noch die Rechner über die remote LAN-IP erreichen kann.
Das ganze tritt manchmal über Wochen nicht auf, so das ich bis jetzt auch noch nicht wirklich dahinter gestiegen bin.
Ich mache dann bei Bedarf einen Reboot auf der pfSense und schon ist mit dem Routing auf beiden Tunneln wieder alles Tacco.
Da das nur privates Netzwerk ist, ich auch nur Rechnerwartung im remoten Netz mache, so das der Zugriff nicht ständig erfolgen muss, habe ich das bisher auch nicht so eng gesehen.
Wäre trotzdem interessant, hier mal dahinter zu kommen.
Gruß orcape
ich kann Dir von meiner pfSense, auf der 2 OpenVPN-Server laufen, die mit 2 DD-WRT Routern als OpenVPN-Clients verbunden sind, wohl gleiches bestätigen.
Die Tunnel bleiben bestehen und die Client-Router sind weiter problemlos vom Server-LAN über die VPN-IP erreichbar.
Sporadisch fällt aber die Verbindung zum remoten Netz aus, so das ich darüber weder die Router, noch die Rechner über die remote LAN-IP erreichen kann.
Das ganze tritt manchmal über Wochen nicht auf, so das ich bis jetzt auch noch nicht wirklich dahinter gestiegen bin.
Ich mache dann bei Bedarf einen Reboot auf der pfSense und schon ist mit dem Routing auf beiden Tunneln wieder alles Tacco.
Da das nur privates Netzwerk ist, ich auch nur Rechnerwartung im remoten Netz mache, so das der Zugriff nicht ständig erfolgen muss, habe ich das bisher auch nicht so eng gesehen.
Wäre trotzdem interessant, hier mal dahinter zu kommen.
Gruß orcape
Moin,
inhaltlich habe ich noch nichts zur Lösung beizutragen, aber offensichtlich tritt das Problem bei einem meiner Kunden bei einer frischen pfSense-Installation zu einem Windows7-Client auf, ich werde heute abend wohl Logging etc. hochdrehen könnnen und auch den Fall näher untersuchen.
Wird die Default-Route bei Euren Installationen zum VPN-Tunnel umgebogen?
HG
Mark
inhaltlich habe ich noch nichts zur Lösung beizutragen, aber offensichtlich tritt das Problem bei einem meiner Kunden bei einer frischen pfSense-Installation zu einem Windows7-Client auf, ich werde heute abend wohl Logging etc. hochdrehen könnnen und auch den Fall näher untersuchen.
Wird die Default-Route bei Euren Installationen zum VPN-Tunnel umgebogen?
HG
Mark
Hi broecker,
Ich habe zwar die Tunnel auf der pfSense auch untereinander geroutet um bei Bedarf von einem remoten Laptop (3.Tunnel) auf die beiden anderen Netzwerke (Tunnel) zu kommen, das Problem tritt aber auch ohne dieses Routing auf.
Gruß orcape
Wird die Default-Route bei Euren Installationen zum VPN-Tunnel umgebogen?
nein. Die pfSense ist als Standartgateway gleichzeitig auch OpenVPN-Server. Keine weiteren Router im Spiel. Netzverbindung O²/dyndns.Ich habe zwar die Tunnel auf der pfSense auch untereinander geroutet um bei Bedarf von einem remoten Laptop (3.Tunnel) auf die beiden anderen Netzwerke (Tunnel) zu kommen, das Problem tritt aber auch ohne dieses Routing auf.
Clientseitig hatte ich, um dies zu vermeiden, extra die Option „keepalive 10 120“ in die Konfiguration aufgenommen.
...habe ich auch Serverseitig drin, ändert nichts.Gruß orcape
Hallo, zusammen,
Oder iist das auf der anderen Seite eventuell auch schon so vergeben worden?
Gruß
Dobby
Der Client hat die IP 172.31.16.16 und der Server die 172.31.16.1.
Hat Euer Server dem VPN Klienten dann eine IP Adresse vergeben?Oder iist das auf der anderen Seite eventuell auch schon so vergeben worden?
Gruß
Dobby
Hat Euer Server dem VPN Klienten dann eine IP Adresse vergeben?
Genau so ist es. Im Server gibt es bei mir die Option
client-config-dir ccd-udpifconfig-push 172.31.16.16 255.255.240.0
