OpenVPN TCP Probleme

[MaChS]

Hallo,

ich habe OpenVPN manuell konfiguriert, doch leider funktioniert es nicht richtig.
Wenn ich mich verbinde, bekomme ich folgende Meldung:

Windows

Spoiler

Thu Jul 23 04:14:30 2020 us=828725 Attempting to establish TCP connection with [AF_INET]111.111.111.111:1194 [nonblock]
Thu Jul 23 04:14:30 2020 us=828725 MANAGEMENT: >STATE:1595470470,TCP_CONNECT,,,,,,
Thu Jul 23 04:14:31 2020 us=834997 TCP connection established with [AF_INET]111.111.111.111:1194
Thu Jul 23 04:14:31 2020 us=834997 TCP_CLIENT link local: (not bound)
Thu Jul 23 04:14:31 2020 us=834997 TCP_CLIENT link remote: [AF_INET]111.111.111.111:1194
Thu Jul 23 04:14:31 2020 us=834997 MANAGEMENT: >STATE:1595470471,WAIT,,,,,,
Thu Jul 23 04:14:31 2020 us=834997 Connection reset, restarting [0]
Thu Jul 23 04:14:31 2020 us=834997 TCP/UDP: Closing socket

Android

Spoiler

04:01:02.470 -- Connecting to [meinedomain.de]:1194 (111.111.111.111) via TCPv4

04:01:02.532 -- TCP recv error: Connection reset by peer

04:01:02.532 -- Transport Error: Transport error on 'meinedomain.de: NETWORK_RECV_ERROR

04:01:02.533 -- EVENT: TRANSPORT_ERROR info='Transport error on 'meinedomain.de: NETWORK_RECV_ERROR'

04:01:02.535 -- Client terminated, restarting in 5000 ms...

(Ich habe die richtige IP-Adresse in 111.111.111.111 geändert)

Letzte Zeilen der Debug-Datei

Spoiler

Thu Jul 23 02:50:32 2020 us=560421 OpenVPN 2.3.11 armle-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Feb 21 2020
Thu Jul 23 02:50:32 2020 us=560494 library versions: OpenSSL 1.0.2u-fips  20 Dec 2019, LZO 2.09
Thu Jul 23 02:50:32 2020 us=573852 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1195
Thu Jul 23 02:50:32 2020 us=574405 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Jul 23 02:50:32 2020 RADIUS-PLUGIN: Configfile name: /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf.
Thu Jul 23 02:50:32 2020 us=602972 PLUGIN_INIT: POST /var/packages/VPNCenter/target/lib/radiusplugin.so '[/var/packages/VPNCenter/target/lib/radiusplugin.so] [/var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY|PLUGIN_CLIENT_CONNECT|PLUGIN_CLIENT_DISCONNECT
Thu Jul 23 02:50:32 2020 us=603112 NOTE: --fast-io is disabled since we are not using UDP
Thu Jul 23 02:50:32 2020 us=632503 Diffie-Hellman initialized with 2048 bit key
Thu Jul 23 02:50:32 2020 us=658246 Control Channel Authentication: using '/usr/syno/etc/packages/VPNCenter/VPNcerts/ta.key' as a OpenVPN static key file
Thu Jul 23 02:50:32 2020 us=658400 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Jul 23 02:50:32 2020 us=658455 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Jul 23 02:50:32 2020 us=658554 TLS-Auth MTU parms [ L:1572 D:1170 EF:80 EB:0 ET:0 EL:3 ]
Thu Jul 23 02:50:32 2020 us=658642 Socket Buffers: R=[87380->87380] S=[16384->16384]
Thu Jul 23 02:50:32 2020 us=659168 TUN/TAP device tun0 opened
Thu Jul 23 02:50:32 2020 us=659276 TUN/TAP TX queue length set to 100
Thu Jul 23 02:50:32 2020 us=659340 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 23 02:50:32 2020 us=659447 /sbin/ifconfig tun0 10.8.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Thu Jul 23 02:50:32 2020 us=663102 Data Channel MTU parms [ L:1572 D:1450 EF:72 EB:143 ET:0 EL:3 AF:3/1 ]
Thu Jul 23 02:50:32 2020 us=663215 Listening for incoming TCP connection on [undef]
Thu Jul 23 02:50:32 2020 us=663283 TCPv4_SERVER link local (bound): [undef]
Thu Jul 23 02:50:32 2020 us=663323 TCPv4_SERVER link remote: [undef]
Thu Jul 23 02:50:32 2020 us=663372 MULTI: multi_init called, r=256 v=256
Thu Jul 23 02:50:32 2020 us=663488 IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=0
Thu Jul 23 02:50:32 2020 us=663569 MULTI: TCP INIT maxclients=5 maxevents=9
Thu Jul 23 02:50:32 2020 us=663664 Initialization Sequence Completed

