Linksys WRT32X - OpenWRT - DEVICE_CLAIM_FAILED

Adebar

New Member
Moin Moin!

Ich bin neu und wollte heute auf meinem Router OpenVPN einrichten und bin nach folgender Anleitung vorgegangen.
Sobald ich das VPN aktiviere startet es auch direkt, startet dann aber direkt neu - in einer Endlosscheife.

Gehe ich auf Netzwerk -> Interfaces bekomme ich bei dem neu erstellten Interface folgende Fehlermeldung angezeigt:
Protocol: Unmanaged
RX: 0 B (0 Pkts.)
TX: 0 B (0 Pkts.)
Error: Unknown error (DEVICE_CLAIM_FAILED)
Schaue ich in das Systemlog finde ich dann folgende Meldungen, ebenfalls in einer Endlosscheife:

Thu Jan 2 21:29:08 2020 daemon.warn openvpn(PP_Amsterdam)[7189]: Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Interface 'PP_VPN' is enabled
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Network device 'tun0' link is up
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Interface 'PP_VPN' has link connectivity
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Interface 'PP_VPN' is setting up now
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Interface 'PP_VPN' is now up
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Network device 'tun0' link is down
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Interface 'PP_VPN' has link connectivity loss
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Interface 'PP_VPN' is now down
Thu Jan 2 21:29:10 2020 daemon.notice netifd: Interface 'PP_VPN' is disabled
Thu Jan 2 21:29:10 2020 user.notice firewall: Reloading firewall due to ifup of PP_VPN (tun0)
Das openvpn.log habe ich natürlich auch:

