OpenVPN Network eof error

Hallo Zusammen,

da viele Hotels VPN von Fritzbox & Co in der Regel blocken, hatte ich mir vor ein paar Jahren einen Qnap (Linux Basiert) angeschafft und das OpenVPN installiert auf TCP Port 80.
Dies klappte fehlerfrei bis ich meine Firmware von 3.x auf 4.2.2 angehoben habe. Seit dem bekomme ich vom Android und iPhone folgenden Fehler bei der Einwahl: openvpn network_eof_error.
An der Configuration wurde nichts geändert.

Hat jemand das gleiche Problem bzw noch besser eine Lösung für das Problem?
Der Support supportet es aktuell zumindest nicht und den Server habe ich bereits einmal erfolglos neu aufgesetzt.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 315368

Url: https://administrator.de/forum/openvpn-network-eof-error-315368.html

Ausgedruckt am: 22.12.2024 um 22:12 Uhr

9 Kommentare

Neuester Kommentar

Hallo D46505SPI,

was sagt denn das log dazu?
Normalerweise zu finden unter /var/log/XXX
XXX = messages, syslog oder openvpn.log (oder ähnlich)

Grüße
Ketanest

Hi Ketanest,

danke für deine Rückmeldung.

Leider logt er nichts, da der Log mit einem "#" ausgeklammert ist.
Evt ist der Fehler in dieser Zeile der Server.conf: push "dhcp-option DNS 10.10.10.10"
Das ist kein DNS Server in meinem Adressbereich. Mein Router hört auf der 10.10.30.1
=> Update in den Einstellungen in der Weboberfläche gefunden unter Manuell setzen => Jetzt stimmt es in der Datei - Es geht aber dennoch nicht...

Leider überschreibt das System beim Dienstneustart die Datei wieder mit der Generierung, sodass er meine Änderung (Log und IP vom DNS) nicht speichert über den VI.

hier noch der Log vom Handy (Android):

Dann habe ich hier noch die Konfiguration meines Clienten:

client
dev tun2001
script-security 3
proto tcp
remote  meinserver.domaintld  80  #Natürlich steht hier die korrekte URL
resolv-retry infinite
nobind
<ca>
-----BEGIN CERTIFICATE-----
XXX 
Cert für das Forum entfernt 
XXX
-----END CERTIFICATE-----
</ca>
auth-user-pass
auth-nocache
reneg-sec 0
cipher AES-256-CBC
tls-cipher TLS-SRP-SHA-RSA-WITH-3DES-EDE-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
comp-lzo

Und hier die Serverkonfiguration (durch die Qnap Software generiert):

[~] # find / -name server.conf
/mnt/ext/opt/vpnopenvpn/etc/openvpn/server.conf
^C
[~] # vi /mnt/ext/opt/vpnopenvpn/etc/openvpn/server.conf
---
port 80
proto tcp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/myserver.crt
key /etc/openvpn/keys/myserver.key
auth-user-pass-verify /usr/sbin/vpn_check_account via-env
client-cert-not-required
username-as-common-name
no-name-remapping
dh /etc/openvpn/keys/dh1024.pem
server 10.10.31.0 255.255.255.0
ifconfig-pool-persist /var/log/ipp.txt
push "redirect-gateway def1"  
push "dhcp-option DNS 10.10.10.10" #falscher Server (siehe oben)  
client-to-client
duplicate-cn
keepalive 10 60
reneg-sec 0
cipher AES-256-CBC
tls-cipher TLS-SRP-SHA-RSA-WITH-3DES-EDE-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
A:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
comp-lzo
max-clients 10
client-connect /etc/openvpn/connect.sh
client-disconnect /etc/openvpn/disconnect.sh
management localhost 7505
persist-key
persist-tun
status /var/log/openvpn-status.log
#log /tmp/openvpn.log
verb 3
/mnt/ext/opt/vpnopenvpn/etc/openvpn/server.conf [+]

DANKE

TCP als Encapsulation zu benutzen ist tödlich ! Auch OpenVPN rät dringenst davon ab. Zudem nutzt du TCP 80 als Port was auch mit erheblichen Problemen verbunden ist und sofort Konflikte mit HTTP Ports bei Endgeräten auslöst.
Das wird vermutlich der grundlegende Fehler sein.
Wenn überhaupt solltest du es auf UDP 80 setzen um das wenigstens zu minimieren.
Noch besser ist es UDP 8080 oder UDP 8088 usw. zu verwenden oder wie es eigentlich vorgeschrieben ist KEINE der IANA vergebenen Ports zu nutzen sondern die sog. freien Ephemeral Ports im Bereich 49152 bis 65535 zu verwenden. Z.B. UDP 58080 was man sich leicht merken kann.
Damit bist du mit OpenVPN vollkommen konfliktfrei und diese Ports werden nirgendwo gefiltert.
Auf alle Fälle solltest du die TCP Encap dringenst ändern.
Googelt man auch mal nach dem Fehler gibt es zahllose Hinweise das der Parameter keysize 128 das problem löst !
https://forums.openvpn.net/viewtopic.php?t=12069

Hi,

vielen Dank für deine Rückmeldung.
Ich habe auf TCP 80 umgestellt weil viele Hotels alles blocken ausser Surfen und Mailen. Selbst der Port 443 über den es ebenfalls eine Zeit lief ist mitlerweise in vielen Hotels dicht.
Ein zweiter Server läuft über IPsec, was zwar noch häufiger erreichbar war als der normale UDP vom opendns, jedoch auch bereits teilweise gesperrt ist.

Bis zum Firmwareupdate lief es problemlos...

Den Schlüssel auf 128 zu senken hatte ich testweise versucht, ebenfalls erfolglos.

Dennoch solltest du aus Performancegründen kein TCP nutzen. Auch das MTU Handling wird schwerer da erheblich mehr Overhead bei TCP Encapsulation. Wenn es denn unbedingt Port 80 sein muss nimmst du UDP 80.
Da wirst du dann um ein detailierteres Debugging nicht drum rum kommen. Must du mal den Debug Level höher drehen oder parallel mal checken wie sich ein z.B. Raspberry Pi mit einem aktuellen OpenVPN als Server verhält. Oder mal ein Live Ubuntu oder Debian in einer VM.
Kannst du in den release Notres zum Firmware Update irgendwas lesen in Bezug auf OVPN Updates, sprich was da upgedated worden ist ?!

Hi,

ich habe mal UDP 63030 testweise genommen wobei er hier bei "Connecting..." hängen bleibt. Portweiterleitung in der Fritzbox ist konfiguriert - total doof gemacht das das Log im Qnap nicht funktioniert. Ich teste das mal mit einer VM und Linux Distri und wenn das klappt spiele ich das auf einen Raspberry PI3 - die bekommt man ja schon für kleines Geld...

Mmmhhh...das bleibt aber dann irgendwo in der Firewall hängen.
Was du aber machen kannst ist das Syslogging zu aktivieren auf dem QNAP. Wenigstens das sollte doch gehen, oder ? Ggf. hilft auch ein Wireshark um zu sehen wo die OVPN Pakete bleiben.
RasPi siehe hier:
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...

Ich habe es jetzt mit einem kleinen Raserpi PI gelöst.
Es scheint ein Problem mit dem qnap nas gewesen zu sein. Auch mit dem UDP Port hatte es nicht geklappt.
Danke für Eure Unterstützung!

Mmmhhh..schon komisch. Hast du das QNAP auf dem aktuellen Firmware Release ??
Ist schon sehr ungewöhnlich, denn OVPN ist eigentlich sehr stabil.
Aber egal...wenns so nun auch klappt ist ja alles gut