OpenVPN-Paket

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Danke, mit neustarten meins du openvpn nicht die Box oder? ;)

Ich glaube er ignoriert die /tmp/flash/openvpn/own_openvpn.conf ...

Hmm seit heute morgen bringt auch kein Neustart mehr was, ich kann 192.168.2.1 nicht pingen und meine Androiden haben kein Internet.

Ich kann auch nicht mehr die 192.168.200.1 pingen, die 192.168.200.2 aber schon...

Code: 
cat /var/tmp/debug_openvpn.out 
Thu Jan  1 01:02:09 1970 OpenVPN 2.3.8 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Aug  9 2015
Thu Jan  1 01:02:09 1970 library versions: OpenSSL 0.9.8zg 11 Jun 2015, LZO 2.09
Thu Jan  1 01:02:09 1970 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Jan  1 01:02:09 1970 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Thu Jan  1 01:02:09 1970 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jan  1 01:02:09 1970 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jan  1 01:02:09 1970 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu Jan  1 01:02:09 1970 Attempting to establish TCP connection with [AF_INET]xxx.xx.x.xx:3128 [nonblock]
Thu Jan  1 01:02:09 1970 TCP connection established with [AF_INET]xxx.xx.x.xx:3128
Thu Jan  1 01:02:09 1970 Send to HTTP proxy: 'CONNECT xxx.myfritz.net:443 HTTP/1.0'
Thu Jan  1 01:02:09 1970 HTTP proxy returned: 'HTTP/1.0 200 Connection established'
Sat Aug 29 00:00:01 2015 TCPv4_CLIENT link local: [undef]
Sat Aug 29 00:00:01 2015 TCPv4_CLIENT link remote: [AF_INET]xxx.xx.x.xx:3128
Sat Aug 29 00:00:02 2015 TLS: Initial packet from [AF_INET]xxx.xx.x.xx:3128, sid=b4771c56 cb86a1f5
Sat Aug 29 00:00:03 2015 VERIFY OK: depth=1, C=DE, ST=xxx, L=xxx, O=Internet Ltd., OU=MyOrganizationalUnit, CN=Internet Ltd. CA, name=xxx, emailAddress=xxx
Sat Aug 29 00:00:03 2015 VERIFY OK: depth=0, C=DE, ST=xxx, L=xxx, O=Internet Ltd., OU=MyOrganizationalUnit, CN=xxx, name=xxx, emailAddress=xxx
Sat Aug 29 00:00:07 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 29 00:00:07 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Aug 29 00:00:07 2015 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 29 00:00:07 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Aug 29 00:00:07 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Aug 29 00:00:07 2015 [vorhop] Peer Connection Initiated with [AF_INET]172.30.0.30:3128
Sat Aug 29 00:00:09 2015 SENT CONTROL [vorhop]: 'PUSH_REQUEST' (status=1)
Sat Aug 29 00:00:09 2015 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.200.1,topology subnet,route 192.168.2.0 255.255.255.0,route 192.168.200.1,ping 10,ping-restart 120,ifconfig 192.168.200.2 255.255.255.0'
Sat Aug 29 00:00:09 2015 OPTIONS IMPORT: timers and/or timeouts modified
Sat Aug 29 00:00:09 2015 OPTIONS IMPORT: --ifconfig/up options modified
Sat Aug 29 00:00:09 2015 OPTIONS IMPORT: route options modified
Sat Aug 29 00:00:09 2015 OPTIONS IMPORT: route-related options modified
Sat Aug 29 00:00:09 2015 TUN/TAP device tun0 opened
Sat Aug 29 00:00:09 2015 TUN/TAP TX queue length set to 100
Sat Aug 29 00:00:09 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Aug 29 00:00:09 2015 /sbin/ifconfig tun0 192.168.200.2 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Sat Aug 29 00:00:09 2015 /sbin/route add -net 172.30.0.30 netmask 255.255.255.255 dev dsl
Sat Aug 29 00:00:09 2015 /sbin/route del -net 0.0.0.0 netmask 0.0.0.0
Sat Aug 29 00:00:09 2015 /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.200.1
Sat Aug 29 00:00:09 2015 /sbin/route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.200.1
Sat Aug 29 00:00:09 2015 /sbin/route add -net 192.168.200.1 netmask 255.255.255.255 gw 192.168.200.1
Sat Aug 29 00:00:09 2015 Initialization Sequence Completed
root@fritz:/var/mod/root# netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
xxx.xx.x.xx     *               255.255.255.255 UH        0 0          0 dsl
192.168.180.1   *               255.255.255.255 UH        0 0          0 dsl
xxx.xx.x.xx     *               255.255.255.255 UH        0 0          0 dsl
xxx.xx.x.xx     *               255.255.255.255 UH        0 0          0 dsl
192.168.180.2   *               255.255.255.255 UH        0 0          0 dsl
192.168.200.1   192.168.200.1   255.255.255.255 UGH       0 0          0 tun0
192.168.2.0     192.168.200.1   255.255.255.0   UG        0 0          0 tun0
192.168.200.0   *               255.255.255.0   U         0 0          0 tun0
192.168.188.0   *               255.255.255.0   U         0 0          0 lan
192.168.189.0   *               255.255.255.0   U         0 0          0 guest
xxx.xx.x.xx     *               255.255.0.0     U         0 0          0 dsl
169.254.0.0     *               255.255.0.0     U         0 0          0 lan
default         192.168.200.1   0.0.0.0         UG        0 0          0 tun0
 