Thu Jan 2 21:39:30 2020 us=162006 OpenVPN 2.4.8 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Thu Jan 2 21:39:30 2020 us=162132 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Thu Jan 2 21:39:30 2020 us=162932 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Jan 2 21:39:30 2020 us=223162 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Thu Jan 2 21:39:30 2020 us=223258 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Jan 2 21:39:30 2020 us=223311 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Thu Jan 2 21:39:30 2020 us=223363 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Jan 2 21:39:30 2020 us=223567 Control Channel MTU parms [ L:1653 D:1156 EF:94 EB:0 ET:0 EL:3 ]
Thu Jan 2 21:39:30 2020 us=223663 Data Channel MTU parms [ L:1653 D:1450 EF:121 EB:411 ET:32 EL:3 ]
Thu Jan 2 21:39:30 2020 us=223758 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1633,tun-mtu 1532,proto UDPv4,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Thu Jan 2 21:39:30 2020 us=223805 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1633,tun-mtu 1532,proto UDPv4,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Thu Jan 2 21:39:30 2020 us=223859 TCP/UDP: Preserving recently used remote address: [AF_INET]95.211.95.232:443
Thu Jan 2 21:39:30 2020 us=223932 Socket Buffers: R=[163840->163840] S=[163840->163840]
Thu Jan 2 21:39:30 2020 us=223978 UDP link local: (not bound)
Thu Jan 2 21:39:30 2020 us=224027 UDP link remote: [AF_INET]95.211.95.232:443
Thu Jan 2 21:39:30 2020 us=254754 TLS: Initial packet from [AF_INET]95.211.95.232:443, sid=ab8e7009 d1ba88e0
Thu Jan 2 21:39:30 2020 us=255832 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Jan 2 21:39:30 2020 us=383608 VERIFY OK: depth=1, C=CH, ST=Zug, L=Zug, O=Perfect Privacy, CN=Perfect Privacy, emailAddress=admin@perfect-privacy.com
Thu Jan 2 21:39:30 2020 us=385358 VERIFY KU OK
Thu Jan 2 21:39:30 2020 us=385428 Validating certificate extended key usage
Thu Jan 2 21:39:30 2020 us=385477 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Jan 2 21:39:30 2020 us=385520 VERIFY EKU OK
Thu Jan 2 21:39:30 2020 us=385561 VERIFY OK: depth=0, C=CH, ST=Zug, O=Perfect Privacy, CN=Server_amsterdam.perfect-privacy.com, emailAddress=admin@perfect-privacy.com
Thu Jan 2 21:39:31 2020 us=135009 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Thu Jan 2 21:39:31 2020 us=135145 [Server_amsterdam.perfect-privacy.com] Peer Connection Initiated with [AF_INET]95.211.95.232:443
Thu Jan 2 21:39:32 2020 us=175320 SENT CONTROL [Server_amsterdam.perfect-privacy.com]: 'PUSH_REQUEST' (status=1)
Thu Jan 2 21:39:32 2020 us=204962 PUSH: Received control message: 'PUSH_REPLY,topology subnet,redirect-gateway def1,sndbuf 131072,rcvbuf 131072,route-gateway 10.0.48.1,redirect-gateway ipv6,route-ipv6 2000::/3,ping 10,ping-restart 60,dhcp-option DNS 95.211.199.144,dhcp-option DNS 185.17.184.3,ifconfig-ipv6 fdbf:1d37:bbe0:0:3::20/112 fdbf:1d37:bbe0:0:3::1,ifconfig 10.0.48.32 255.255.255.0,peer-id 0'
Thu Jan 2 21:39:32 2020 us=205224 OPTIONS IMPORT: timers and/or timeouts modified
Thu Jan 2 21:39:32 2020 us=205283 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Thu Jan 2 21:39:32 2020 us=205334 Socket Buffers: R=[163840->262144] S=[163840->262144]
Thu Jan 2 21:39:32 2020 us=205377 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jan 2 21:39:32 2020 us=205417 OPTIONS IMPORT: route options modified
Thu Jan 2 21:39:32 2020 us=205457 OPTIONS IMPORT: route-related options modified
Thu Jan 2 21:39:32 2020 us=205497 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Jan 2 21:39:32 2020 us=205537 OPTIONS IMPORT: peer-id set
Thu Jan 2 21:39:32 2020 us=205588 OPTIONS IMPORT: adjusting link_mtu to 1656
Thu Jan 2 21:39:32 2020 us=205651 Data Channel MTU parms [ L:1636 D:1450 EF:104 EB:411 ET:32 EL:3 ]
Thu Jan 2 21:39:32 2020 us=205971 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Jan 2 21:39:32 2020 us=206045 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Jan 2 21:39:32 2020 us=206115 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Jan 2 21:39:32 2020 us=206172 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Jan 2 21:39:32 2020 us=206491 GDG6: remote_host_ipv6=n/a
Thu Jan 2 21:39:32 2020 us=206597 GDG6: NLMSG_ERROR: error Permission denied

Thu Jan 2 21:39:32 2020 us=208339 TUN/TAP device tun0 opened
Thu Jan 2 21:39:32 2020 us=208574 TUN/TAP TX queue length set to 100
Thu Jan 2 21:39:32 2020 us=208676 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Thu Jan 2 21:39:32 2020 us=208769 /sbin/ifconfig tun0 10.0.48.32 netmask 255.255.255.0 mtu 1500 broadcast 10.0.48.255
Thu Jan 2 21:39:32 2020 us=222398 /sbin/ifconfig tun0 add fdbf:1d37:bbe0:0:3::20/112
Thu Jan 2 21:39:32 2020 us=227252 up.sh tun0 1500 1636 10.0.48.32 255.255.255.0 init
Thu Jan 2 21:39:32 2020 us=232514 WARNING: Failed running command (--up/--down): could not execute external program
Thu Jan 2 21:39:32 2020 us=232638 Exiting due to fatal error
Ich habe auch verschiedene VPN Konfigurationen erstellt und durch probiert, leider bekomme ich aber immer die gleichen Fehler bzw. Meldungen.
Die Rechte der Skripte geprüft.
Testweise volle Pfadangaben in den Skripten genutzt.
Ich benutze das aktuelle OpenWRT Release von Davidc502.

