Probleme OpenVPN - sporadische Verbindungsabbrüche

CharlieScene

Lt. Junior Grade
Registriert
Juli 2016
Beiträge
382
Moin zusammen!
Ich zerbreche mir jetzt seit ein paar Tagen schon den Kopf wegen eines Kollegen, bei dem sein VPN "plötzlich" nicht mehr funktioniert.
Änderungen gab es keine (zumindest nicht bewusst), was das ganze noch merkwürdiger macht und ich langsam der Meinung bin dass sein Provider zuhause etwas geändert hat sodass der Reconnect beim Ablauf der Session nicht funktioniert. Für andere Funktioniert der VPN nach wie vor einwandfrei.
Genutzt wird OpenVPN auf einer pfSense (2.4.4-RELEASE-p3). Authentifizierung läuft über RADIUS.
Die Logs des Clients melden "recursive routing detected", die pfSense "tls key negotiation failed to occur within 60 seconds tls handshake failed".

dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-256-GCM:AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote owa.xxxxxxx.de 1194 udp
auth-user-pass
ca xxxFirewall-UDP4-1194-ca.crt
tls-auth xxxFirewall-UDP4-1194-tls.key 1
remote-cert-tls server

dev ovpns1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 66.666.66.666
engine rdrand
tls-server
server1.conf: unmodified: line 1
dev ovpns1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 66.666.66.666
engine rdrand
tls-server
server 192.168.10.0 255.255.255.224
client-config-dir /var/etc/openvpn-csc/server1
verify-client-cert none
username-as-common-name
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user SGFlbmRzY2hrZS1OUFM= fals
e server1 1194
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'owa.xxxxxxx.de' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 20
push "dhcp-option DOMAIN xxxxxxx.local"
push "dhcp-option DNS 192.168.1.204"
push "dhcp-option DNS 8.8.8.8"
push "block-outside-dns"
dev ovpns1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 66.666.66.666
engine rdrand
tls-server
server 192.168.10.0 255.255.255.224
client-config-dir /var/etc/openvpn-csc/server1
verify-client-cert none
username-as-common-name
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user SGFlbmRzY2hrZS1OUFM= false server1 1194
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'owa.xxxxxxx.de' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 20
push "dhcp-option DOMAIN xxxxxxx.local"
push "dhcp-option DNS 192.168.1.204"
push "dhcp-option DNS 8.8.8.8"
push "block-outside-dns"
push "register-dns"
push "dhcp-option NTP 192.168.1.204"
push "redirect-gateway def1"
client-to-client
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1.tls-auth 0
ncp-ciphers AES-256-GCM:AES-128-GCM
persist-remote-ip
float
topology subnet

pfSense Log:
Feb 12 08:58:02 openvpn 9240 MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Feb 12 08:57:50 openvpn 9240 12.3.456.789:5626 SIGTERM[soft,delayed-exit] received, client-instance exiting
Feb 12 08:57:44 openvpn 9240 12.3.456.789:5626 SENT CONTROL [Benutzer]: 'AUTH_FAILED' (status=1)
Feb 12 08:57:44 openvpn 9240 12.3.456.789:5626 Delayed exit in 5 seconds
Feb 12 08:57:44 openvpn 9240 12.3.456.789:5626 PUSH: Received control message: 'PUSH_REQUEST'
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 [Benutzer] Peer Connection Initiated with [AF_INET]12.3.456.789:5626
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384
Feb 12 08:57:43 openvpn user 'Benutzer' could not authenticate.
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 TLS: Username/Password authentication deferred for username 'Benutzer' [CN SET]
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 PLUGIN_CALL: POST /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so/PLUGIN_AUTH_USER_PASS_VERIFY status=2
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_GUI_VER=OpenVPN_GUI_11
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_TCPNL=1
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_COMP_STUBv2=1
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_COMP_STUB=1
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_LZO=1
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_LZ4v2=1
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_LZ4=1
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_NCP=2
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_PROTO=2
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_PLAT=win
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 peer info: IV_VER=2.4.4
Feb 12 08:57:43 openvpn 9240 12.3.456.789:5626 TLS: Initial packet from [AF_INET]12.3.456.789:5626, sid=588b2104 1bcabac2
(der oben angesprochene TLS Error fehlt in diesem Ausschnitt).