Zuletzt bearbeitet:
Also, der Verbindungsaufbau sieht gut aus, Routen kommen usw.

Wenn du nun von der FB nicht mehr durch den Tunnel kommst:

- LZO auf beiden Seiten an/aus?
- tls-auth auf beiden Seiten an/aus?
 
Das ist über Nacht passiert und eigentlich habe ich nicht dran rumgefummelt...

Server:
Code: 
cat /mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Wed Sep  2 16:28:26 CEST 2015
proto tcp-server
dev tun
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 443
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
topology subnet
push "topology subnet"
push "route 192.168.2.0 255.255.255.0"
max-clients 9
mode server
ifconfig-pool 192.168.200.100 192.168.200.250
push "route 192.168.200.1"
client-config-dir clients_openvpn
route 192.168.188.0 255.255.255.0 192.168.200.2
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher BF-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-key
Hier wundert mich etwas tls-auth /tmp/flash/openvpn/static.key 0

Client:
Code: 
cat /mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Thu Jan  1 01:02:13 CET 1970
proto tcp-client
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
tls-auth /tmp/flash/openvpn/static.key 1
remote xxx.myfritz.net 443
nobind
pull
redirect-gateway
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher BF-CBC
comp-lzo
float
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log
cd /var/tmp/openvpn
persist-tun
persist-key
http-proxy xxx.xx.x.xx 3128

tls-auth /tmp/flash/openvpn/static.key 1


Ist das der entscheidende Unterschied?
Wenn ja wieso? der Hacken ist bei beiden drin und bisher hat es so funktioniert oO
Und viel wichtiger: Wie bekomme ich es wieder gerade?
 
Das mit dem "tls-auth" und den Zahlen "muss so" (das ist die "direction", und entweder Server und Client haben unterschiedliche wie hier oder keine)

...
The direction parameter should always be complementary on either side of
the connection, i.e. one side should use "0" and the other should use "1",
or both sides should omit it altogether.
Zum Vergrößern anklicken....

Was sagt das Log auf dem Server? Weicht die Zeit zu weit ab (du nutzt ja eine "veraltete" Zeit auf dem Server)? Nutzt vielleicht ein weiterer Client das gleiche Zertifikat? ...
 