Ich komme leider nicht weiter und hoffe dass ihr mir helfen könnt, vielen Dank. :)
Beste Grüße
Adebar
 

Gerd

Junior Member
Hi.

Ich habe mehrmals die Anleitung durchprobiert und es funktionierte bei mir. Die VPN Konfiguration war bei mir nur anders..

Nimm mal testweise folgende Konfiguration:
  • macOS
  • OpenVPN
  • 2.4
  • UDP
  • AES-256-CBC
  • TLS-auth
  • Separat
  • zip
und ändere die Konfiguration wie hier:

Code:
auth-user-pass userpass.txt
client
dev tun0
hand-window 120
inactive 604800
mute-replay-warnings
nobind
persist-key
persist-remote-ip
persist-tun
ping 5
ping-restart 120
redirect-gateway def1
remote-random
reneg-sec 3600
resolv-retry 60
route-delay 2
route-method exe
script-security 2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
tls-timeout 5
verb 4

tun-ipv6
tun-mtu  1500
proto udp
fragment 1300
mssfix
comp-lzo

remote 85.17.28.145 148
remote 85.17.28.145 149
remote 85.17.28.145 150
remote 85.17.28.145 151
remote 85.17.28.145 1148
remote 85.17.28.145 1149
remote 85.17.28.145 1150
remote 85.17.28.145 1151

cipher AES-256-CBC
auth SHA512
ignore-unknown-option ncp-disable
ncp-disable
remote-cert-tls server
key-direction 1

ca ca.crt
cert Amsterdam1_cl.crt
key Amsterdam1_cl.key
tls-auth Amsterdam1_ta.key
log /var/log/openvpn1.log
log-append /var/log/openvpn1.log
up up.sh
down down.sh
Das einzige was sich ändert ist "dev tun0" und die Hinweise zu den Zertifikaten.

Edit: Lass auch nur eine Remote IP in der Konfiguration, wie von mir angegeben.
 
Last edited:

Adebar

New Member
Hey Gerd,

danke für deine Antwort!
Ich hab das entsprechend umgesetzt allerdings ist der Fehler der gleiche geblieben, auch in den Logs hat sich praktisch nichts verändert.
Um auszuschließen dass ich meinen Router verbastelt habe, hab ich ihn mal vollständig zurückgesetzt und nur das allernötigste konfiguriert. Auch da bleibt der Fehler absolut identisch.

Was mir aufgefallen ist, beim Konfigurieren der DNS Server habe ich nicht die Auswahl "Use DNS servers advertised by peer" auszuhaken. Ist das bei dir auch so?

Sollte ich mal ein anderes OpenWRT Release versuchen? Hast du da evtl. eine Empfehlung?

Vielen Dank und Grüße
Adebar
 

Gerd

Junior Member
Was mir aufgefallen ist, beim Konfigurieren der DNS Server habe ich nicht die Auswahl "Use DNS servers advertised by peer" auszuhaken. Ist das bei dir auch so?
Da habe ich das Häkchen entfernt und DNS Server eingetragen.

Sollte ich mal ein anderes OpenWRT Release versuchen? Hast du da evtl. eine Empfehlung?
Ja. Die Anleitung wurde mit OpenWRT 18.06.02 getestet. Versuch mal OpenWRT 18.06.05, um den Fehler auszuschließen.

Edit: Wie ist die korrekte Bezeichnung von deinem Router?
 

Adebar

New Member
Merkwürdig, denn dieses Häkchen hab ich bei mir gar nicht.

OpennWRT 18.06.05 werde ich mir jetzt noch mal direkt runterladen und testen, ich melde mich danach nochmal.

Modell ist der Linksys WRT32X.
 

Adebar

New Member
Das gleiche Image hab ich zum glück gerade eben auch genutzt, leider wieder ohne erfolg.
Dass ich "Use DNS servers advertised by peer" nicht gesehen habe, lag daran dass ich auf dem Interface kein DHCP Client an hatte sondern über Statisch ging. Das hab ich testhalber auch mal umgebaut... aber hat auch nichts gebracht.