Hat jemand noch ne Idee?:D Ich hab den Spaß nicht aufgesetzt, diesen lediglich übernommen.
Für jeglichen Input bin ich sehr dankbar!
Beste Grüße,
Charlie
 
Dante2000 schrieb:
Verfügt der Kollege über einen IPv4 Anschluss oder wurde dieser "vor kurzem" auf IPv6 abgeändert?
Er hat nun nachgucken können. Vodafon Kunde und DS Lite.... Also keine public/unique ipv4..hier liegt dann ja vermutlich der Hund begraben. Also entweder VPN umstellen oder er muss gucken dass er Vodafon kontaktiert?
 
Einzige Lösung ist, das er Vodafone kontaktiert und darum bittet, auf IPv4 umgestellt zu werden. Das funktioniert in der Regel kosten- sowie problemlos. Haben bereits zahlreiche Mitarbeiter bei mir im Unternehmen machen müssen (Die sich ebenfalls "plötzlich" nicht mehr mit VPN Verbinden konnten).

IPv6 und VPN schließt sich leider aus. Daher gibts hier keine andere Lösungen.
 
Ich bin kein Netzwerkguru aber eine Point to Site Verbindung sollte so doch auch möglich sein? Es ist ja im Normalfall per SSL VPN nichts anderes vom Verbindungsaufbau her wie eine Websitenaufruf?
Site to Point sehe ich ein aber ich lasse mir gerne erklären warum das nicht geht :)
 
OpenVPN ist (im Gegensatz zu z. B. IPsec) eigentlich recht unempfindlich gegenüber NAT bzw. CG-NAT.

Das Netzwerk vom Client verwendet nicht zufällig das gleiche 192.168.10.0/24-Netz wie das VPN?
Ich würde auch mal probieren am Client noch nobind einzufügen damit ein zufälliger Port verwendet wird.
 
TheCadillacMan schrieb:
Das Netzwerk vom Client verwendet nicht zufällig das gleiche 192.168.10.0/24-Netz wie das VPN?
Das habe ich schon geprüft leider nicht.

Grundsätzlich kann er sich ja verbinden. Es kommt nur seit circa 2 Wochen zu Ausfällen, immer im Zusammenhang mit dem TLS handshake der nicht klappt. Er kommt dabei oft von unterschiedlichen IPs bzw. über unterschiedliche Ports und ich denke dass ich das Problem bei der (re-)authentifizierung.
Er meldet sich an mit 12.3.45.678:9999; erneuter TLS handshake - er meldet sich mit 12.3.45.678:8888 und fliegt raus -> "Authentication failed". Eventuell doch eine Störung bei Vodafon die dazu führt dass er sehr regelmäßig ne neue interne IPv4 bekommt?
 
Die Portänderung sollte nicht ins Gewicht fallen, wenn sich wirklich die IP zu häufig ändert könnte das "--persist-remote-ip" allerdings relevant werden. Wenn er wirklich während einer Session eine neue IP zugewiesen bekommt, würde sich das aber durch eine generelle Unterbrechung bemerkbar machen. Noch etwas auffällig ? Eventuell bestimmte Uhrzeit ? Ist es wirklich immer der reconnect vom auslaufen der Session oder bricht die Verbindung inital durch etwas anderes ab ?
 
Feb 12 10:36:57openvpn924012.3.456.789:5674 SIGTERM[soft,delayed-exit] received, client-instance exiting
Feb 12 10:36:51openvpn924012.3.456.789:5674 SENT CONTROL [Benutzer]: 'AUTH_FAILED' (status=1)
Feb 12 10:36:51openvpn924012.3.456.789:5674 Delayed exit in 5 seconds
Feb 12 10:36:51openvpn924012.3.456.789:5674 PUSH: Received control message: 'PUSH_REQUEST'
Feb 12 10:36:50openvpn924012.3.456.789:5674 [Benutzer] Peer Connection Initiated with [AF_INET]12.3.456.789:5674
Feb 12 10:36:50openvpn924012.3.456.789:5674 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384
Feb 12 10:36:50openvpnuser 'Benutzer' could not authenticate.
Feb 12 10:36:50openvpn924012.3.456.789:5674 TLS: Username/Password authentication deferred for username 'Benutzer' [CN SET]
Feb 12 10:36:50openvpn924012.3.456.789:5674 PLUGIN_CALL: POST /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so/PLUGIN_AUTH_USER_PASS_VERIFY status=2