MaxMuster schrieb:
Das mit dem "tls-auth" und den Zahlen "muss so"
Zum Vergrößern anklicken....
auch das Static?

MaxMuster schrieb:
Was sagt das Log auf dem Server?
Zum Vergrößern anklicken....

Schau ich gleich mal


MaxMuster schrieb:
Weicht die Zeit zu weit ab (du nutzt ja eine "veraltete" Zeit auf dem Server)?
Zum Vergrößern anklicken....

Jap, die weicht extremst ab, war bisher aber kein Problem solange sie innerhalb der Zertifikatsgültigkeit ist, die Fritz!Box hat ihre Zeit aktualisiert, wenn sie dann per OpenVPN dazu in der Lage war.
MaxMuster schrieb:
Nutzt vielleicht ein weiterer Client das gleiche Zertifikat? ...
Zum Vergrößern anklicken....
Ich hoffe doch nicht ;)
 
Es wird nur der "static Key", genutzt, der sonst z.B. in einer Config nur mit "Secret" genutzt wird. Wie in dem Fall muss er auf beiden Seiten gleich sein, aber wenns zuvor funktioniert hatte ...
 
MaxMuster schrieb:
Es wird nur der "static Key", genutzt, der sonst z.B. in einer Config nur mit "Secret" genutzt wird. Wie in dem Fall muss er auf beiden Seiten gleich sein, aber wenns zuvor funktioniert hatte ...
Zum Vergrößern anklicken....

Ah OK, das hab ich nicht gewusst.
Da hab ich ja Glück, dass ich das ganze vorher versucht habe über static hin zu bekommen, da ich erstmal den einfachen Weg nutzen wollte.
Die sind gleich, habs gerade vorsichtshalber nochmal gecheckt.

So, nun wie versprochen die Logs vom Server.
Habe anhand der Logs mal den VPN Server neu gestartet und dann funktionierte es auch wieder.
(Have you tried to put it on and off again?...)
Die Logs riechen ja danach, dass sich jemand versucht hat in die Verbindung zu hacken oder?
Der Admin des Proxy Servers? Wie hoch ist denn die Wahrscheinlichkeit, dass er es schafft? Public-Key ist doch ziemlich sicher oder?
Code: 
cat /var/tmp/debug_openvpn.out
Mon Sep  7 19:39:53 2015 OpenVPN 2.3.8 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Aug  7 2015
Mon Sep  7 19:39:53 2015 library versions: OpenSSL 0.9.8zg 11 Jun 2015, LZO 2.09
Mon Sep  7 19:39:53 2015 Diffie-Hellman initialized with 2048 bit key
Mon Sep  7 19:39:53 2015 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Mon Sep  7 19:39:53 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep  7 19:39:53 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep  7 19:39:53 2015 TUN/TAP device tun2 opened
Mon Sep  7 19:39:53 2015 TUN/TAP TX queue length set to 100
Mon Sep  7 19:39:53 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Sep  7 19:39:53 2015 /sbin/ifconfig tun2 192.168.200.1 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Mon Sep  7 19:39:54 2015 /sbin/route add -net 192.168.188.0 netmask 255.255.255.0 gw 192.168.200.2
route: SIOCADDRT: File exists
Mon Sep  7 19:39:54 2015 ERROR: Linux route add command failed: external program exited with error status: 1
Mon Sep  7 17:39:54 2015 chroot to '/var/tmp/openvpn' and cd to '/' succeeded
Mon Sep  7 17:39:54 2015 GID set to openvpn
Mon Sep  7 17:39:54 2015 UID set to openvpn
Mon Sep  7 17:39:54 2015 TCP connection established with [AF_INET]xx.xx.xxx.xx:34611
Mon Sep  7 17:39:54 2015 TCPv4_SERVER link local: [inetd]
Mon Sep  7 17:39:54 2015 TCPv4_SERVER link remote: [AF_INET]xx.xx.xxx.xx:34611
Mon Sep  7 17:39:54 2015 MULTI: multi_init called, r=256 v=256
Mon Sep  7 17:39:54 2015 IFCONFIG POOL: base=192.168.200.100 size=151, ipv6=0
Mon Sep  7 17:39:54 2015 MULTI: TCP INIT maxclients=9 maxevents=13
Mon Sep  7 17:39:54 2015 Initialization Sequence Completed
Mon Sep  7 17:39:54 2015 TCP connection established with [AF_INET]xx.xx.xxx.xx:34611
Mon Sep  7 17:39:54 2015 xx.xx.xxx.xx:34611 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1547 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Mon Sep  7 17:39:54 2015 xx.xx.xxx.xx:34611 Connection reset, inetd/xinetd exit [0]
Mon Sep  7 17:39:54 2015 xx.xx.xxx.xx:34611 SIGTERM[soft,connection-reset-inetd] received, client-instance exiting
Mon Sep  7 17:39:54 2015 TCP/UDP: Close Socket failed: Bad file descriptor (errno=9)
Mon Sep  7 17:39:54 2015 Closing TUN/TAP interface
Mon Sep  7 17:39:54 2015 /sbin/ifconfig tun2 0.0.0.0
Mon Sep  7 17:39:54 2015 Linux ip addr del failed: could not execute external program
Mon Sep  7 17:39:54 2015 SIGTERM[soft,] received, process exiting
 