Ich hab nochmal die Logs mit angehangen, allerdings weiß ich nicht mehr weiter. :(

Fri Jan 3 18:22:43 2020 daemon.notice netifd: Interface 'PP_VPN' is enabled
Fri Jan 3 18:22:43 2020 daemon.notice netifd: Network device 'tun0' link is up
Fri Jan 3 18:22:43 2020 daemon.notice netifd: Interface 'PP_VPN' has link connectivity
Fri Jan 3 18:22:43 2020 daemon.notice netifd: Interface 'PP_VPN' is setting up now
Fri Jan 3 18:22:43 2020 daemon.notice netifd: Interface 'PP_VPN' is now up
Fri Jan 3 18:22:43 2020 daemon.notice netifd: Network device 'tun0' link is down
Fri Jan 3 18:22:43 2020 daemon.notice netifd: Interface 'PP_VPN' has link connectivity loss
Fri Jan 3 18:22:43 2020 daemon.notice netifd: Interface 'PP_VPN' is now down
Fri Jan 3 18:22:43 2020 daemon.notice netifd: Interface 'PP_VPN' is disabled
Fri Jan 3 18:22:43 2020 user.notice firewall: Reloading firewall due to ifup of PP_VPN (tun0)
Fri Jan 3 18:22:46 2020 daemon.err uhttpd[1840]: luci: accepted login on /admin for root from 192.168.2.173
Fri Jan 3 18:22:48 2020 daemon.warn openvpn(PP_Amsterdam)[2962]: Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Interface 'PP_VPN' is enabled
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Network device 'tun0' link is up
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Interface 'PP_VPN' has link connectivity
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Interface 'PP_VPN' is setting up now
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Interface 'PP_VPN' is now up
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Network device 'tun0' link is down
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Interface 'PP_VPN' has link connectivity loss
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Interface 'PP_VPN' is now down
Fri Jan 3 18:22:51 2020 daemon.notice netifd: Interface 'PP_VPN' is disabled
Fri Jan 3 18:22:51 2020 user.notice firewall: Reloading firewall due to ifup of PP_VPN (tun0)
Fri Jan 3 18:22:56 2020 daemon.warn openvpn(PP_Amsterdam)[3190]: Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Interface 'PP_VPN' is enabled
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Network device 'tun0' link is up
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Interface 'PP_VPN' has link connectivity
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Interface 'PP_VPN' is setting up now
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Interface 'PP_VPN' is now up
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Network device 'tun0' link is down
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Interface 'PP_VPN' has link connectivity loss
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Interface 'PP_VPN' is now down
Fri Jan 3 18:22:59 2020 daemon.notice netifd: Interface 'PP_VPN' is disabled
Fri Jan 3 18:22:59 2020 user.notice firewall: Reloading firewall due to ifup of PP_VPN (tun0)
Fri Jan 3 18:23:02 2020 daemon.warn openvpn(PP_Amsterdam)[3452]: Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.

Fri Jan 3 18:39:24 2020 us=102901 OpenVPN 2.4.5 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Fri Jan 3 18:39:24 2020 us=102958 library versions: OpenSSL 1.0.2u 20 Dec 2019, LZO 2.10
Fri Jan 3 18:39:24 2020 us=103377 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Jan 3 18:39:24 2020 us=104606 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jan 3 18:39:24 2020 us=104664 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jan 3 18:39:24 2020 us=104705 LZO compression initializing
Fri Jan 3 18:39:24 2020 us=104871 Control Channel MTU parms [ L:1626 D:1140 EF:110 EB:0 ET:0 EL:3 ]
Fri Jan 3 18:39:24 2020 us=105027 Data Channel MTU parms [ L:1626 D:1300 EF:126 EB:407 ET:0 EL:3 ]
Fri Jan 3 18:39:24 2020 us=105074 Fragmentation MTU parms [ L:1626 D:1300 EF:125 EB:407 ET:1 EL:3 ]
Fri Jan 3 18:39:24 2020 us=105148 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1606,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
Fri Jan 3 18:39:24 2020 us=105180 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1606,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
Fri Jan 3 18:39:24 2020 us=105221 TCP/UDP: Preserving recently used remote address: [AF_INET]85.17.28.145:150
Fri Jan 3 18:39:24 2020 us=105263 Socket Buffers: R=[163840->163840] S=[163840->163840]
Fri Jan 3 18:39:24 2020 us=105294 UDP link local: (not bound)
Fri Jan 3 18:39:24 2020 us=105329 UDP link remote: [AF_INET]85.17.28.145:150
Fri Jan 3 18:39:24 2020 us=132176 TLS: Initial packet from [AF_INET]85.17.28.145:150, sid=abac6ad8 67c25965
Fri Jan 3 18:39:24 2020 us=132334 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Jan 3 18:39:24 2020 us=258128 VERIFY OK: depth=1, C=CH, ST=Zug, L=Zug, O=Perfect Privacy, CN=Perfect Privacy, emailAddress=admin@perfect-privacy.com
Fri Jan 3 18:39:24 2020 us=260866 VERIFY KU OK
Fri Jan 3 18:39:24 2020 us=260914 Validating certificate extended key usage
Fri Jan 3 18:39:24 2020 us=260949 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jan 3 18:39:24 2020 us=260978 VERIFY EKU OK
Fri Jan 3 18:39:24 2020 us=261007 VERIFY OK: depth=0, C=CH, ST=Zug, O=Perfect Privacy, CN=Server_amsterdam.perfect-privacy.com, emailAddress=admin@perfect-privacy.com
Fri Jan 3 18:39:25 2020 us=641852 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Fri Jan 3 18:39:25 2020 us=641953 [Server_amsterdam.perfect-privacy.com] Peer Connection Initiated with [AF_INET]85.17.28.145:150
Fri Jan 3 18:39:26 2020 us=900299 SENT CONTROL [Server_amsterdam.perfect-privacy.com]: 'PUSH_REQUEST' (status=1)
Fri Jan 3 18:39:26 2020 us=926378 PUSH: Received control message: 'PUSH_REPLY,topology subnet,redirect-gateway def1,sndbuf 131072,rcvbuf 131072,comp-lzo adaptive,route-gateway 10.3.1.2,redirect-gateway ipv6,route-ipv6 2000::/3,ping 10,ping-restart 60,dhcp-option DNS 95.211.146.77,dhcp-option DNS 5.79.98.56,ifconfig-ipv6 fdbf:1d37:bbe0:0:48:9:0:37/112 fdbf:1d37:bbe0:0:48:9:0:1,ifconfig 10.3.1.55 255.255.255.0,peer-id 16'
Fri Jan 3 18:39:26 2020 us=926580 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jan 3 18:39:26 2020 us=926620 OPTIONS IMPORT: compression parms modified
Fri Jan 3 18:39:26 2020 us=926657 LZO compression initializing
Fri Jan 3 18:39:26 2020 us=926692 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Fri Jan 3 18:39:26 2020 us=926728 Socket Buffers: R=[163840->262144] S=[163840->262144]
Fri Jan 3 18:39:26 2020 us=926756 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jan 3 18:39:26 2020 us=926783 OPTIONS IMPORT: route options modified
Fri Jan 3 18:39:26 2020 us=926810 OPTIONS IMPORT: route-related options modified
Fri Jan 3 18:39:26 2020 us=926842 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Jan 3 18:39:26 2020 us=926871 OPTIONS IMPORT: peer-id set
Fri Jan 3 18:39:26 2020 us=926899 OPTIONS IMPORT: adjusting link_mtu to 1629
Fri Jan 3 18:39:26 2020 us=926943 Data Channel MTU parms [ L:1609 D:1300 EF:109 EB:407 ET:0 EL:3 ]
Fri Jan 3 18:39:26 2020 us=927135 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jan 3 18:39:26 2020 us=927177 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jan 3 18:39:26 2020 us=927212 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jan 3 18:39:26 2020 us=927250 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jan 3 18:39:26 2020 us=927481 GDG6: remote_host_ipv6=n/a
Fri Jan 3 18:39:26 2020 us=927548 GDG6: NLMSG_ERROR: error Permission denied

Fri Jan 3 18:39:26 2020 us=930499 TUN/TAP device tun0 opened
Fri Jan 3 18:39:26 2020 us=930692 TUN/TAP TX queue length set to 100
Fri Jan 3 18:39:26 2020 us=930752 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Fri Jan 3 18:39:26 2020 us=930822 /sbin/ifconfig tun0 10.3.1.55 netmask 255.255.255.0 mtu 1500 broadcast 10.3.1.255
Fri Jan 3 18:39:26 2020 us=935078 /sbin/ifconfig tun0 add fdbf:1d37:bbe0::48:9:0:37/112
Fri Jan 3 18:39:26 2020 us=940493 up.sh tun0 1500 1609 10.3.1.55 255.255.255.0 init
Fri Jan 3 18:39:26 2020 us=942721 WARNING: Failed running command (--up/--down): could not execute external program
Fri Jan 3 18:39:26 2020 us=942792 Exiting due to fatal error
 

Adebar

New Member
OK, ich bin weiter gekommen..

Nachdem ich in der Amsterdam.ovpn die beiden Zeilen:"up up.sh & down down.sh" raus genommen habe, läuft es eigentlich. Ich musste zwar noch an den DNS Einstellungen rumspielen aber es läuft nun. Verteile einfach den PP DNS Server von Amsterdam, damit kommen meine zwei Test Clients auch erfolgreich ins Netz. Die Tests sehen auch IO aus, der IP Test zeigt den niederländischen Server, beim DNS Leak Test bekomme ich den DNS Server von Amsterdam und beim WebRTC steht keine öffentliche IP da.

Aber warum ist die Rechtevergabe auf die beiden Skripte "defekt"? Hast du da eine Idee?

Unbenannt.JPG


Über Amsterdam bin ich auch leider nur mit 40% meiner Bandbreite (100mbit) unterwegs, da werde ich aber noch entsprechend rumspielen und testen.
 

Gerd

Junior Member
der IP Test zeigt den niederländischen Server, beim DNS Leak Test bekomme ich den DNS Server von Amsterdam
Ich hatte bei der OpenWrt 18.06.02 OpenVPN Verbindung mit einem PP Server keine PP-DNS-Server. Daher war das Skript dafür gedacht.
Das Skript up.sh ändert den Eintrag "/tmp/resolv.conf.auto" in "Network-> DHCP and DNS-> Resolv and Host files-> Leasefile" (wo die eigenen DNS Server stehen) mit "/tmp/resolv.conf.vpn", wo dann die PP-DNS-Server stehen und verwendet werden.

Wenn bei dir automatisch die PP-DNS-Server nach der OpenVPN Verbindung verwendet werden, dann brauchst du natürlich nicht die up.sh und down.sh Skripte. Das ist umso besser für dich.

Aber warum ist die Rechtevergabe auf die beiden Skripte "defekt"? Hast du da eine Idee?
Damit man die Skripte benutzen kann, sorgt wahrscheinlich der Befehl:

Code:
script-security 2
Es wäre möglich, dass die Skripte nicht defekt sind und dass einiges mit der OpenWRT 18.06.05 geändert/verbessert wurde.

Ich teste OpenWrt 18.06.05 selbst nochmal.
 

Gerd

Junior Member
Ich habe nochmal die Version 18.06.05 getestet. Bei mir ist up.sh und down.sh Skript notwendig, um PP-DNS.Server anzuzeigen. Es wird auch bei mir kein Fehler angezeigt.

Die Server.ovpn Dateien, die in der Anleitung zum Download stehen, funktionieren auch einwandfrei.

Die Frage ist jetzt worin deine OpenWrt 18.06.05 von meiner unterscheidet. Das könnte gut das OpenWrt Forum beantworten.

Ein kleinen Fehler habe ich noch in der Anleitung gefunden.

Man müsste diese Zeile für IPv6 Skript:
Code:
cat << EOF > /etc/firewall.nat6 iptables-save --table="nat" \ | sed -e "/\s[DS]NAT\s/d" \ | ip6tables-restore --table="nat" EOF
mit diesen Zeilen ersetzen:
Code:
cat << EOF > /etc/firewall.nat6
iptables-save -t nat \
| sed -e "/\s[DS]NAT\s/d" \
| ip6tables-restore -T nat
EOF
Edit: Eine Frage noch @Adebar. Hast du etwas zusätzlich aktiviert, damit automatisch die PP-DNS-Server verwendet werden?
 

Gerd

Junior Member
Aber warum ist die Rechtevergabe auf die beiden Skripte "defekt"? Hast du da eine Idee?
Ich vermute, dass irgend etwas im Skript nicht gelesen werden kann. An der Rechtevergabe liegt es nicht.

Wenn das Problem weiterhin besteht, dann versuch mal folgendes. Trage in up.sh und down.sh am Ende des Skripts
Code:
exit 0
hinzu und sag mir Bescheid, ob es funktioniert hat.
 

Adebar

New Member
Ich hatte bei der OpenWrt 18.06.02 OpenVPN Verbindung mit einem PP Server keine PP-DNS-Server. Daher war das Skript dafür gedacht.
Das Skript up.sh ändert den Eintrag "/tmp/resolv.conf.auto" in "Network-> DHCP and DNS-> Resolv and Host files-> Leasefile" (wo die eigenen DNS Server stehen) mit "/tmp/resolv.conf.vpn", wo dann die PP-DNS-Server stehen und verwendet werden.

Wenn bei dir automatisch die PP-DNS-Server nach der OpenVPN Verbindung verwendet werden, dann brauchst du natürlich nicht die up.sh und down.sh Skripte. Das ist umso besser für dich.
Ah das erklärt es sehr gut.
Da bei mir keine "/tmp/resolv.conf.vpn" erstellt wird, könntest du mir testhalber einmal den Inhalt deiner senden? Würde gern ein wenig damit testen.
Oder kann ich das up.sh Skript auch selbst mit einem Befehl via SSH ausführen? Bin bei Linux leider nicht so auf der Höhe.

Ich habe nochmal die Version 18.06.05 getestet. Bei mir ist up.sh und down.sh Skript notwendig, um PP-DNS.Server anzuzeigen. Es wird auch bei mir kein Fehler angezeigt.

Die Server.ovpn Dateien, die in der Anleitung zum Download stehen, funktionieren auch einwandfrei.

Die Frage ist jetzt worin deine OpenWrt 18.06.05 von meiner unterscheidet. Das könnte gut das OpenWrt Forum beantworten.
Sehr komisch.. wenn ich die Zeile "Failed running command (--up/--down): could not execute external program" google bekomme ich eigentlich auch nur Antworten die ich schon getestet habe. So ggf. muss ich mich da wirklich mal an das OpenWRT Forum wende, weiß nicht nicht so recht wie ich da anfangen soll :)

