Hallo!
Auf Anraten von PeterPawn werde ich veruschen mein Anliegen hier nochmal ausführlich und strukturiert darzulegen.
Ich möchte auf einer FritzBox 7560 einen OpenVPN Server einrichten.
Diese Box ist im Netzwerk aber nicht Modem, Router oder DHCP, sondern nur Switch/WLAN-AP.
Diese Box (192.168.172.2) hängt über LAN 1 am Router, einer FB 7362SL (192.168.172.1).
Hier ist die Konfiguration des Servers:
Hier noch ein Screenshot von der Konfiguration, anscheinend ist nicht alles ausschließlich in openvpn.conf hinterlegt:
Der primäre Klient ist ein Windows 10 Laptop hinter einer Unitymedia Kabel FritzBox, auf die ich weiter keinen Einfluss habe. Das Netz hier wird aufgespannt über 192.168.178.0.
Es sollte also "eigentlich" keine Subnetzkonflikte geben.
Dessen opvn-Konfiguration sieht so aus:
Die Keys und Zertifikate habe ich direkt mit in die *.ovpn gepackt.
Bezüglich des geänderten Standardportes, den habe ich im Router auch so hinterlegt:
Ohnehin scheint bis hier hin, inklusive des aufsetzens der Keys und Zertifikate alles gut gelaufen zu sein, hier die Log beim Einloggen:
Alles was die OpenVPN Gui rot markiert habe ich versucht auch hier rot zu markieren, aber ich befürchte die Code Klammern werden das nicht mitnehmen. Persönliches wurde gexxxt.
Nun scheint aber erstmal alles zu funktioinieren. Im Zielnetzwerk kann ich interne HTTP-Server aufrufen und auch Samba-Shares funktionieren, Netzlaufwerke verbinden sich automatisch wieder, sogar die Namensauflösung funktioniert. Vorwärts wie Rückwärts.
Versuche ich eine RemoteDesktop Verbindung zu einem Windows 10 Computer aufzubauen, der direkt am LAN 2 der 7560 hängt, funktioniert zwar die Passwortabfrage, lokale Sitzungen oder weitere Remotesitzungen werden auch geschlossen, doch das Bild bleibt schwarz und das RDP Fenster wird nach einigen Sekunden geschlossen mit dem Verweis darauf das entweder die Netzwerkkonektivität zu schlecht sei, oder wahlweise (ca 30% zu 69%) das es einen internen Fehler gegeben habe. Die nachfolgende angebotene Windowshilfe ist beides mal die gleiche und geradeheraus nutzlos. Ganz selten funktioniert die Verbindung für wenige Minuten/Sekunden.
Soweit ich das mit verbleibenden Android-Remote Mitteln beurteilen kann verhält sich das ganze in die andere Richtung genau so.
Im selben Netzwerk harmonieren die beiden Maschinen wunderbar, die letzen drei Monate und auch Montag noch. Und auch heute brachte ein "sfc /scannow" keine Integritätsverletzungen zutage.
Weitere Anomalien, versuchtes Troubleshooting:
- Die "DHCP-Range für Clients" ignoriert der Server geflissentlich. Wahrscheinlich weil die Box selbst kein DHCP ist und OpenVPN diese Art der Selbstverwaltung in diesem Modus nicht mitbringt. Wenn ich die erweiterte Clientkonfiguration aktiviere funktioniert es.
-Egal ob ich die erweiterte Konfiguration benutze oder nicht, das "gebridgte", remote Gerät taucht in der Netzwerktabelle des Routers immer zweimal auf. Einmal unter der MAC-Adresse meiner echten Netzwerkkarte (Realtek Family Gigabit) und einmal unter der des virtuellen "TAP-Windows Adapter V9".
-Im Status meines "TAP-Windows Adapter V9" steht als DHCP 192.168.172.0. Müsste es nicht 192.168.172.1 sein? So war es bei zumindest bisher bei allen anderen Netzwerkkarten, der DHCP zeigte direkt auf den Router.
-Einige allgemeinere OpenVPN Threads und ein Schubser von PeterPawn haben schon darauf hingewiesen dass es eventuell die MTU sein kann. Deswegen habe ich die maximale MTU an beiden Anschlüssen überprüft, und obgleich vollkommen unterschiedlich (Kabel vs DSL) habe ich beide male 1472 als maximale Paketgröße raus.
Überprüft wie folgt:
1473 geht schon nicht mehr durch.
1500 ist ja die Standardeinstellung bei OpenVPN.
Nun habe ich in der der ServerGUI die MTU unter den "Experteneinstellungen" bereits einmal auf 1472 gestellt. Das hat aber funktioniell keinen Unterschied gemacht.
Muss man da wie bei damals nicht zu erreichenden Webseiten noch einen Overhead abziehen für die Zahl die man tatsächlich einträgt, muss ich die Einstellungen zusätzlich beim Klienten (OpenVPN config, Netzwerktreiber, Windows generell) ändern?
-Möchte ich zum Testen UDP verwenden bekomme ich es auf Teufel komm raus nicht ans laufen.
Das ist zunächst alles was mir einfällt vielleicht.
Hierran arbeite ich noch. "var/log/openvpn.log" scheint relativ nutzlos zu sein und im OpenVPN Anteil der Syslog sieht alles hervorragend aus.
Wenn ich an noch mehr Verbose komme kommt es in den Edit, aber ansonsten würde ich weiter über jeden Input, auch wie ich mehr Verbose liefern kann, freuen!
Danke im Vorraus!
Auf Anraten von PeterPawn werde ich veruschen mein Anliegen hier nochmal ausführlich und strukturiert darzulegen.
Ich möchte auf einer FritzBox 7560 einen OpenVPN Server einrichten.
Diese Box ist im Netzwerk aber nicht Modem, Router oder DHCP, sondern nur Switch/WLAN-AP.
Diese Box (192.168.172.2) hängt über LAN 1 am Router, einer FB 7362SL (192.168.172.1).
Hier ist die Konfiguration des Servers:
Code:
root@FritzBoxXXX:/var/mod/etc# cat openvpn.conf
# OpenVPN 2.4.6 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Jan 13 2019
# library versions: OpenSSL 1.0.2q 20 Nov 2018, LZO 2.10
# Config date: Wed Mar 20 19:34:28 CET 2019
proto tcp6-server
dev tap0
#Helperline for rc.openvpn to add tap0 to lan bridge and use LAN IP
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
tls-auth /tmp/flash/openvpn/static.key 0
port 11194
push "route-gateway 192.168.172.2"
push "route 192.168.172.1 255.255.255.0"
max-clients 15
mode server
ifconfig-pool 192.168.172.240 192.168.172.254
push "route 192.168.172.0 255.255.255.0"
client-config-dir clients_openvpn
client-to-client
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
comp-lzo
float
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-keyDer primäre Klient ist ein Windows 10 Laptop hinter einer Unitymedia Kabel FritzBox, auf die ich weiter keinen Einfluss habe. Das Netz hier wird aufgespannt über 192.168.178.0.
Es sollte also "eigentlich" keine Subnetzkonflikte geben.
Dessen opvn-Konfiguration sieht so aus:
Code:
tls-client
dev tap
proto tcp-client
remote xxx.xxx 11194
nobind
pull
remote-cert-tls server
auth SHA1
cipher AES-256-CBC
verb 3
comp-lzo
persist-tun
persist-key
<key>Die Keys und Zertifikate habe ich direkt mit in die *.ovpn gepackt.
Bezüglich des geänderten Standardportes, den habe ich im Router auch so hinterlegt:
Ohnehin scheint bis hier hin, inklusive des aufsetzens der Keys und Zertifikate alles gut gelaufen zu sein, hier die Log beim Einloggen:
Code:
Wed Mar 20 19:56:10 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019
Wed Mar 20 19:56:10 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Mar 20 19:56:10 2019 library versions: OpenSSL 1.1.0j 20 Nov 2018, LZO 2.10
Wed Mar 20 19:56:10 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Mar 20 19:56:10 2019 Need hold release from management interface, waiting...
Wed Mar 20 19:56:11 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Mar 20 19:56:11 2019 MANAGEMENT: CMD 'state on'
Wed Mar 20 19:56:11 2019 MANAGEMENT: CMD 'log all on'
Wed Mar 20 19:56:11 2019 MANAGEMENT: CMD 'echo all on'
Wed Mar 20 19:56:11 2019 MANAGEMENT: CMD 'bytecount 5'
Wed Mar 20 19:56:11 2019 MANAGEMENT: CMD 'hold off'
Wed Mar 20 19:56:11 2019 MANAGEMENT: CMD 'hold release'
Wed Mar 20 19:56:11 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 20 19:56:11 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 20 19:56:11 2019 MANAGEMENT: >STATE:1553108171,RESOLVE,,,,,,
Wed Mar 20 19:56:11 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:11194
Wed Mar 20 19:56:11 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Mar 20 19:56:11 2019 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.xxx:11194 [nonblock]
Wed Mar 20 19:56:11 2019 MANAGEMENT: >STATE:1553108171,TCP_CONNECT,,,,,,
Wed Mar 20 19:56:12 2019 TCP connection established with [AF_INET]xxx.xxx.xxx.xxx:11194
Wed Mar 20 19:56:12 2019 TCP_CLIENT link local: (not bound)
Wed Mar 20 19:56:12 2019 TCP_CLIENT link remote: [AF_INET]xxx.xxx.xxx.xxx:11194
Wed Mar 20 19:56:12 2019 MANAGEMENT: >STATE:1553108172,WAIT,,,,,,
Wed Mar 20 19:56:12 2019 MANAGEMENT: >STATE:1553108172,AUTH,,,,,,
Wed Mar 20 19:56:12 2019 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:11194, sid=d58485ae 5e371b2e
Wed Mar 20 19:56:13 2019 VERIFY OK: depth=x, C=x, ST=x, L=x, O=x, OU=x, CN=x, name=x, emailAddress=x
Wed Mar 20 19:56:13 2019 VERIFY KU OK
Wed Mar 20 19:56:13 2019 Validating certificate extended key usage
Wed Mar 20 19:56:13 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Mar 20 19:56:13 2019 VERIFY EKU OK
Wed Mar 20 19:56:13 2019 VERIFY OK: depth=x, C=x, ST=x, L=x, O=x, OU=x, CN=x, name=x, emailAddress=x
Wed Mar 20 19:56:14 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Wed Mar 20 19:56:14 2019 [FritzBoxxxx] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:11194
Wed Mar 20 19:56:15 2019 MANAGEMENT: >STATE:1553108175,GET_CONFIG,,,,,,
Wed Mar 20 19:56:15 2019 SENT CONTROL [FritzBoxxxx]: 'PUSH_REQUEST' (status=1)
Wed Mar 20 19:56:15 2019 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.172.2,route 192.168.172.1 255.255.255.0,route 192.168.172.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 192.168.172.241 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Wed Mar 20 19:56:15 2019 OPTIONS IMPORT: timers and/or timeouts modified
Wed Mar 20 19:56:15 2019 OPTIONS IMPORT: --ifconfig/up options modified
Wed Mar 20 19:56:15 2019 OPTIONS IMPORT: route options modified
Wed Mar 20 19:56:15 2019 OPTIONS IMPORT: route-related options modified
Wed Mar 20 19:56:15 2019 OPTIONS IMPORT: peer-id set
Wed Mar 20 19:56:15 2019 OPTIONS IMPORT: adjusting link_mtu to 1659
Wed Mar 20 19:56:15 2019 OPTIONS IMPORT: data channel crypto options modified
Wed Mar 20 19:56:15 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Mar 20 19:56:15 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Mar 20 19:56:15 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Mar 20 19:56:15 2019 interactive service msg_channel=0
Wed Mar 20 19:56:15 2019 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 I=15 HWADDR=6c:c2:17:5f:86:a9
Wed Mar 20 19:56:15 2019 open_tun
Wed Mar 20 19:56:15 2019 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{08FA8B8C-0353-474D-B8BA-BE0663E97AB8}.tap
Wed Mar 20 19:56:15 2019 TAP-Windows Driver Version 9.21
Wed Mar 20 19:56:15 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.172.241/255.255.255.0 on interface {08FA8B8C-0353-474D-B8BA-BE0663E97AB8} [DHCP-serv: 192.168.172.0, lease-time: 31536000]
Wed Mar 20 19:56:15 2019 NOTE: FlushIpNetTable failed on interface [5] {08FA8B8C-0353-474D-B8BA-BE0663E97AB8} (status=5) : Zugriff verweigert
Wed Mar 20 19:56:15 2019 MANAGEMENT: >STATE:1553108175,ASSIGN_IP,,192.168.172.241,,,,
Wed Mar 20 19:56:20 2019 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Wed Mar 20 19:56:20 2019 MANAGEMENT: >STATE:1553108180,ADD_ROUTES,,,,,,
Wed Mar 20 19:56:20 2019 C:\WINDOWS\system32\route.exe ADD 192.168.172.1 MASK 255.255.255.0 192.168.172.2
Wed Mar 20 19:56:20 2019 Warning: address 192.168.172.1 is not a network address in relation to netmask 255.255.255.0
Wed Mar 20 19:56:20 2019 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=5]
Wed Mar 20 19:56:20 2019 Route addition via IPAPI failed [adaptive]
Wed Mar 20 19:56:20 2019 Route addition fallback to route.exe
Wed Mar 20 19:56:20 2019 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Wed Mar 20 19:56:20 2019 ERROR: Windows route add command failed [adaptive]: returned error code 1
Wed Mar 20 19:56:20 2019 C:\WINDOWS\system32\route.exe ADD 192.168.172.0 MASK 255.255.255.0 192.168.172.2
Wed Mar 20 19:56:20 2019 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=5]
Wed Mar 20 19:56:20 2019 Route addition via IPAPI failed [adaptive]
Wed Mar 20 19:56:20 2019 Route addition fallback to route.exe
Wed Mar 20 19:56:20 2019 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Wed Mar 20 19:56:20 2019 ERROR: Windows route add command failed [adaptive]: returned error code 1
Wed Mar 20 19:56:20 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Mar 20 19:56:20 2019 Initialization Sequence Completed
Wed Mar 20 19:56:20 2019 MANAGEMENT: >STATE:1553108180,CONNECTED,SUCCESS,192.168.172.241,xxx.xxx.xxx.xxx,11194,192.168.178.65,58876Nun scheint aber erstmal alles zu funktioinieren. Im Zielnetzwerk kann ich interne HTTP-Server aufrufen und auch Samba-Shares funktionieren, Netzlaufwerke verbinden sich automatisch wieder, sogar die Namensauflösung funktioniert. Vorwärts wie Rückwärts.
Versuche ich eine RemoteDesktop Verbindung zu einem Windows 10 Computer aufzubauen, der direkt am LAN 2 der 7560 hängt, funktioniert zwar die Passwortabfrage, lokale Sitzungen oder weitere Remotesitzungen werden auch geschlossen, doch das Bild bleibt schwarz und das RDP Fenster wird nach einigen Sekunden geschlossen mit dem Verweis darauf das entweder die Netzwerkkonektivität zu schlecht sei, oder wahlweise (ca 30% zu 69%) das es einen internen Fehler gegeben habe. Die nachfolgende angebotene Windowshilfe ist beides mal die gleiche und geradeheraus nutzlos. Ganz selten funktioniert die Verbindung für wenige Minuten/Sekunden.
Soweit ich das mit verbleibenden Android-Remote Mitteln beurteilen kann verhält sich das ganze in die andere Richtung genau so.
Im selben Netzwerk harmonieren die beiden Maschinen wunderbar, die letzen drei Monate und auch Montag noch. Und auch heute brachte ein "sfc /scannow" keine Integritätsverletzungen zutage.
Weitere Anomalien, versuchtes Troubleshooting:
- Die "DHCP-Range für Clients" ignoriert der Server geflissentlich. Wahrscheinlich weil die Box selbst kein DHCP ist und OpenVPN diese Art der Selbstverwaltung in diesem Modus nicht mitbringt. Wenn ich die erweiterte Clientkonfiguration aktiviere funktioniert es.
-Egal ob ich die erweiterte Konfiguration benutze oder nicht, das "gebridgte", remote Gerät taucht in der Netzwerktabelle des Routers immer zweimal auf. Einmal unter der MAC-Adresse meiner echten Netzwerkkarte (Realtek Family Gigabit) und einmal unter der des virtuellen "TAP-Windows Adapter V9".
-Im Status meines "TAP-Windows Adapter V9" steht als DHCP 192.168.172.0. Müsste es nicht 192.168.172.1 sein? So war es bei zumindest bisher bei allen anderen Netzwerkkarten, der DHCP zeigte direkt auf den Router.
-Einige allgemeinere OpenVPN Threads und ein Schubser von PeterPawn haben schon darauf hingewiesen dass es eventuell die MTU sein kann. Deswegen habe ich die maximale MTU an beiden Anschlüssen überprüft, und obgleich vollkommen unterschiedlich (Kabel vs DSL) habe ich beide male 1472 als maximale Paketgröße raus.
Überprüft wie folgt:
Code:
C:\Users\xxx>ping -n 1 -l 1472 -f google.com -t1500 ist ja die Standardeinstellung bei OpenVPN.
Nun habe ich in der der ServerGUI die MTU unter den "Experteneinstellungen" bereits einmal auf 1472 gestellt. Das hat aber funktioniell keinen Unterschied gemacht.
Muss man da wie bei damals nicht zu erreichenden Webseiten noch einen Overhead abziehen für die Zahl die man tatsächlich einträgt, muss ich die Einstellungen zusätzlich beim Klienten (OpenVPN config, Netzwerktreiber, Windows generell) ändern?
-Möchte ich zum Testen UDP verwenden bekomme ich es auf Teufel komm raus nicht ans laufen.
Das ist zunächst alles was mir einfällt vielleicht.
Hierran arbeite ich noch. "var/log/openvpn.log" scheint relativ nutzlos zu sein und im OpenVPN Anteil der Syslog sieht alles hervorragend aus.
Wenn ich an noch mehr Verbose komme kommt es in den Edit, aber ansonsten würde ich weiter über jeden Input, auch wie ich mehr Verbose liefern kann, freuen!
Danke im Vorraus!