Ja, die Sicherheit sollte eigentlich "für den Hausgebrauch" auf jeden Fall ausreichen.
Eventuell ist tatsächlich bei nem internen OpenVPN Neustart was danebengegangen (z.B. "tun2" im Log; es fängt eigentlich mit "tun0" an).
Dass sich zwischendrin die Zeit (Zeitzone?) ändert, könnte auch das Problem sein (da geht es plötzlich zwei Stunden in die Vergangenheit)...
 
MaxMuster schrieb:
Ja, die Sicherheit sollte eigentlich "für den Hausgebrauch" auf jeden Fall ausreichen.
Zum Vergrößern anklicken....
Na das hoffe ich mal, Netzwerkgeräte sind hier nicht erlaubt, was für ein Zufall, dass die Fritz!Box die gleiche MAC Adresse hat wie der Rechner der hier steht ;)

MaxMuster schrieb:
Eventuell ist tatsächlich bei nem internen OpenVPN Neustart was danebengegangen (z.B. "tun2" im Log; es fängt eigentlich mit "tun0" an).
Dass sich zwischendrin die Zeit (Zeitzone?) ändert, könnte auch das Problem sein (da geht es plötzlich zwei Stunden in die Vergangenheit)...
Zum Vergrößern anklicken....

Stimmt, seltsam...
Naja, die VPN Verbindung stand schon einige Tage...
Das mit der Zeit ist ja "witzig", weil der Server sollte eigentlich keine Probleme haben an die richtige Zeit zu kommen...
 
JokerGermany schrieb:
Na das hoffe ich mal, Netzwerkgeräte sind hier nicht erlaubt ...
...
Zum Vergrößern anklicken....
Nun, dann hoffe ich, du weißt, was du tust.
Je nach der Konkretisierung von "hier" sind besonders solche Leute wie Arbeitgeber oft hart, wenn man solche Beschränkungen ganz aktiv umgeht (m.E. meist vollkommen zurecht)...
 
Konnte auf die Schnelle nix finden: Hat noch jemand mit der aktuellen OpenVPN-Version als Server in Freetz Probleme? Bekomme mit der 2.3.8, die aktuell im SVN enthalten ist zwar eine Verbindung und die Routen werden gesetzt, allerdings werden keinerlei Daten mehr übertragen (mit LAN gebrücktes TAP-Device). Ich habe die Version im Code mal händisch auf 2.3.6 geändert und neu gebaut und siehe da: Mit der selben config funktioniert's auch mit neueren Freetz-Versionen. Es muss also irgendwie ein Problem mit Versionen > 2.3.6 geben.
Kann das jemand bestätigen?
 