Edit: Eine Frage noch @Adebar. Hast du etwas zusätzlich aktiviert, damit automatisch die PP-DNS-Server verwendet werden?
Grundsätzlich nicht.

Ich hab das IPv6 Interface sogar mal ganz aus gehabt.
Das WAN Interface hab ich auf Statisch, DHCP hab ich aber vorhin auch getestet.
Im LAN Interface verweise ich lediglich auf mein PiHole und dort habe ich zwei DNS Server von PP eingetragen. Damit laufen gerade auch alle Clients - das allerdings erst seitdem ich das up.sh und down.sh rausgenommen habe.
Ich hab vorhin wirklich n ganz frisches System gehabt, nur die IPs der beiden Interfaces eingerichtet und einen normalen DNS Server, danach direkt das VPN versucht zu bauen und da auch direkt den Berechtigungsfehler erhalten.

Hast du evtl. einen Tipp wie ich meine Bandbreite verbessern kann? Vorhin hatte ich kurzzeitig 80 Mbits, seitdem aber nur noch ca 30.
Hab auch schon verschiedene Server durch Probiert, möchte aber in der Verschlüsselung nicht unter AES-256-CBC gehen.

Hätte noch eine allgemeine Frage:
Sobald das VPN eingeschalten ist, kann ich ja über meine tatsächliche IP Adresse mein System nicht mehr erreichen, gibt es eine Möglichkeit da trozdem einen Port zu öffnen und das System so hinter dem Router zu erreichen?
 