Hier nochmal ein Auszug des Logs (ganz frisch!). Es gibt leider keine Konstanten dabei, weder Uhrzeit noch mögliche Auslöser sind bekannt oder zuzuordnen. Aber ja du hast Recht, kann eigentlich nicht hinkommen mit dem Sessionende - bricht also auch unabhängig davon mal ab.
Im Log des NPS für die Radius Authentifizierung sehe ich um die Uhrzeit keine Einträge für den User.

Noch ein Nachtrag: Es werden die korrekten Credentials genutzt!
 
Wie lange funktioniert das Verbinden denn nicht ? Oder könnte er sich wenn er den vpn-client neu startet direkt wieder verbinden ?
Sind das extra Credentials oder mit AD anbindung ?
Warum eigentlich der 8.8.8.8 als 2. DNS ?
 
Zuletzt bearbeitet:
Genauere Zeit liegt nicht vor, ein einfacher restart des VPN Clients reich wohl nicht aus - wenn er kurz wartet läuft das aber wieder.
Das ist mit AD Anbindung (Radius, also Domain NPS)
War wohl mal als Test eingerichtet, gibt also keinen tieferen Sinn dahinter..
 
Dante2000 schrieb:
IPv6 und VPN schließt sich leider aus. Daher gibts hier keine andere Lösungen.
Stimmt zwar nicht mehr, aber tut für den Fall trotzdem nichts zur Sache.

Würde auch erst mal versuchen Dual-Stack zu bekommen und dann weitersehen. Dass die eingesetzte pfSense Version veraltet ist, brauch ich wohl nicht zu erwähnen. 😉
 
Bob.Dig schrieb:
Stimmt zwar nicht mehr, aber tut für den Fall trotzdem nichts zur Sache.

Würde auch erst mal versuchen Dual-Stack zu bekommen und dann weitersehen. Dass die eingesetzte pfSense Version veraltet ist, brauch ich wohl nicht zu erwähnen. 😉
Hm, zumindest PPTP (Ich weis veraltet - Aber in China bsp. der einzige Weg nach "draußen") sowie SSTP sind mit IPv6 nicht umsetzbar. OpenVPN macht meines Wissens auch ständig Probleme, solange kein IPv4 verwendet wird. Hier lasse ich mich aber auch gerne eines besseren belehren.

Fakt ist, das hier auf der Seite des "Kollegen" eine Änderung stattgefunden haben muss. Wenn hier die IP-Version vor kurzem abgeändert wurde und es seitdem Probleme gibt, liegt das Problem eindeutig beim "Kollegen".
 
Dante2000 schrieb:
Hier lasse ich mich aber auch gerne eines besseren belehren.
Mit OVPN 2.5 kann selbst das Tunnelnetz nur aus IPv6 bestehen, vorher war wohl an dieser Stelle immer auch IPv4 von Nöten. Bin aber selbst nicht der Experte und hab es nicht getestet. Ich bin schon froh, wenn es irgendwie läuft. 😅
 
  • Gefällt mir
Reaktionen: Dante2000
Bob.Dig schrieb:
Mit OVPN 2.5 kann selbst das Tunnelnetz nur aus IPv6 bestehen, vorher war wohl an dieser Stelle immer auch IPv4 von Nöten. Bin aber selbst nicht der Experte und hab es nicht selbst getestet. Ich bin schon froh, wenn es irgendwie läuft. 😅
Gut zu wissen. Bin seit 2.4 nicht mehr mit OpenVPN in Kontakt gekommen, habe aber 5 Jahre lang pfsense Firewalls mit OpenVPN für ca 150 Mitarbeitern administriert. Aber auch das ist schon wieder über ein Jahr her. ^^
 
  • Gefällt mir
Reaktionen: Bob.Dig
Nur sollte dann die Verbindung nicht schon direkt scheitern, nicht erst mittendrin ?
@TE Bitte, sofern dir möglich, mal das Loglevel der FW erhöhen, eventuell unterschlägt er auf 3 Details - 6 oder 7 sollte passen.
 
Zurück
Oben