21
OpenVPN Client Fehlermeldungen
Hallo Zusammen,
wir nutzen seit kurzem einen neuen Router und den OpenVPN Client. Die VPN Verbindung klappt;
allerdings kommen folgende Meldungen mit denen ich nichts anfangen kann:
Wed Apr 18 16:21:56 2018 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Wed Apr 18 16:21:58 2018 RESOLVE: Cannot parse IP address: 192.168.089.1: (Der angegebene Host ist unbekannt. )
Wed Apr 18 16:22:23 2018 SIGTERM[hard,] received, process exiting
Der Router hängt über WAN an einer Fritzbox. Die Fritzbox ist aus dem Netz mit einer Domain (DDNS) erreichbar.
Über eine Portfreigabe wird die VPN Anfrage auf den Router weitergeleitet.
Hat jemand Erfahrung mit OpenVPN bzw. dem Client? Der Support vom Router Hersteller ist leider nicht gut...
Danke & Viele Grüße
wir nutzen seit kurzem einen neuen Router und den OpenVPN Client. Die VPN Verbindung klappt;
allerdings kommen folgende Meldungen mit denen ich nichts anfangen kann:
Wed Apr 18 16:21:56 2018 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Wed Apr 18 16:21:58 2018 RESOLVE: Cannot parse IP address: 192.168.089.1: (Der angegebene Host ist unbekannt. )
Wed Apr 18 16:22:23 2018 SIGTERM[hard,] received, process exiting
Der Router hängt über WAN an einer Fritzbox. Die Fritzbox ist aus dem Netz mit einer Domain (DDNS) erreichbar.
Über eine Portfreigabe wird die VPN Anfrage auf den Router weitergeleitet.
Hat jemand Erfahrung mit OpenVPN bzw. dem Client? Der Support vom Router Hersteller ist leider nicht gut...
Danke & Viele Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 371470
Url: https://administrator.de/forum/openvpn-client-fehlermeldungen-371470.html
Ausgedruckt am: 23.12.2024 um 12:12 Uhr
21 Kommentare
Neuester Kommentar
RESOLVE: Cannot parse IP address: 192.168.089.1: (Der angegebene Host ist unbekannt. )
Folgenden Eintragproto tcp6aus der Config rausnehmen dann verschwindet die Resolve-Meldung.
WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls
Deprecated ist nicht schlimm aber wenn möglich in der Config switchen zuremote-cert-tls <server>Gruß m.
Guten Morgen,
vielen Dank für die schnelle Antwort. Leider sind in der Config
beide Einträge nicht zu finden. Hier der Auszug der Datei:
remote vpn.xxxxxxxxxx.de 1194
float
nobind
proto udp
dev tap
sndbuf 0
rcvbuf 0
keepalive 15 60
comp-lzo adaptive
auth-user-pass
client
auth SHA1
cipher AES-256-CBC
ns-cert-type server
<ca>
oder muss das in den Router Einstellungen geändert werden?
VG
vielen Dank für die schnelle Antwort. Leider sind in der Config
beide Einträge nicht zu finden. Hier der Auszug der Datei:
remote vpn.xxxxxxxxxx.de 1194
float
nobind
proto udp
dev tap
- Windows needs the TAP-Win32 adapter name
- from the Network Connections panel
- if you have more than one. On XP SP2,
- you may need to disable the firewall
- for the TAP adapter.
sndbuf 0
rcvbuf 0
keepalive 15 60
comp-lzo adaptive
auth-user-pass
client
auth SHA1
cipher AES-256-CBC
ns-cert-type server
<ca>
oder muss das in den Router Einstellungen geändert werden?
VG
Was die erste Fehlermeldung anbetrifft benutzt du eine veraltete Kommando Syntax in deiner client.conf Datei.
Die solltest du editieren und das veraltete und nicht mehr gebräuchliche Kommando ns-cert-type server durch das richtige remote-cert-tls server ersetzen bzw. überschreiben.
Du kannst sehen das das veraltete Kommando oben in deiner geposteten Client Konfig enthalten ist !
Weitere Korrekturen zur Verbesserung:
float kann entfallen und kannst du löschen, denn das ist Default !
Die Send- und Receive Buffer auf 0 zu setzen ist fatal. Sowas sollte man niemals machen, denn damit deaktivierst du jedes Buffering am Client.
Auch diese beiden Kommandos solltest du deshalb besser entfernen oder mit # auskommentieren und mit den Default Buffern arbeiten !
Der Rest ist OK so.
Mit den Korrekturen verschwinden die Fehler sehr wahrscheinlich.
Die solltest du editieren und das veraltete und nicht mehr gebräuchliche Kommando ns-cert-type server durch das richtige remote-cert-tls server ersetzen bzw. überschreiben.
Du kannst sehen das das veraltete Kommando oben in deiner geposteten Client Konfig enthalten ist !
Weitere Korrekturen zur Verbesserung:
float kann entfallen und kannst du löschen, denn das ist Default !
Die Send- und Receive Buffer auf 0 zu setzen ist fatal. Sowas sollte man niemals machen, denn damit deaktivierst du jedes Buffering am Client.
Auch diese beiden Kommandos solltest du deshalb besser entfernen oder mit # auskommentieren und mit den Default Buffern arbeiten !
Der Rest ist OK so.
Mit den Korrekturen verschwinden die Fehler sehr wahrscheinlich.
Hallo,
danke für die Tips - die Buffer sind raus bzw. dann auf Default; float ist
raus und ich habe remote-cert-tls eingetragen. Das klappt auch soweit alles.
Nun ist nur noch der Resolve Fehler / Meldung vorhanden - einfach ignorieren?
Oder gibt es eine Lösung? Was bedeutet es überhaupt
?
LG
danke für die Tips - die Buffer sind raus bzw. dann auf Default; float ist
raus und ich habe remote-cert-tls eingetragen. Das klappt auch soweit alles.
Nun ist nur noch der Resolve Fehler / Meldung vorhanden - einfach ignorieren?
Oder gibt es eine Lösung? Was bedeutet es überhaupt
?LG
Er versucht irgendwas "aufzulösen" mit der IP 192.168.89.1 !
WAS ist das für eine IP Adresse ??
Ist die ggf. fälschlicherweise irgendwo als Gateway oder DNS Server konfiguriert ?
Möglich auch das er die Nomenklatur 192.168.089.1 nicht mag und lieber ein 192.168.89.1 !
Dazu müsstest du aber mal genau spezifizieren WO und WAS diese IP Adsresse ist bzw. wo das Netzwerk dazu liegt.
Ansonsten können wir auch nur im freien Fall dazu raten weil deine Angaben dazu mehr als oberflächlich sind...leider.
WAS ist das für eine IP Adresse ??
Ist die ggf. fälschlicherweise irgendwo als Gateway oder DNS Server konfiguriert ?
Möglich auch das er die Nomenklatur 192.168.089.1 nicht mag und lieber ein 192.168.89.1 !
Dazu müsstest du aber mal genau spezifizieren WO und WAS diese IP Adsresse ist bzw. wo das Netzwerk dazu liegt.
Ansonsten können wir auch nur im freien Fall dazu raten weil deine Angaben dazu mehr als oberflächlich sind...leider.
Hallo,
das ist die IP von dem Router der hinter der Fritzbox hängt.
Der Aufbau ist wie folgt: Client -> Fritzbox -> Router. Die Verbindung
geht von dem Client an eine DDNS Adresse zur Fritzbox, dort ist eine Portfreigabe auf den Router eingetragen.
Reicht das als Info?
das ist die IP von dem Router der hinter der Fritzbox hängt.
Der Aufbau ist wie folgt: Client -> Fritzbox -> Router. Die Verbindung
geht von dem Client an eine DDNS Adresse zur Fritzbox, dort ist eine Portfreigabe auf den Router eingetragen.
Reicht das als Info?
das ist die IP von dem Router der hinter der Fritzbox hängt.
OK, dann betreibst du den Client hinter einer Router Kaskade. Ist das richtig ?Oder ist das jetzt so gemeint:
Client===Internet===(WAN-FritzBox-LAN)---Koppelnetz---(VPN-Router)---lokales LAN
Was ist jetzt richtig ?? Ist leider etwas verwirrend, da deine Beschreibung nicht ganz eindeutig ist
Bin leider nicht so fit in dem Thema; aber für mich als Laie so:
Client===Internet===(WAN-FritzBox-LAN)---Koppelnetz?---(VPN-Router(über WAN an FritzBox)---lokales LAN
Client===Internet===(WAN-FritzBox-LAN)---Koppelnetz?---(VPN-Router(über WAN an FritzBox)---lokales LAN
OK, dann ist das inbound eine Router Kaskade !
Das erklärt dann auch den Fehler !!
Hier ist fälschlicherweise die DDNS Konfig am WAN Port des VPN Routers gemacht worden, der Router der also mit dem WAN Port an den LAN Port der davor liegenden FritzBox liegt und über das "Koppelnetz" mit ihr verbunden ist.
Dieses Netz hat die IP 192.168.89.0 /24 und der WAN Port des VPN Routers ist dann die 192.168.89.1
Das Fatale was jetzt bei der falschen DDNS Einrichtung passiert ist das der DDNS Client die WAN IP 192.168.89.1 meldet an den DDNS Dienst.
Der VPN Client versucht dann bei Eingabe des DDNS Hostnamen den aufzulösen scheitert aber logischerweise das 192.168er IP Adressen private RFC 1918 IPs sind die im Internet NICHT geroutet werden !
https://de.wikipedia.org/wiki/Private_IP-Adresse
Fazit:
DDNS falsch !
Der DDNS Client muss logischerweise auf der davor liegenden FritzBox gemacht werden, da genau DIESE ja die öffentliche IP Adresse ins Internet hält die der Client bzw. DDNS Dienst braucht als Ziel für den VPN Tunnel.
Weg also mit der DDNS Konfig auf dem hinter der FB liegenden Router und auf der FB selber installieren.
Dann kommt die richtige IP und der Fehler verschwindet.
Ist eigentlich auch klar wenn man nur ein klein wenig mal nachdenkt wie DDNS funktioniert !!!
Das erklärt dann auch den Fehler !!
Hier ist fälschlicherweise die DDNS Konfig am WAN Port des VPN Routers gemacht worden, der Router der also mit dem WAN Port an den LAN Port der davor liegenden FritzBox liegt und über das "Koppelnetz" mit ihr verbunden ist.
Dieses Netz hat die IP 192.168.89.0 /24 und der WAN Port des VPN Routers ist dann die 192.168.89.1
Das Fatale was jetzt bei der falschen DDNS Einrichtung passiert ist das der DDNS Client die WAN IP 192.168.89.1 meldet an den DDNS Dienst.
Der VPN Client versucht dann bei Eingabe des DDNS Hostnamen den aufzulösen scheitert aber logischerweise das 192.168er IP Adressen private RFC 1918 IPs sind die im Internet NICHT geroutet werden !
https://de.wikipedia.org/wiki/Private_IP-Adresse
Fazit:
DDNS falsch !
Der DDNS Client muss logischerweise auf der davor liegenden FritzBox gemacht werden, da genau DIESE ja die öffentliche IP Adresse ins Internet hält die der Client bzw. DDNS Dienst braucht als Ziel für den VPN Tunnel.
Weg also mit der DDNS Konfig auf dem hinter der FB liegenden Router und auf der FB selber installieren.
Dann kommt die richtige IP und der Fehler verschwindet.
Ist eigentlich auch klar wenn man nur ein klein wenig mal nachdenkt wie DDNS funktioniert !!!
Hallo aqui,
also DDNS ist schon an der Fritzbox eingerichtet; am Router nicht. An der Fritzbox dann via Portfreigabe zum Router.
Die IP's:
FritzBox 192.168.178.1
Von der FritzBox hat der Router die IP 192.168.178.148 erhalten.
Der Router selbst hat "im zweiten Netz" die IP 192.168.89.1.
Hoffe du verstehst was ich meine?!
also DDNS ist schon an der Fritzbox eingerichtet; am Router nicht. An der Fritzbox dann via Portfreigabe zum Router.
Die IP's:
FritzBox 192.168.178.1
Von der FritzBox hat der Router die IP 192.168.178.148 erhalten.
Der Router selbst hat "im zweiten Netz" die IP 192.168.89.1.
Hoffe du verstehst was ich meine?!
Hoffe du verstehst was ich meine?!
Ja.Laut deiner Beschreibung wäre das dann aber alles richtig !
Kann es sein das du in der OpenVPN Server Konfig (VPN Router) das Push Route Kommando falsch angelegt hast und dort statt eines IP Netzwerks (alle Hostbits auf 0) eine Hostadresse und zwar die des Routers eingegen hast.
Leider muss man hier mal wieder raten, da du keinerlei Infos zu deiner OVPN Server Konfig gepostet hast
Es müsste da sowas in der server.confstehen:
...
server 172.16.2.0 255.255.255.0
push "route 192.168.89.0 255.255.255.0"
...
Und du statt des 192.168.89.0 in der Konfig ein 192.168.89.1 dort eingegeben hast ?
Auch das würde den Fehler erklären.
Danke für deine Geduld! Hier der Auzug aus dem VPN Router (Asus RT-AC66U_B1) Menü:
In dem Log vom Router steht:
Apr 19 18:44:32 vpnserver1[1377]: 87.181.xx.xxx:65070 TLS: Initial packet from [AF_INET]87.181.xx.xxx:65070 (via [AF_INET]192.168.178.148%eth0), sid=1f5cbf92 5ace8df3
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 TLS: Username/Password authentication succeeded for username ‘chris’ [CN SET]
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 [chris] Peer Connection Initiated with [AF_INET]87.181.xx.xxx:65070 (via [AF_INET]192.168.178.148%eth0)
Apr 19 18:44:33 vpnserver1[1377]: chris/87.181.xx.xxx:65070 MULTI: no dynamic or static remote --ifconfig address is available for chris/87.181.xx.xxx:65070
Apr 19 18:44:35 vpnserver1[1377]: chris/87.181.xx.xxx:65070 PUSH: Received control message: 'PUSH_REQUEST'
Apr 19 18:44:35 vpnserver1[1377]: chris/87.181.xx.xxx:65070 send_push_reply(): safe_cap=940
Apr 19 18:44:35 vpnserver1[1377]: chris/87.181.xx.xxx:65070 SENT CONTROL [chris]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 192.168.089.1,route-gateway dhcp,ping 15,ping-restart 60' (status=1)
Apr 19 18:44:35 vpnserver1[1377]: chris/87.181.xx.xxx:65070 MULTI: Learn: 00:ff:23:ff:23:ac -> chris/87.181.xx.xxx:65070
Apr 19 18:44:35 dnsmasq-dhcp[1401]: Ignoring domain xxx.local for DHCP host name laptop
In dem Log vom Router steht:
Apr 19 18:44:32 vpnserver1[1377]: 87.181.xx.xxx:65070 TLS: Initial packet from [AF_INET]87.181.xx.xxx:65070 (via [AF_INET]192.168.178.148%eth0), sid=1f5cbf92 5ace8df3
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 TLS: Username/Password authentication succeeded for username ‘chris’ [CN SET]
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA
Apr 19 18:44:33 vpnserver1[1377]: 87.181.xx.xxx:65070 [chris] Peer Connection Initiated with [AF_INET]87.181.xx.xxx:65070 (via [AF_INET]192.168.178.148%eth0)
Apr 19 18:44:33 vpnserver1[1377]: chris/87.181.xx.xxx:65070 MULTI: no dynamic or static remote --ifconfig address is available for chris/87.181.xx.xxx:65070
Apr 19 18:44:35 vpnserver1[1377]: chris/87.181.xx.xxx:65070 PUSH: Received control message: 'PUSH_REQUEST'
Apr 19 18:44:35 vpnserver1[1377]: chris/87.181.xx.xxx:65070 send_push_reply(): safe_cap=940
Apr 19 18:44:35 vpnserver1[1377]: chris/87.181.xx.xxx:65070 SENT CONTROL [chris]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 192.168.089.1,route-gateway dhcp,ping 15,ping-restart 60' (status=1)
Apr 19 18:44:35 vpnserver1[1377]: chris/87.181.xx.xxx:65070 MULTI: Learn: 00:ff:23:ff:23:ac -> chris/87.181.xx.xxx:65070
Apr 19 18:44:35 dnsmasq-dhcp[1401]: Ignoring domain xxx.local for DHCP host name laptop
Schwierig zu beurteilen, da man die interne Server Konfig Datei nicht sehen kann und nur das GUI. Falls der Asus ggf. einen Shell Zugang hat mit SSH wäre das mal interessant die Datei zu sehen.
Aus den Log Daten geht hervor das das teil ein Gateway Redirect macht. Es macht also keinerlei Push Routing sondern verbiegt den gesamten Traffic in den VPN Tunnel.
Sehr bedenklich ist auch die Verwendung des tap interfaces, denn das implziert ein Bridging was dann im VPN gemacht wird.
OpenVPN selber rät dringenst davon ab und empfihlt immer ein Routing zu macxhen über das tun Interface.
Möglich das das mit der Fehlermeldung zusammenhängt, das müsste man aber mal im Vergleich sehen.
Bridging ist aus Performance Sicht immer das schlechteste was man machen kann.
Aus den Log Daten geht hervor das das teil ein Gateway Redirect macht. Es macht also keinerlei Push Routing sondern verbiegt den gesamten Traffic in den VPN Tunnel.
Sehr bedenklich ist auch die Verwendung des tap interfaces, denn das implziert ein Bridging was dann im VPN gemacht wird.
OpenVPN selber rät dringenst davon ab und empfihlt immer ein Routing zu macxhen über das tun Interface.
Möglich das das mit der Fehlermeldung zusammenhängt, das müsste man aber mal im Vergleich sehen.
Bridging ist aus Performance Sicht immer das schlechteste was man machen kann.
Das dachte ich mir schon; leider finde ich über die GUI nichts - werde mal den Support bzgl. SSH fragen ob es da eine Möglichkeit gibt. In der GUI kann ich auch auf tun umstellen. Allerdings klappt so der Verbindungsaufbau nicht mehr. Log vom Client sagt:
Fri Apr 20 10:11:01 2018 OpenVPN 2.4.5 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Mar 1 2018
Fri Apr 20 10:11:01 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Fri Apr 20 10:11:01 2018 library versions: OpenSSL 1.1.0f 25 May 2017, LZO 2.10
Enter Management Password:
Fri Apr 20 10:11:09 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]91.4.xxx.xx:1194
Fri Apr 20 10:11:09 2018 UDP link local: (not bound)
Fri Apr 20 10:11:09 2018 UDP link remote: [AF_INET]91.4.xxx.xx:1194
Fri Apr 20 10:11:09 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Apr 20 10:11:10 2018 [RT-AC66U_B1] Peer Connection Initiated with [AF_INET]91.4.xxx.xx:1194
Fri Apr 20 10:11:11 2018 RESOLVE: Cannot parse IP address: 192.168.089.1: (Der angegebene Host ist unbekannt. )
Fri Apr 20 10:11:11 2018 open_tun
Fri Apr 20 10:11:11 2018 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{23FF23AC-37DB-48E8-AFED-0625A8C7ADB4}.tap
Fri Apr 20 10:11:11 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {23FF23AC-37DB-48E8-AFED-0625A8C7ADB4} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Fri Apr 20 10:11:11 2018 ERROR: The TAP-Windows driver rejected a TAP_WIN_IOCTL_CONFIG_DHCP_SET_OPT DeviceIoControl call
Fri Apr 20 10:11:11 2018 Exiting due to fatal error
Fri Apr 20 10:11:01 2018 OpenVPN 2.4.5 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Mar 1 2018
Fri Apr 20 10:11:01 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Fri Apr 20 10:11:01 2018 library versions: OpenSSL 1.1.0f 25 May 2017, LZO 2.10
Enter Management Password:
Fri Apr 20 10:11:09 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]91.4.xxx.xx:1194
Fri Apr 20 10:11:09 2018 UDP link local: (not bound)
Fri Apr 20 10:11:09 2018 UDP link remote: [AF_INET]91.4.xxx.xx:1194
Fri Apr 20 10:11:09 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Apr 20 10:11:10 2018 [RT-AC66U_B1] Peer Connection Initiated with [AF_INET]91.4.xxx.xx:1194
Fri Apr 20 10:11:11 2018 RESOLVE: Cannot parse IP address: 192.168.089.1: (Der angegebene Host ist unbekannt. )
Fri Apr 20 10:11:11 2018 open_tun
Fri Apr 20 10:11:11 2018 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{23FF23AC-37DB-48E8-AFED-0625A8C7ADB4}.tap
Fri Apr 20 10:11:11 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {23FF23AC-37DB-48E8-AFED-0625A8C7ADB4} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Fri Apr 20 10:11:11 2018 ERROR: The TAP-Windows driver rejected a TAP_WIN_IOCTL_CONFIG_DHCP_SET_OPT DeviceIoControl call
Fri Apr 20 10:11:11 2018 Exiting due to fatal error
Ja, das liegt daran das dann das Windows Interface von der internen Firewall als Öffentlich deklariert wird weil die Autodetection wegen des fehlenden Gateways fehlschläg und dann die Windows lokale Firewall alle eingehenden Packete dort blockt.
Du musst also in den Windows Firewall Settings das Profil am virtuellen VPN Netzadapter auf Privat setzen, dann klappt es.
Auf dem Client zeigt dir dann ein route print bei aktivem VPN die Windows Routing Tabelle an und ob das netzwerk dann richtig geroutet wird.
Irgendwo im Setup muss da aber noch die .89.1 stehen, denn die taucht da schon wieder auf
Kann es sein das du in der Router Kaskade die IP Adressierung mit DHCP gemacht hast statt statisch ??
Du musst also in den Windows Firewall Settings das Profil am virtuellen VPN Netzadapter auf Privat setzen, dann klappt es.
Auf dem Client zeigt dir dann ein route print bei aktivem VPN die Windows Routing Tabelle an und ob das netzwerk dann richtig geroutet wird.
Irgendwo im Setup muss da aber noch die .89.1 stehen, denn die taucht da schon wieder auf
Kann es sein das du in der Router Kaskade die IP Adressierung mit DHCP gemacht hast statt statisch ??
Wo kann ich denn von Öffentlich auf Privat umschalten? Die Firewall ist nicht aktiv bzw. von Symantec Endpoint ... verwaltet
Also im Setup finde ich nichts und lt. ASUS Support kann man weder die Config sehen noch per SSH darauf zugreifen.
Der Router hat in der FritzBox eine feste IP und in den WAN Einstellungen des Routers ist auch diese IP fest eingetragen.
Also im Setup finde ich nichts und lt. ASUS Support kann man weder die Config sehen noch per SSH darauf zugreifen.
Der Router hat in der FritzBox eine feste IP und in den WAN Einstellungen des Routers ist auch diese IP fest eingetragen.
Das mit den statischen IPs ist richtig und korrekt so !
Sowas ist immer tödlich wenns um Security Anpassungen geht. Da musst du wohl mal einen Symantec Spezl fragen oder in deren Handbuch sehen. No clue...
https://www.heise.de/security/meldung/Asus-Router-koennen-beim-Vorbeisur ...
https://www.heise.de/newsticker/meldung/Asus-muss-20-Jahre-lang-seine-Ro ...
https://www.heise.de/security/meldung/Asus-Router-schutzlos-bei-Angriffe ...
und und und...
Asus Router sind da ja leider bekanntermaßen berühmt berüchtigt
Das einzige was da hilft ist die mit einer anständigen alternativen Firmware zu flashen wie DD-WRT z.B.: https://dd-wrt.com/site/index
Die Firewall ist nicht aktiv bzw. von Symantec Endpoint ... verwaltet
Uuuuhhh wie gruselig. Die Firewall mit einer Firewall ersetzt die sich gegenseitig bekriegen. Genau DAS wird vermutlich der Knackpunkt sein... Sowas ist immer tödlich wenns um Security Anpassungen geht. Da musst du wohl mal einen Symantec Spezl fragen oder in deren Handbuch sehen. No clue...
lt. ASUS Support kann man weder die Config sehen noch per SSH darauf zugreifen.
Wundert einen bei Weltfirma Asus auch nicht mehr groß:https://www.heise.de/security/meldung/Asus-Router-koennen-beim-Vorbeisur ...
https://www.heise.de/newsticker/meldung/Asus-muss-20-Jahre-lang-seine-Ro ...
https://www.heise.de/security/meldung/Asus-Router-schutzlos-bei-Angriffe ...
und und und...
Asus Router sind da ja leider bekanntermaßen berühmt berüchtigt
Das einzige was da hilft ist die mit einer anständigen alternativen Firmware zu flashen wie DD-WRT z.B.: https://dd-wrt.com/site/index
Das klingt ja prima - hast du einen Vorschlag für einen Router bis 300 Euro der was taugt? Brauche WLAN und VPN Server für max. 2 Clients.
Mikrotik 2011 mit WLAN
https://de.varia-store.com/produkt/31874-mikrotik-routerboard-rb2011uias ...
oder pfSense mit separatem WLAN AP:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
https://de.varia-store.com/produkt/10133-mikrotik-cap-lite-mit-ar9533-65 ...
Gebrauchten Cisco 886va
https://www.ebay.de/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw ...
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Oder ne einfache FritzBox.
Es gibt viele Möglichkeiten, da deine Anforderung relativ gering sind...
MT und pfSense haben den Vorteil das sie auch OpenVPN und andere VPN Protokolle supporten.
Die anderen können nur IPsec oder L2TP. PPTP macht ja kaum einer mehr.
https://de.varia-store.com/produkt/31874-mikrotik-routerboard-rb2011uias ...
oder pfSense mit separatem WLAN AP:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
https://de.varia-store.com/produkt/10133-mikrotik-cap-lite-mit-ar9533-65 ...
Gebrauchten Cisco 886va
https://www.ebay.de/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw ...
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Oder ne einfache FritzBox.
Es gibt viele Möglichkeiten, da deine Anforderung relativ gering sind...
MT und pfSense haben den Vorteil das sie auch OpenVPN und andere VPN Protokolle supporten.
Die anderen können nur IPsec oder L2TP. PPTP macht ja kaum einer mehr.
Danke - werde ich mir mal in Ruhe anschauen nächste Woche. Eine FritzBox ist ja vorhanden - allerdings ist die VPN Verbindung sehr langsam. Ich muss auf eine Software im entfernten Netz zugreifen - das geht zwar mit der FritzBox, aber sehr langsam. Trotz der Fehler geht es mit dem ASUS jetzt schon bedeutend schneller.
Dann lass es doch so und ignoriere den Fehler einfach
Bridging ist aber immer ein Problem, denn damit belastest du den VPN Tunnel mit dem gesamten Broad- und Multicast Traffic aus dem Netz. Schwachbrüstige Consumer Router legen sich dann schon mal gerne die Karten.
Deshalb sollte man immer routen wenn nur irgend möglich im VPN Umfeld.
Bridging ist aber immer ein Problem, denn damit belastest du den VPN Tunnel mit dem gesamten Broad- und Multicast Traffic aus dem Netz. Schwachbrüstige Consumer Router legen sich dann schon mal gerne die Karten.
Deshalb sollte man immer routen wenn nur irgend möglich im VPN Umfeld.