Adebar

New Member
Wenn das Problem weiterhin besteht, dann versuch mal folgendes. Trage in up.sh und down.sh am Ende des Skripts
Code:
exit 0
hinzu und sag mir Bescheid, ob es funktioniert hat.
Hat leider auch nicht geholfen, keine Ahnung was da schief läuft. Logs sehen in dem Fall unverändert aus.
 

Gerd

Junior Member
Da bei mir keine "/tmp/resolv.conf.vpn" erstellt wird, könntest du mir testhalber einmal den Inhalt deiner senden?
amsterdam2.perfect-privacy.com, IPv4: 95.211.95.232

/tmp/resolv.conf.vpn:
Code:
nameserver 185.17.184.3
nameserver 95.211.199.144
Nach der OpenVPN Verbindung den Eintrag "/tmp/resolv.conf.auto" in "Network-> DHCP and DNS-> Resolv and Host files-> Leasefile" mit "/tmp/resolv.conf.vpn" ersetzen.

So ggf. muss ich mich da wirklich mal an das OpenWRT Forum wende, weiß nicht nicht so recht wie ich da anfangen soll
Das Forum ist leider in englisch, aber da kommt man nicht drum herum. Wenn man das Problem genau beschreibt, dann erhaltet man zügig eine Antwort.