openvpn.ovpn

Spoiler

remote meinedomain.de 1194
dhcp-option DNS 10.8.0.1

# client.crt
# client.key
# CA.crt
#ta.key
key-direction 1

verb 4
nobind
float
block-outside-dns
register-dns
redirect-gateway def1
dev tun
proto tcp-client
pull
tls-client
remote-cert-tls server
cipher AES-256-CBC
prng SHA256 32
auth SHA256
tls-version-min 1.2 or-highest
fast-io
comp-lzo no
auth-user-pass
auth-nocache

openvpn.conf.user

Spoiler

log /var/log/openvpn.log
verb 4
server 10.8.0.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
max-clients 5
topology subnet
push "sndbuf 0"
push "rcvbuf 0"
sndbuf 0
rcvbuf 0
management 127.0.0.1 1195
dev tun
proto tcp-server
port 1194
persist-tun
persist-key
cipher AES-256-CBC
prng SHA256 32
auth SHA256
tls-version-min 1.2 or-highest
tls-auth /usr/syno/etc/packages/VPNCenter/VPNcerts/ta.key 0
remote-cert-tls client
dh /usr/syno/etc/packages/VPNCenter/VPNcerts/dh2048.pem
ca /usr/syno/etc/packages/VPNCenter/VPNcerts/CA.crt
cert /usr/syno/etc/packages/VPNCenter/VPNcerts/Server.crt
key /usr/syno/etc/packages/VPNCenter/VPNcerts/Server.key
fast-io
comp-lzo no
keepalive 10 60
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
status /tmp/ovpn_status_2_result 30
status-version 2

Welche Ports müssen denn für OpenVPN (TCP) freigegeben werden? Ich habe es mehrmals überprüft und der Port 1194 müsste überall freigegeben sein. Die meisten anderen Ports (443, etc.) habe ich gesperrt. Wenn es nicht an den Ports liegt, woran könnte es dann liegen?

VG
Mark

 

[Kurt-oe1kyw]

DSM > Hauptmenü > VPN Server > links unten OpenVPN > ist dort in der Zeile "Clients den Server-LAN Zugriff erlauben" gesetzt?
Wenn nicht, Haken setzen und rechts unten auf Übernehmen klicken und nochmal probieren.
Das Protokoll kannst du auf UDP umschalten, Port 1194 ist der Richtige.

 

[MaChS]

DSM > Hauptmenü > VPN Server > links unten OpenVPN > ist dort in der Zeile "Clients den Server-LAN Zugriff erlauben" gesetzt?
Wenn nicht, Haken setzen und rechts unten auf Übernehmen klicken und nochmal probieren.
Das Protokoll kannst du auf UDP umschalten, Port 1194 ist der Richtige.

Leider nutze ich wie oben erwähnt eine benutzerdefinierte OpenVPN-Konfiguration und UDP ist für mich keine Option. Trotzdem danke

 

[Kurt-oe1kyw]

eine benutzerdefinierte OpenVPN-Konfiguration

ah ok:

 

[tproko]

1194 muss am Router zur Syno freigegeben werden.
1195 ist mMn nur für intern.