Zuletzt bearbeitet:
Minimaltest mit TAP und 2.3.8 ohne Probleme:

Code: 
root@fritz:/var/mod/root# openvpn --version
OpenVPN 2.3.8 mipsel-unknown-linux-gnu [SSL (PolarSSL)] [LZO] [IPv6] built on Sep 15 2015
library versions: PolarSSL 1.2.15, LZO 2.09
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <[email protected]>
root@fritz:/var/mod/root# ifconfig tap0
tap0      Link encap:Ethernet  HWaddr 42:F3:3F:69:EB:30  
          inet addr:10.11.12.1  Bcast:10.11.12.255  Mask:255.255.255.0
          inet6 addr: fe80::XXXX:XXXXXXXXXXX/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:70 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:11072 (10.8 KiB)  TX bytes:854 (854.0 B)

root@fritz:/var/mod/root# ping 10.11.12.2
PING 10.11.12.2 (10.11.12.2): 56 data bytes
64 bytes from 10.11.12.2: seq=0 ttl=64 time=174.689 ms
64 bytes from 10.11.12.2: seq=1 ttl=64 time=3.151 ms
64 bytes from 10.11.12.2: seq=2 ttl=64 time=3.042 ms
64 bytes from 10.11.12.2: seq=3 ttl=64 time=3.150 ms

--- 10.11.12.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 3.042/46.008/174.689 ms
root@fritz:/var/mod/root# ifconfig tap0
tap0      Link encap:Ethernet  HWaddr 42:F3:3F:69:EB:30  
          inet addr:10.11.12.1  Bcast:10.11.12.255  Mask:255.255.255.0
          inet6 addr: fe80::XXXX:XXXXXXXXXXX/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:78 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:11717 (11.4 KiB)  TX bytes:1288 (1.2 KiB)

root@fritz:/var/mod/root#
 
Ich habe beide Fritz!Boxen auf die Firmware 6.51 mit neuem OpenVPN simple gui gupdatet und nun geht nichts mehr...

Fehlermeldung:
Code: 
cat /var/tmp/debug_openvpn.out 
Sat Mar  5 23:58:14 2016 cd to '/var/tmp/openvpn' failed: No such file or directory (errno=2)
Sat Mar  5 23:58:14 2016 Exiting due to fatal error

Config ist eigentlich nahezu (Port + Ohne HTTP Proxy, da über Mobilfunk) gleich zu meiner letzten Problemmeldung geblieben:

Server:
Code: 
#  OpenVPN 2.1 Config, Wed Sep  2 16:28:26 CEST 2015
proto tcp-server
dev tun
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 1194
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
topology subnet
push "topology subnet"
push "route 192.168.2.0 255.255.255.0"
max-clients 9
mode server
ifconfig-pool 192.168.200.100 192.168.200.250
push "route 192.168.200.1"
client-config-dir clients_openvpn
route 192.168.188.0 255.255.255.0 192.168.200.2
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher BF-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-key
Hier wundert mich etwas tls-auth /tmp/flash/openvpn/static.key 0

Client:
Code: 
#  OpenVPN 2.1 Config, Thu Jan  1 01:02:13 CET 1970
proto tcp-client
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
tls-auth /tmp/flash/openvpn/static.key 1
remote xxx.myfritz.net 1194
nobind
pull
#redirect-gateway
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher BF-CBC
comp-lzo
float
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log
cd /var/tmp/openvpn
persist-tun
persist-key
#http-proxy xxx.xx.x.xx 3128
 
Nanu?

Nicht mehr ganz taufrisch: PolarSSL 1.2.15 in #1193

Der Zweig 1.2 wird nicht mehr gepflegt.
 