Ja was soll ich sagen...

  • Die Fehlermeldung posten:
Code:
Thu Jan 2 21:39:32 2020 us=227252 up.sh tun0 1500 1636 10.0.48.32 255.255.255.0 init
Thu Jan 2 21:39:32 2020 us=232514 WARNING: Failed running command (--up/--down): could not execute external program
Thu Jan 2 21:39:32 2020 us=232638 Exiting due to fatal error
  • Das Skript up.sh und down.sh posten und fragen warum die Skripte nicht erkannt werden bzw. fragen wo der Fehler liegt
Hast du evtl. einen Tipp wie ich meine Bandbreite verbessern kann? Vorhin hatte ich kurzzeitig 80 Mbits, seitdem aber nur noch ca 30.
Wenn dein PiHole so angeschlossen ist:

Internet<------>ISP Router<------>PiHole<------->LinksysWRT32X

Dann würde ich behaupten, dass dein PiHole der Flaschenhals ist.

Sobald das VPN eingeschalten ist, kann ich ja über meine tatsächliche IP Adresse mein System nicht mehr erreichen, gibt es eine Möglichkeit da trozdem einen Port zu öffnen und das System so hinter dem Router zu erreichen?
Ja, mit Policy Routing Package. Hier ist der Link.
 

Gerd

Junior Member
Nach der OpenVPN Verbindung den Eintrag "/tmp/resolv.conf.auto" in "Network-> DHCP and DNS-> Resolv and Host files-> Leasefile" mit "/tmp/resolv.conf.vpn" ersetzen.
Edit: Wenn du die OpenVPN Verbindung beendest oder den Router neustartest, dann brauchst du natürlich wieder "/tmp/resolv.conf.auto".
 
Top