Deaktiviere kurzfristig für Tests mal die Firewall der Syno.
Hast du eine Fritzbox? Manchmal benötigt die einen Neustart bei den Port-Regeln.
Sperrt dein Provider 1194? Wenn du nach außen 443 nicht benötigst, wäre sowieso 443 statt 1194 eine gute Wahl zwecks Hotel WLANs etc.

 

[the other]

Moinsen,
dafür, dass du UDP als keine Option ansiehst benutzt du den Port 1194 aber an fast jeder Stelle in den Bildern...zB in den Fehlerlogs Windows und Android wird das bemeckert, dann in deiner openvpn.opvpn Konfigdatei.
Als Standard benutzt openVPN im TCP Modus 443 und im UDP Modus 1194. Das würd ich erstmal genauso auch probieren, ob das tut. Wenn ja, dann kannst du ggf. den Port verändern. Der Trick, openVPN auf TCP zu stellen wegen Hotels war hier auch mal in Anwendung, brachte dann viele Fehlerprotokolle, lief aber. Nachdem ich den Tip bekommen hatte, dass es trotzdem nicht best practice wäre (bzw. einfach openVPN eben von Haus aus udp erwartet), hab ich es auf udp 1194 umgestellt. Alternativ zu dem dann zu erwartenden Verbindungsproblemen aus WLANS in Hotels und co, wird empfohlen:
https://administrator.de/forum/probleme-openvpn-tcp-adresse-398704.html (hier der Beitrag weiter unten von aqui zum Thema UDP und TCP bei openVPN)

Viel Erfolg...

 

[tproko]

Bisschen OT
Ich verstehe deine Punkte nicht wirklich.
Welche Fehlerprotokolle meinst du da bei dir in Kombination mit tcp?

OpenVPN supported sowohl TCP als auch UDP - Standard ist UDP.
TCP hat einen gewissen Overhead in Package Size etc. Ja stimmt. Kann ich für mich aber zB vernachlässigen. TCP ist definitiv möglich.

Bezüglich Port: das ist der Port der am Server eingestellt wird, ja. Default ist 1194 udp bzw. 443 tcp, aber der kann beliebig geändert werden. Solange Client und Server den gleichen Port nehmen, sollte das auch passen... egal ob tcp oder udp. Er hat am Client und Server 1194, also sollte soweit passen.

Bei mir läuft nur UDP Server mit Port 443.

Ein Dual-Betrieb von udp und tcp ist auf der Syno sowieso nicht einfach möglich. Da nur ein Prozess gestartet wird.
/OT

@MaChS hast du am Router schon die Ports Freigegeben Richtung Syno? Syno Firewall?

 

[MaChS]

ah ok:

Anhang anzeigen 54196

Moinsen,
dafür, dass du UDP als keine Option ansiehst benutzt du den Port 1194 aber an fast jeder Stelle in den Bildern...zB in den Fehlerlogs Windows und Android wird das bemeckert, dann in deiner openvpn.opvpn Konfigdatei.
Als Standard benutzt openVPN im TCP Modus 443 und im UDP Modus 1194. Das würd ich erstmal genauso auch probieren, ob das tut. Wenn ja, dann kannst du ggf. den Port verändern. Der Trick, openVPN auf TCP zu stellen wegen Hotels war hier auch mal in Anwendung, brachte dann viele Fehlerprotokolle, lief aber. Nachdem ich den Tip bekommen hatte, dass es trotzdem nicht best practice wäre (bzw. einfach openVPN eben von Haus aus udp erwartet), hab ich es auf udp 1194 umgestellt. Alternativ zu dem dann zu erwartenden Verbindungsproblemen aus WLANS in Hotels und co, wird empfohlen:
https://administrator.de/forum/probleme-openvpn-tcp-adresse-398704.html (hier der Beitrag weiter unten von aqui zum Thema UDP und TCP bei openVPN)

Viel Erfolg...

1194 ist erstmal nur eine Zahl. Ich muss aufgrund meiner Netzwerk-Konfiguration TCP verwenden. Mit Port 443 hatte ich es schon versucht, aber da kommt gar keine Verbindung zustande. Dann hatte ich gelesen, dass man statt Port 443 auf der DS Port 1194 benutzen soll (auch für TCP), da Port 443 für eine Menge anderer Dinge benötigt wird. Außerdem möchte ich wohl später mal die Photo Station ausprobieren. Ich hätte natürlich auch Port 1234 oder so eintragen können, aber Port 1194 fand ich einleuchtender. Sonst weiß man später nicht mehr, wofür der Port gut ist. ;-) Danke für den Link, werde mir das nachher mal ansehen.

Bisschen OT
Ich verstehe deine Punkte nicht wirklich.
Welche Fehlerprotokolle meinst du da bei dir in Kombination mit tcp?

OpenVPN supported sowohl TCP als auch UDP - Standard ist UDP.
TCP hat einen gewissen Overhead in Package Size etc. Ja stimmt. Kann ich für mich aber zB vernachlässigen. TCP ist definitiv möglich.

Bezüglich Port: das ist der Port der am Server eingestellt wird, ja. Default ist 1194 udp bzw. 443 tcp, aber der kann beliebig geändert werden. Solange Client und Server den gleichen Port nehmen, sollte das auch passen... egal ob tcp oder udp. Er hat am Client und Server 1194, also sollte soweit passen.

Bei mir läuft nur UDP Server mit Port 443.

Ein Dual-Betrieb von udp und tcp ist auf der Syno sowieso nicht einfach möglich. Da nur ein Prozess gestartet wird.
/OT

@MaChS hast du am Router schon die Ports Freigegeben Richtung Syno? Syno Firewall?

Mit TCP haben die Logs nicht viel zu tun. Es ist aber doch hilfreich, wenn ich die Logs und Konfigurations-Dateien hier poste. Wie soll sonst der Fehler / das Problem gefunden werden? Wie oben schon beschrieben benötige ich definitiv TCP. Mir ist klar, dass UDP z. B. für Videostreaming von Vorteil ist, aber UDP funktioniert mit meiner Netzwerk-Konfiguration nicht.

Danke für den Hinweis mit dem Port. Ich war mir nicht ganz sicher, ob außer Port 1194 auch noch ein anderer Port benötigt wird. Wenn nur der eine Port benötigt wird, dann müsste das ja nicht der Fehler sein.

Ich habe jetzt überall den Port 443 freigegeben. Der ist jetzt definitiv verfügbar. Die Konfiguration habe ich an beiden Stellen auf Port 443 umgestellt. Es funktioniert jedoch immer noch nicht. Komischerweise bekomme ich jetzt nicht einmal eine Fehlermeldung. Es wird lediglich auf den Server gewartet. Ich versuche später mal den Netzwerkverkehr zu überprüfen, um die Fehlerquelle etwas besser eingrenzen zu können.

 

[MaChS]

Ok, mit Port 443 bekomme ich nun den Fehler: "TCP_SIZE_ERROR". Hat wohl mit der Firewall ein bisschen gedauert. Aber wie behebe ich den nun?

 

[tproko]

Mit TCP haben die Logs nicht viel zu tun. Es ist aber doch hilfreich, wenn ich die Logs und Konfigurations-Dateien hier poste.

Das war alles richtig und passt gut!

Mein ganzer Off Topic Bereich hat sich an the other gerichtet. Sorry falls das nicht richtig rüber kam. Er hat auch von Fehlern geschrieben, die meinte ich da.

Nur so zum Verständnis, welche anderen Anwendungen willst du am Router leicht unter 443 wohin weiter schleifen?
Habe das wohl etwas zu sehr abgekürzt. Bevor mein Vpn zum Router gewandert ist, hatte ich einen Port Forward von PublicIP:443 am Router zu interneNasIP:1194. Sprich nur von außen bis zum Router war es 443. Am NAS selber nicht.

 

[tproko]

Noch eine Frage. Versuchst du aus dem gleichen Netz die VPN Verbindung aufzubauen?

Bei mir klappts das nur von extern.
Und dann benötigst du entsprechende Portweiterleitungen am Router. Gibt es die schon?

 

[MaChS]

Das war alles richtig und passt gut!

Mein ganzer Off Topic Bereich hat sich an the other gerichtet. Sorry falls das nicht richtig rüber kam. Er hat auch von Fehlern geschrieben, die meinte ich da.

Nur so zum Verständnis, welche anderen Anwendungen willst du am Router leicht unter 443 wohin weiter schleifen?
Habe das wohl etwas zu sehr abgekürzt. Bevor mein Vpn zum Router gewandert ist, hatte ich einen Port Forward von PublicIP:443 am Router zu interneNasIP:1194. Sprich nur von außen bis zum Router war es 443. Am NAS selber nicht.

Ach so, sorry, hatte das falsch verstanden.

Den Port 443 benötige ich vielleicht bald für die Photo Station, und außerdem wird der schon für die Weiterleitung zu Port 5001 verwendet. Kann es sein, dass es deshalb nicht funktioniert? Leider sind die Fehlermeldungen (" TCP_SIZE_ERROR", etc.) nicht sehr aussagekräftig. Ich werde auf jeden Fall später noch ein wenig damit rumprobieren. Mit der Standard-Konfiguration hatte es damals problemlos geklappt, also muss es so ja auch möglich sein.

Ich habe derzeit den Port am NAS auf 443 eingestellt und vorher hatte ich den auf 1194. Mit dem Router von 443 auf 1194 weiterzuleiten habe ich noch nicht probiert, aber damit sollte zumindest einer der beiden Fehler auftreten.

Noch eine Frage. Versuchst du aus dem gleichen Netz die VPN Verbindung aufzubauen?

Bei mir klappts das nur von extern.
Und dann benötigst du entsprechende Portweiterleitungen am Router. Gibt es die schon?

Nein, ich nutze zum Testen das Netz meines Handys. Mit der Standardkonfiguration war das problemlos möglich über TCP und Port 1194.
Portweiterleitungen habe ich bereits in meinem Router hinzugefügt, derzeit von 443 zu 443.

Ergänzung: nginx nutzt den TCP Port 443 bei mir. Wohl für die Weiterleitung zu 5001 oder so. Jemand eine Idee, wie man das beheben kann?

 

[Synchrotron]

Es geht hier ein wenig durcheinander.

Der externe Port kann belegt werden, wie man ihn belegen möchte. Der ist erst mal nichts weiter als eine Nummer, die man angibt (z.B. In einem VPN-Client), damit der Router weiß, wohin er intern weiter leiten soll. Man kann beliebige externe Ports belegen, und im Router dann angeben, wenn auf 47110 etwas rein kommt, leite ich das intern an 12345 mit der internen statischen IP 5.6.7.8 weiter.

Es gibt eine Liste von Standardports wie 22, 443, 1194 etc., und es ist gute Praxis, DIESE Nummern nicht dafür zu verwenden, selbst andere Services anzutriggern. Und ja, es gibt das Problem, dass manche WLAN-Anbieter alle Ports außer den Standardports blockieren. Wenn man weiß, dass man damit öfter zu tun hat, opfert man halt doch einen Standardport, oder bohrt seinen Mobilfunkvertrag auf.

Das Gerät, das an der statischen IP intern lauscht, muss wissen, wenn dort etwas mit diesem (definierten) internen Port rein kommt, dann muss ich es an meinen VPN-SERVER weiter leiten. Da ist der externe Port aber egal, weil er im Router umgeschlüsselt wird. Kommt etwas mit anderem internen Port an, wird vielleicht die PhotoStation aufgerufen, oder die FileStation, oder der Webserver etc. Jeder dieser internen Ports muss extern eine Entsprechung haben, aber der externe kann ganz anders lauten als der, an den intern weiter geleitet wird. Und die Firewall muß so eingestellt sein, dass alles außer den festgelegten Ports blockiert wird.

Bitte alles vorher überlegen und festlegen, und dann umsetzen. Dabei selbst einrichten, Finger weg von UPnP. Dann testen und dokumentieren.

 

[MaChS]

Es geht hier ein wenig durcheinander.

Der externe Port kann belegt werden, wie man ihn belegen möchte. Der ist erst mal nichts weiter als eine Nummer, die man angibt (z.B. In einem VPN-Client), damit der Router weiß, wohin er intern weiter leiten soll. Man kann beliebige externe Ports belegen, und im Router dann angeben, wenn auf 47110 etwas rein kommt, leite ich das intern an 12345 mit der internen statischen IP 5.6.7.8 weiter.

Es gibt eine Liste von Standardports wie 22, 443, 1194 etc., und es ist gute Praxis, DIESE Nummern nicht dafür zu verwenden, selbst andere Services anzutriggern. Und ja, es gibt das Problem, dass manche WLAN-Anbieter alle Ports außer den Standardports blockieren. Wenn man weiß, dass man damit öfter zu tun hat, opfert man halt doch einen Standardport, oder bohrt seinen Mobilfunkvertrag auf.

Das Gerät, das an der statischen IP intern lauscht, muss wissen, wenn dort etwas mit diesem (definierten) internen Port rein kommt, dann muss ich es an meinen VPN-SERVER weiter leiten. Da ist der externe Port aber egal, weil er im Router umgeschlüsselt wird. Kommt etwas mit anderem internen Port an, wird vielleicht die PhotoStation aufgerufen, oder die FileStation, oder der Webserver etc. Jeder dieser internen Ports muss extern eine Entsprechung haben, aber der externe kann ganz anders lauten als der, an den intern weiter geleitet wird. Und die Firewall muß so eingestellt sein, dass alles außer den festgelegten Ports blockiert wird.

Bitte alles vorher überlegen und festlegen, und dann umsetzen. Dabei selbst einrichten, Finger weg von UPnP. Dann testen und dokumentieren.

Leider verstehe ich nicht, worauf die meisten hier hinauswollen. Wie so einige hier empfohlen haben, habe ich den Port (intern & extern) von 1194 auf 443 geändert. Der Traffic kommt auch am Port 443 an (habe ich getestet), aber OpenVPN nutzt den Port nicht, da er bereits von nginx verwendet wird. Aus diesem Grund werde ich nun wieder den Port 1194 verwenden und hoffen, dass ich es damit zum Laufen bekomme. Sollte ich den Port 1194 in irgendwelchen Netzen nicht verwenden können, kann ich den externen Port ja immer noch auf 443 oder so setzen und dann an die DS an Port 1194 oder so weiterleiten. Wo ist das Problem? Ich bezweifle, dass das ursprüngliche Problem war, dass ich den Port 1194 (TCP) verwendet habe. Immerhin nutzt Synology für die TCP VPN-Verbindung ebenfalls Port 1194 in der Standardkonfiguration (habe ich eben recherchiert).

Ergänzung: Ich verwende nun wieder Port 1194 und der Traffic kommt auch auf dem NAS an (über mein Handynetz). Doch leider bekomme ich den gleichen Fehler, wie in meinem ersten Post. Wenn ich den Fehler finde, werde ich es hier schreiben. Falls euch irgendetwas einfällt, lasst es mich bitte wissen. Aber den Port ändere ich erstmal nicht mehr.

Weiß jemand, wieso openvpn 2x auf Port 1194 zuhört? Ist das normal? Scheint wohl kein Problem zu sein.

 

[tproko]

Ich möchte das von @Synchrotron nochmal aufgreifen.

Du kannst OpenVPN intern und extern auf verschiedenen Ports laufen lassen. Am NAS ist 443 / 5001 schon belegt, klar das wird man nicht verwenden können.

Du vermischt interne (in diesem Fall beim NAS) und externe Ports (Am Router).

Also nochmal:

1. Am NAS intern läuft OpenVPN auf 1194, kannst du genau so lassen
2. Über extern kommst du per Port 1234 (kann zB. 443, 1234 oder 1194 sein)
3. Deine Client Config muss natürlich (!) dann 1234 als Port definieren, also den externen, nicht den internen! (Das muss manuell im exportierten Config-File angepasst werden)
4. Dein Router muss den externen Port 1234 auf intern NAS-IP 1194 weiterleiten
5. Ggf. musst du die Firewall erweitern, damit hier nichts gesperrt wird (NAS?, Router?)

 

[diver68]

Der Traffic kommt auch am Port 443 an (habe ich getestet), aber OpenVPN nutzt den Port nicht, da er bereits von nginx verwendet wird

Dann benutze doch SSLH. Damit kannst du mehrere applikationen auf Port 443 betreiben. Hier auch eine Anleitung https://christiandietze.de/synology-diskstation-dsm-6-sslh-anleitung/

 

[MaChS]

Ich möchte das von @Synchrotron nochmal aufgreifen.

Du kannst OpenVPN intern und extern auf verschiedenen Ports laufen lassen. Am NAS ist 443 / 5001 schon belegt, klar das wird man nicht verwenden können.

Du vermischt interne (in diesem Fall beim NAS) und externe Ports (Am Router).

Also nochmal:

1. Am NAS intern läuft OpenVPN auf 1194, kannst du genau so lassen
2. Über extern kommst du per Port 1234 (kann zB. 443, 1234 oder 1194 sein)
3. Deine Client Config muss natürlich (!) dann 1234 als Port definieren, also den externen, nicht den internen! (Das muss manuell im exportierten Config-File angepasst werden)
4. Dein Router muss den externen Port 1234 auf intern NAS-IP 1194 weiterleiten
5. Ggf. musst du die Firewall erweitern, damit hier nichts gesperrt wird (NAS?, Router?)

Sorry, aber wo verwechsle ich interne/externe Ports? Ich hatte es von den Vorrednern so verstanden, dass OpenVPN mit TCP den Port 443 intern benötigen würde. Das habe ich auch ausprobiert und es funktioniert einfach nicht, da Port 443 schon benutzt wird. Außerdem nutzt Synology ja selbst den Port 1194 für TCP. Wenn ich von Port 443 auf 1194 weiterleiten lasse, bringt mir das auch nicht viel. Ich bekomme dadurch selbstverständlich den gleichen Fehler, wie schon zu Beginn. Ich habe alle Firewalls aus meiner Sicht richtig konfiguriert, denn der Traffic kommt ja auch bei Port 1194 an. Ich gehe davon aus, dass etwas anderes an der Konfiguration nicht stimmt, doch leider bin ich kein OpenVPN-Experte.

Dann benutze doch SSLH. Damit kannst du mehrere applikationen auf Port 443 betreiben. Hier auch eine Anleitung https://christiandietze.de/synology-diskstation-dsm-6-sslh-anleitung/

Der Port 443 ist mir nicht so wichtig. Ich würde es erstmal gerne mit Port 1194 zum Laufen bekommen. Wenn ich das geschafft habe, werde ich mir mal die "port-share"-Option von OpenVPN angucken. Sollte das nicht funktionieren, werde ich auf dein Tutorial zurückgreifen. Danke hierfür

 

[tproko]

Ich hatte es von den Vorrednern so verstanden, dass OpenVPN mit TCP den Port 443 intern benötigen würde.

Das stimmt so nicht. Du kannst OpenVPN intern mit TCP oder UDP mit jedem beliebigen Port starten... ZB. mit Port 1194.

Aber egal, ich glaube wir haben etwas aneinander vorbei geschrieben.

Port 1194 und der Traffic kommt auch auf dem NAS an (über mein Handynetz)

Super, also geht OpenVPN ja grundsätzlich... oder?? Geht es jetzt über TCP und Port 1194?
Was geht jetzt nicht? Das lese ich eigentlich aus Post #1 leider nicht mehr heraus.