grauGolz schrieb:
PolarSSL 1.2.15 in #1193; Der Zweig 1.2 wird nicht mehr gepflegt.
Zum Vergrößern anklicken....

@Graugolz: Du verbreitest hier mal wieder Müll, bzw. Fehlaussagen!!!

an die OpenVPN und PolarSSL-Interessierte:
das aktuelle Maintenance Release von PolarSSL ist 1.2.19 und wurde am 04.01.2016 published: PolarSSL 1.2.19 released
Hinweis: PolarSSL is now part of ARM and rebranded as mbed TLS, d.h. der Name wird sich zukünftig nach mbedTLS ändern.

LG tuxedonet
 
Zuletzt bearbeitet:
tls.mbed.org sagt:

"Users of the PolarSSL 1.2 branch are urged to upgrade to one of the maintained branches as 1.2 is now end-of-life and will no longer receive security fixes."

Kann jeder nachlesen oder auch nicht.

Kann aber sein, daß die Leute von tls.mbed.org auch nur Müll oder Fehlausagen verbreiten. :)
 
Zuletzt bearbeitet:
@JokerGermany
JokerGermany schrieb:
[...] mit neuem OpenVPN simple gui gupdatet und nun geht nichts mehr...
[...]
Config ist eigentlich nahezu (Port + Ohne HTTP Proxy, da über Mobilfunk) gleich zu meiner letzten Problemmeldung geblieben:
Zum Vergrößern anklicken....
So ein "Umstieg" ist nicht vorgesehen. Bei der "simplen GUI" musst du alle Voraussetzungen "selbst schaffen", die dir die "normale GUI" abgenommen hat.

Eine Nutzung eines "chroot" setzt dann z.B. das Anlegen des Verzeichnisses voraus, das ist bei dir scheinbar das Problem. "Einfacher Workaround" für dieses Problem wäre der Verzicht auf chuser/chroot, also Löschen der Zeilen:
Code: 
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
Ob noch was anderes fehlt, müsste man dann mal sehen.
 
Danke, hatte ich auch schon probiert, dann bekomme ich folgende Fehlermeldung:
Code: 
cat /var/tmp/debug_openvpn.out 
Options error: --client-config-dir fails with 'clients_openvpn': No such file or directory
Options error: Please correct these errors.
Use --help for more information.
 
Ohne zu erkennen, worauf sich das "auch schon probiert" beziehen mag ... ich unterstelle mal, daß Du damit meinst, Du hast das "chroot" weggelassen und dann müssen sich natürlich die anderen Einstellungen (zumindest die, die nach dem "chroot" und dem nachfolgenden "Droppen" der Privilegien erst wirksam werden) auch auf die "reale" Verzeichnisstruktur beziehen. Damit liegt dann das gesuchte "client-config-dir" eben nicht mehr unterhalb von /var/tmp/openvpn, sondern irgendwo anders - normalerweise nimmt dann OpenVPN (rein aus der Erinnerung, muß nicht stimmen und wäre zu prüfen) das Verzeichnis mit der Konfigurationsdatei als Basis für relative Pfadangaben. Ob da absolute Angaben möglich sind, wäre einen Versuch wert, ansonsten eben dafür sorgen, daß das Unterzeichnis für die Client-Konfigurationsdateien auch existiert (nichts anderes fordert die Fehlermeldung in #1198).
 
Hmm, Danke.
Ich habe mir gedacht verfrachte ich das doch dahin wo es vorher war.
--client-config-dir /var/tmp/openvpn

Leider existiert das Verzeichnis nicht und mkdir "kennt" er angeblich nicht...

Irgendwas verstehe ich scheinbar gewaltig falsch =(
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 759 (Mitglieder: 36, Gäste: 723)

Neueste Beiträge

Statistik des Forums

Themen
246,149
Beiträge
2,246,931
Mitglieder
373,662
Neuestes Mitglied
frankbugislaus
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück