OpenVPN TCP Probleme

Status
Für weitere Antworten geschlossen.

tproko

Benutzer
Sehr erfahren
Mitglied seit
11. Jun 2017
Beiträge
2.101
Punkte für Reaktionen
253
Punkte
129
Ich verwende Syno vpn schon länger nicht mehr. Haben die das jetzt mittlerweile so aufgeteilt oder kommt die user.conf rein von dir?
Dachte zuerst das soll die Client (Handy) Config sein.

Sorry sollte genauer lesen bevor ich da mehr Fragen stelle.

Kurz zusammen gefasst, ging vpn noch nie, nur ein TCP Dump oder?
 

the other

Benutzer
Sehr erfahren
Mitglied seit
17. Okt 2015
Beiträge
2.100
Punkte für Reaktionen
541
Punkte
154
Moinsen,
der STANDARD Port ist für openVPN UDP 1194:
https://openvpn.net/images/pdf/OpenVPN_Access_Server_Sysadmin_Guide_Rev.pdf
https://www.thomas-krenn.com/de/wiki/OpenVPN_am_Synology_NAS_einrichten
https://www.synology.com/de-de/knowledgebase/DSM/help/VPNCenter/vpn_setup
Ich nutze ebenfalls nicht mehr das NAS als VPN-Server, hier waren aber vor ca. 1,5 Jahren als Standard der o.g Port benutzt mit UDP Protokoll...wie hier ja mehrfach geschrieben, kann davon auch abgewichen werden, aber auch Synology schreibt (sihe LINK), dass die Standardeinstellung UDP 1194 ist....
 

MaChS

Benutzer
Mitglied seit
23. Jul 2018
Beiträge
17
Punkte für Reaktionen
0
Punkte
1
Ich verwende Syno vpn schon länger nicht mehr. Haben die das jetzt mittlerweile so aufgeteilt oder kommt die user.conf rein von dir?
Dachte zuerst das soll die Client (Handy) Config sein.

Sorry sollte genauer lesen bevor ich da mehr Fragen stelle.

Kurz zusammen gefasst, ging vpn noch nie, nur ein TCP Dump oder?

Die Datei ist für die manuelle Konfiguration des VPN und liegt auf dem NAS.

VPN ging mit der Standard-Konfiguration über TCP und Port 1194 problemlos, nur dann habe ich es mit einer manuellen Konfiguration versucht (für die Client-Zertifikat-Authentifizierung). Leider kam es dann zu dem Fehler von Post #1. Zwischendurch hatte ich noch einige Firewall-Regeln gelöscht (z. B. 443), daher hatte ich gedacht, dass es daran liegen könnte. Ganz ausschließen würde ich es immer noch nicht, aber wenn ihr meint, dass es reicht, einen einzigen Port, wie hier den Port 1194, geöffnet zu haben, wird es wohl nicht das Problem sein. Der TCP Dump funktioniert jedenfalls. Von der Konfiguration muss dann etwas falsch sein.

Moinsen,
der STANDARD Port ist für openVPN UDP 1194

Das stimmt, aber für TCP scheint es ebenfalls 1194 zu sein. Ich habe bei meinen NAS in der Standard-Konfigurations-Datei nachgesehen. Habe ich über das Web-Interface TCP ausgewählt, steht in der Datei der Port 1194. Haben die wohl so gemacht, weil Port 443 schon von anderen Diensten verwendet wird.
 
Zuletzt bearbeitet:

the other

Benutzer
Sehr erfahren
Mitglied seit
17. Okt 2015
Beiträge
2.100
Punkte für Reaktionen
541
Punkte
154
Moinsen,
auch wenn der Hinweis jetzt hier etwas spät kommt (dafür habe ich das auch schon inflationär im hiesigen Forum geschrieben, sorry Leute!):
überleg dir doch mal ernsthaft, ob du die Idee "VPN-Server auf NAS" nicht begräbst und den VPN-Server zB auf einem kleinen Raspberry Pi laufen lässt. Das wäre definitv sicherer und ggf. in der Einrichtung auch schicker...jm2c
 

MaChS

Benutzer
Mitglied seit
23. Jul 2018
Beiträge
17
Punkte für Reaktionen
0
Punkte
1
Moinsen,
auch wenn der Hinweis jetzt hier etwas spät kommt (dafür habe ich das auch schon inflationär im hiesigen Forum geschrieben, sorry Leute!):
überleg dir doch mal ernsthaft, ob du die Idee "VPN-Server auf NAS" nicht begräbst und den VPN-Server zB auf einem kleinen Raspberry Pi laufen lässt. Das wäre definitv sicherer und ggf. in der Einrichtung auch schicker...jm2c