Es geht am Handy, aber bei anderen Netzen geht es nicht? Das deutet dann halt darauf hin, dass das andere Netz dir 1194 TCP sperrt...


Mittlerweile bin ich mir eigentlich nicht mehr sicher, was du genau für ein Problem hast, und was du wirklich wann änderst
Ich glaub in deinen Post #1 sind auch openvpn.config und openvpn.client.config verdreht. Aber das ist nur ein kleines Detail am Rande.

 

[the other]

Moinsen,
erst einmal sorry, wenn ich hier für Verwirrungen gesorgt habe. An den TE: du hast ausführliche Logs angegeben, das war und ist super und genau richtig und leider oft viel zu selten. Also alles richtig gemacht!!! Mein Vorschlag, erstmal alles auf den Standard Protokollen und Ports einzurichten kam daher: wenn die ootb Lösung gut funktioniert, dann kann individuell gebastelt werden...

@ tproko: bei mir liefen Fehlermeldungen auf dem VPN Server auf (bei Nutzung von TCP Port 443) bezüglich Bad Encapsulation, das dann auch viel und kontinuierlich....der Tunnel selber wurde aber auch hier problemlos aufgebaut, wie ich auch geschireben habe. Wegen der andauernden Fehlerlogs hatte ich dann die Farge bei dem o.g. Forum mal reingestellt, und eben die Antwort bekommen...hier noch einmal der Thread:
https://administrator.de/forum/laie-openvpn-log-564910.html#comment-1443416
Wie gesagt, bei mir läuft / lief sowohl TCP 443 als auch UDP 1194 im Praxisbetrieb problemfrei...nur um deine OT Frage zu beantworten...

Allen ein gesundes Wochenende!!

 

[MaChS]

Das stimmt so nicht. Du kannst OpenVPN intern mit TCP oder UDP mit jedem beliebigen Port starten... ZB. mit Port 1194.

Aber egal, ich glaube wir haben etwas aneinander vorbei geschrieben.



Super, also geht OpenVPN ja grundsätzlich... oder?? Geht es jetzt über TCP und Port 1194?
Was geht jetzt nicht? Das lese ich eigentlich aus Post #1 leider nicht mehr heraus.

Es geht am Handy, aber bei anderen Netzen geht es nicht? Das deutet dann halt darauf hin, dass das andere Netz dir 1194 TCP sperrt...


Mittlerweile bin ich mir eigentlich nicht mehr sicher, was du genau für ein Problem hast, und was du wirklich wann änderst
Ich glaub in deinen Post #1 sind auch openvpn.config und openvpn.client.config verdreht. Aber das ist nur ein kleines Detail am Rande.

Gut, denn das hatte ich ja von Anfang an.

Nein, leider geht es immer noch nicht. Der Traffic kommt zwar bei Port 1194 an, aber die Verbindung schlägt trotzdem fehl. Ich habe lediglich mit tcpdump getestet, ob es ein Firewall-/Port-Problem ist, wie vermutet.

Ich habe immer noch das Problem aus Post #1. Keine Ahnung, wieso du meinst, dass ich die Dateien vertauscht habe. Aus meiner Sicht stimmt das so. Wie gesagt, ich bin kein Linux-/OpenVPN-Profi, deshalb kann ich auch irgendeinen dummen Fehler gemacht haben. Daher werde ich wohl bald alles rückgängig machen und nachsehen, ob die Standard-Konfiguration von Synology noch funktioniert. Danach werde ich dann Schritt für Schritt die Konfiguration anpassen. Hoffentlich finde ich so den Fehler...

Mein Vorschlag, erstmal alles auf den Standard Protokollen und Ports einzurichten kam daher: wenn die ootb Lösung gut funktioniert, dann kann individuell gebastelt werden...

Genau das verwirrt mich, denn der Standardport für OpenVPN TCP ist bei Synology ebenfalls 1194. Danke für den Link, werde ich mir nachher mal ansehen.