Ich hatte das letztes Jahr so gelöst, aber mir gefiel die getrennte Lösung nicht so gut. Die Einrichtung war definitiv leichter, aber sicherer? Das glaube ich nicht. Ich überlege stattdessen, ob ich einen VPN-Server auf einem VPS nutzen soll. Damit wäre dann auch UDP möglich, glaube ich. Trotzdem versuche ich erstmal die Lösung aus Post #1.
 

the other

Benutzer
Sehr erfahren
Mitglied seit
17. Okt 2015
Beiträge
2.100
Punkte für Reaktionen
541
Punkte
154
Moinsen,
sicherer weil:
du öffnest aktuell gezwungenermaßen einen Port für VPN in deiner Fritzbox (oder anderem Router). Dieser zeigt aber eben auf dein NAS, da dieses ja zugleich VPN-Server als auch Datensammlung ist. Damit steht ein potentielles Tor offen, welches eben auch auf deine Datensammlung zeigt. Daher wäre es sicherer, wenn du das trennst. Dann zeigt der einzige Port von außerhalb auf deinen separierten VPN-Server. Über diesen dann den Tunnel aufbauen, andere Portweiterleitungen nicht nötig. Davon ab traue ich den Machern von den VPN Lösungen bei Raspi eher eine schnelle Aktualisierung zu als den Synoleuten, hier ist einiges an Software den aktuellen Versionen z.T arg hinterher...
 

MaChS

Benutzer
Mitglied seit
23. Jul 2018
Beiträge
17
Punkte für Reaktionen
0
Punkte
1
Moinsen,
sicherer weil:
du öffnest aktuell gezwungenermaßen einen Port für VPN in deiner Fritzbox (oder anderem Router). Dieser zeigt aber eben auf dein NAS, da dieses ja zugleich VPN-Server als auch Datensammlung ist. Damit steht ein potentielles Tor offen, welches eben auch auf deine Datensammlung zeigt. Daher wäre es sicherer, wenn du das trennst. Dann zeigt der einzige Port von außerhalb auf deinen separierten VPN-Server. Über diesen dann den Tunnel aufbauen, andere Portweiterleitungen nicht nötig. Davon ab traue ich den Machern von den VPN Lösungen bei Raspi eher eine schnelle Aktualisierung zu als den Synoleuten, hier ist einiges an Software den aktuellen Versionen z.T arg hinterher...

Ich habe sowieso für Plex einen Port offen und möchte das auch nicht ändern. Also Port 80 (für das Zertifikat), Port 1194 (für das VPN) und der Plex-Port sind bei mir offen, wenn ich mich richtig erinnere. Beim Raspberry Pi hat man noch das Problem, dass die Geräte generell sehr beliebt für Angriffe sind. Eine deutlich größere Sicherheitslücke ist die fehlende IP-Sperre bei mir. Aus Konfigurationsgründen kann ich diese nämlich nicht aktivieren. ? Trotzdem glaube ich, dass mein System relativ sicher ist.Zielgerichtete Angriffe gibt es bei mir sowieso nicht und die Massenangriffe sind meines Erachtens eher ungefährlich, da sie nur offensichtliche Schwachstellen ausnutzen. Vor der VPN-Lösung hatte ich die 2-Faktor-Authentifizierung aktiviert, aber da die VPN-Lösung für einige Anwendungsfälle (z. B. Backups anderer Systeme ohne öffentliche IP aus dem Internet) praktischer ist und angeblich etwas sicherer sein soll, wollte ich meinen NAS dementsprechend ändern. Mal sehen, vielleicht bekomme ich es ja noch zum Laufen. Sollte ich es hinbekommen, werde ich die Lösung / den Fehler hier beschreiben. Vielleicht hilft es ja jemandem...
 

the other

Benutzer
Sehr erfahren
Mitglied seit
17. Okt 2015
Beiträge
2.100
Punkte für Reaktionen
541
Punkte
154
Moinsen,
die Lösung hier dann zu posten (und ich drücke dir die Daumen und bin gespannt) wäre ein feiner Zug und sollte eigentlich von allen so gemacht werden.
Wie gesagt, viel Erfolg, lass uns teilhaben und schickes Wochenende!
 

MaChS

Benutzer
Mitglied seit
23. Jul 2018
Beiträge
17
Punkte für Reaktionen
0
Punkte
1
Moinsen,
die Lösung hier dann zu posten (und ich drücke dir die Daumen und bin gespannt) wäre ein feiner Zug und sollte eigentlich von allen so gemacht werden.
Wie gesagt, viel Erfolg, lass uns teilhaben und schickes Wochenende!

So, ich habe nun die Lösung. Ein Fehler war, dass ich "proto tcp-server" verwendet habe und nicht "proto tcp6-server". So greife ich auf meinen NAS zu: Handy --<IPv4>--> VPS --<IPv6>--> NAS. Da der letzte Teil über IPv6 erfolgt, gehe ich davon aus, dass das der Grund ist. Ich bin aber kein Experte und lasse mich gerne korrigieren. :LOL: Einen anderen Fehler hatte ich auch noch gemacht, aber ich konnte nicht mehr nachvollziehen, welcher Schritt ihn behoben hat. Ich hatte ursprünglich dieses Tutorial benutzt: https://www.youtube.com/watch?v=ZcLhSfOU-r0 (Achtung: Ich habe einige Dinge angepasst).

Und so sehen meine Konfigurationsdateien nun in der kommentierten/korrigierten Version aus:

Code:
# Push routes to the client to allow it
# to reach other private subnets behind
# the server.  Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
push "route 192.168.0.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"

# "dev tun" will create a routed IP tunnel,
# "dev tap" will create an ethernet tunnel.
# Use "dev tap0" if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use "dev-node" for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
dev tun

# Network topology
# Should be subnet (addressing via IP)
# unless Windows clients v2.0.9 and lower have to
# be supported (then net30, i.e. a /30 per client)
# Defaults to net30 (not recommended)
topology subnet

# This will prevent OpenVPN from tweaking the buffer
# size between the server and the client. It will be
# determined by the OS. Windows users who connect to
# a Linux server will experience faster speeds.
push "sndbuf 0"
push "rcvbuf 0"
sndbuf 0
rcvbuf 0

management 127.0.0.1 1195

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info
server 10.8.0.0 255.255.255.0

# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key).  Each client
# and the server must have their own cert and
# key file.  The server and all clients will
# use the same ca file.
# Diffie hellman parameters.
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 # This file should be kept secret

# The maximum number of concurrently connected
# clients we want to allow.
max-clients 5

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-tun
persist-key

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 4

# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it.  Use one
# or the other (but not both).
log /var/log/openvpn.log

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 60 second time period.
keepalive 10 60

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf

# Output a short status file showing
# current connections, truncated
# and rewritten every 30 seconds.
status /tmp/ovpn_status_2_result 30
status-version 2

# TCP or UDP server?
proto tcp6-server

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 1194

# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
cipher AES-256-CBC # AES

auth SHA256

# For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
tls-auth /usr/syno/etc/packages/VPNCenter/VPNcerts/ta.key 0 # This file is secret

# Sets the minimum TLS version we will accept from the peer.
# If 'or-highest' is specified and version is not recognized,
# we will only accept the highest TLS version supported by
# the local SSL implementation.
tls-version-min 1.2 or-highest

remote-cert-tls client

Code:
dev tun
tls-client

remote meinedomain.de 1194

# The "float" tells OpenVPN to accept authenticated packets from any address,
# not only the address which was specified in the --remote option.
# This is useful when you are connecting to a peer which holds a dynamic address
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)
#float

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)
redirect-gateway def1

# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.
dhcp-option DNS 10.8.0.1

pull

# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto tcp-client

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
cipher AES-256-CBC

auth SHA256

auth-user-pass

# Verify server certificate by checking that the
# certificate has the correct key usage set.
# This is an important precaution to protect against
# a potential attack discussed here:
# http://openvpn.net/howto.html#mitm
remote-cert-tls server

key-direction 1

# Set log file verbosity.
verb 4

# Most clients don't need to bind to
# a specific local port number.
nobind

# Prevent DNS leakage to any DNS server other than the configured one
block-outside-dns

# Force Windows to prefer the configured DNS server over any other it
# may have received from DHCP
register-dns

# Sets the minimum TLS version we will accept from the peer.
# If 'or-highest' is specified and version is not recognized,
# we will only accept the highest TLS version supported by
# the local SSL implementation.
tls-version-min 1.2 or-highest

auth-nocache

# username.crt
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

# username.key
<key>
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
</key>

# CA.crt
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>

#ta.key
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>

Falls sich jemand die Konfiguration ansehen sollte und ihm Sicherheitslücken auffallen, bzw. ihm Verbesserungen einfallen, bitte Bescheid sagen. Ansonsten hoffe ich, dass das hier jemandem helfen wird und wünsche euch ebenfalls ein schönes Wochenende :)
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat