OpenVPN-Paket

[knox]

Selbst die Variante mit dem Static.key läuft nicht mehr???

wie supamicha und andere berichtet haben, funktioniert zumindest static key ohne probleme. ich selbst hab es mit einem entfernten client versucht (fritzbox als server) und das klappt einwandfrei.

Top1
Der VPN-Daemon lässt nicht ohne Fehler starten. Der Client liefert mir im verb 6 immer die Meldung:

 UDPv4 WRITE [42] to MYREMOTEIP:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #14 ] [ ] pid=0 DATA len=0

bis ich den Verbindungsaufbau unterbreche (die #14 ist offensichtlich ein Zähler. Hier der 14. Versuch).

also der daemon startet ja offensichtlich doch ohne fehlermeldung. was du da zeigst, sind probleme beim verbindungsaufbau. sowas hat meistens mit routing (zwischen server und client) oder firewall zu tun.

Top2 ... Kann man das irgendwo einstellen (z.B. verb serverseitig anheben)?

ja, du kannst es einstellen. allerdings bisher nicht über das webinterface (weil es für normalsterbliche ja auch uninteressant ist). du kannst einfach den wert OPENVPN_LZO_VERBOSE in /mod/etc/conf/openvpn-lzo.cfg ändern.

Top3
... alle bestehenden Verbindungen in die Datei geschrieben.

guter vorschlag, wird im nächsten package release dabei sein. aber erst mal ohne weboberfläche.

Top4
... Wie kann ich manuelle Änderungen an solchen Konfigurationsdateien permanent machen.

diese frage wird häufig gestellt; die config dateien der dienste sind im ds-mod grundsätzlich flüchtig. sie werden von den start/stop scripten on the fly erstellt bzw. gelöscht. schau dir mal /mod/etc/default.openvpn-lzo/openvpn-lzo_conf an, dieses script erstellt die config. aber ob es wirklich sinn macht, daran selbst herum zu schrauben?

[MicAlter]

also der daemon startet ja offensichtlich doch ohne fehlermeldung. was du da zeigst, sind probleme beim verbindungsaufbau. sowas hat meistens mit routing (zwischen server und client) oder firewall zu tun.

Die Firewall am Client habe ich komplett beendet und für die FritzBox sollte eigentlich das dsmod zuständig sein...UUUPPSS...ich habe mal in der ar7.cfg nachgeschaut und musste mit erschrecken feststellen, dass der Port 1194 nicht geöffnet ist. Und ich dachte, als ich die Port-Einstellung im WebInterface gesehen habe, dass das dsmod die Regel einträgt...ähm...

Ok, habe die Änderung manuell in die ar7.cfg eingebaut, die Box rebootet und die Einstellung nochmals geprüft. Leider bekomme ich es trotzdem nicht hin. Ich habe jetzt wieder auf "Static" umgestellt, aber bekomme nur folgende Ausgabe:

Mon Jan 15 09:52:31 2007 us=745000 UDPv4 link remote: WANIP:1194
Mon Jan 15 09:52:31 2007 us=745000 UDPv4 READ [-1] from [undef]: DATA UNDEF len=-1
Mon Jan 15 09:52:31 2007 us=755000 UDPv4 READ [-1] from [undef]: DATA UNDEF len=-1
...

Irgendwie habe ich das Gefühl, als wenn die Pakete nicht an den Server weitergereicht werden???

EDIT
Ich habe hier ein komisches Verhalten:
Ich habe im Syslog gelesen, dass UDP-Pakete vom openvpn-daemon zurückgewiesen wurden!?! Danach habe ich mal auf TCP umgestellt, die ar7cfg entsprechend erweitert, rebootet und siehe da - es läuft. Anschließend Server und Client wieder auf UDP umgestellt - kein Reboot - und die Verbindung konnte auch hergestellt werden!
Keine Ahnung, was da intern passiert

guter vorschlag, wird im nächsten package release dabei sein. aber erst mal ohne weboberfläche.

Ich werde mich mal ein bisschen damit beschäftigen...vielleicht bekomme ich ja was brauchbares hin. Wird allerdings etwas dauern, da ich erst einmal ins Thema einarbeiten muss...

... aber ob es wirklich sinn macht, daran selbst herum zu schrauben?

Ist auch nur für Testzwecke gedacht, damit ich beispielsweise mal das verb erhöhen kann, ohne manuell den daemon zu stoppen, um ihn dann mit einer geänderten Configdatei aus einem anderen Verzeichnis erneut zu starten. Das man damit viel - sehr viel - Unsinn anstellen kann, sollte allen klar sein, oder?

[MicAlter]

Verwendung von Zertifikaten
Die Verbindung wird nun aufgebaut, allerdings sagt der Server, dass er keine CRL.pem lesen kann:

"CRL: cannot read: /tmp/flash/crl.pem: No such file or directory (errno=2)".

-> Danach beendet sich der daemon!

Ich habe die aktuelle Konfiguration in "/var/tmp" kopiert und die Option "crl-verify" herausausgenommen. Anschließend den VPN-daemon mit dieser Konfiguration gestartet und siehe da: Nun funktioniert das Ganze auch mit Zertifikaten!

Also: Wenn ich noch keine zurückgewiesenen Zertifikate habe, was soll dann in der Datei stehen? Nur ein Header?

Wenn ja, wie erzeuge ich diesen?

Ich habe versucht die Datei (CRL.pem) unter Windows zu erzeugen, aber das schlägt total fehl:

C:\Programme\OpenVPN\bin>openssl ca -gencrl -out crl.pem
Using configuration from /usr/local/ssl/openssl.cnf
error loading the config file '/usr/local/ssl/openssl.cnf'
828:error:02001003:system library:fopen:No such process:.\crypto\bio\bss_file.c:
104:fopen('/usr/local/ssl/openssl.cnf','rb')
828:error:2006D080:BIO routines:BIO_new_file:no such file:.\crypto\bio\bss_file.
c:107:
828:error:0E064072:configuration file routines:CONF_load:no such file:.\crypto\c
onf\conf_def.c:197:

Funktioniert wohl nur unter Linux...oder mache ich was falsch?

[knox]

"CRL: cannot read: /tmp/flash/crl.pem: No such file or directory (errno=2)".

ok, vielen dank für den hinweis. ich hab das gefixed.

wie erzeuge ich diesen?

schau dir mal easy-rsa von openvpn an. damit ist die erstellung von zertifikaten und den dazu gehörigen dateien eigentlich ein kinderspiel.

[knox]

Hier kommt nun ein neues Release des OpenVPN Package:

openvpn-2.1_rc1-dsmod-0.6b-lzo

Mit dieser Package Version wurden alle bisher bekannten Bugs der letzten Version behoben und kleinere Ergänzungen hinzugefügt. Nach wie vor müssen die neuen Funktionen ausführlich getestet werden. Es ist daher auch diesmal kein vollständiges Paket, sondern nur eine "Labor-Version" mit geändertem Webinterface und Scripten - das binary muss selbst compiled werden

Änderungen:

• Bugfix: Client-Modus mit statischem Schlüssel
• Bugfix: doppelter Start in rc.openvpn-lzo
• Bugfix: Kommunikation zwischen Clients (im Server-Modus)
• Bugfix: Start auch ohne crl.pem (Zertifikate)
• Bugfix: Maximale Länge bei Eingabe "Server-Adresse" (Client)
• Bugfix: Checkbox "Pull" (Client)
• Feature: VPN Netzwerk konfigurierbar (für TUN-Server)
• Feature: Lokales Netzwerk konfigurierbar (Route wird an Clients gepusht)
• Feature: Verbindungen in /var/log/openvpn.log protokollieren
• Feature: Optionale TLS-Authentifizierung (mit Zertifikaten)

Status:

• TUN Server, statischer Schlüssel = Ok
• TUN Client, statischer Schlüssel = Ok
• TAP DHCP Client, Zertifikate = Ok
• TAP DHCP Client, Zertifikate, TLS = Ok
• TAP Server, Zertifikate, TLS = Ok

Der angehängte Patch bezieht sich auf ds-0.2.9_26-13, aber das Package sollte auch mit älteren ds-mod Versionen funktionieren. Ferner wird das Paket nur mit der Option LZO angeboten (die Option muss in menuconfig mit ausgewählt werden!).

Einfach den angehängten Patch auf ein ds-mod Verzeichnis anwenden und dann mit "make openvpn-precompiled" das OpenVPN Paket erstellen. (Wie das geht steht im Wiki!)

Update: Veraltete Dateien entfernt - folge dem Thread oder schau ins Wiki

[wonderdoc]

Danke knox,

werde es gleich mal in meinen 0.2.9_26-12er DSMod einbauen und testen.

So, bekomme mein Client(statisch) nicht zum laufen, Tunnel steht, aber probleme mit route.

Jan 15 21:36:32 fritz daemon.warn openvpn[1108]: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Jan 15 21:36:32 fritz daemon.warn openvpn[1108]: OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.30.0

meine openvpn-lzo.conf

# OpenVPN 2.1 Config
proto tcp-client
port 32783
dev tun
secret /tmp/flash/static.key

remote xxx.dyndns.org
nobind
tun-mtu 1500
mssfix

daemon
verb 3

cipher BF-CBC
route 192.168.30.0 255.255.255.0
comp-lzo
resolv-retry infinite
comp-lzo

EDIT:
Ich habe in der root\etc\default.openvpn-lzo\openvpn-lzo_conf
die folgende Zeile erweitert:

if [ "$OPENVPN_LZO_REMOTE_NET" ]; then
echo "ifconfig $OPENVPN_LZO_BOX_IP $OPENVPN_LZO_REMOTE_IP"
echo "route $OPENVPN_LZO_REMOTE_NET"
fi

Danach klappe das Routing und die Fehler-Logmeldung ist weg.

mfg
Wonderdoc

[knox]

bekomme mein Client(statisch) nicht zum laufen, Tunnel steht, aber probleme mit route.

so ein mist, schon wieder so ein dämlicher bug (es ist aber auch wirklich kompliziert, wenn man 4 unterschiedliche betriebsmodi in einem script abbilden muss)...

deine änderung mag für deinen fall ausreichend sein, aber sie ist auch nicht die vollständige lösung.

ich habe nun unter dem selben namen ein aktualisiertes paket bereitgestellt.

[wonderdoc]

@knox

Ich habe nun mal dein aktualisiertes paket aufgespielt und siehe da,
Tunnel zum Server wurde aufgebaut und Routing ist OK.
(Test als Client mit statischer Verschlüsselung)

mfg
Wonderdoc

[knox]

weitere bugfixes...
selber dateiname, siehe hier.

[wonderdoc]

weitere bugfixes...
selber dateiname, siehe hier.

Hattest du die Datei im Anhang bereits neu ausgetauscht?
(Der Downloadzähler der Datei steht noch/schon bei 18 und daß Paket fehlt )

mfg
Wonderdoc

[MicAlter]

Hab's zwar noch nicht eingespielt, aber ich denke, man soll nur den folgenden Teil erneut durchführen, da das Patch lediglich die Versionsnummer ändert (von 0.5 -> 0.6a, bzw. jetzt 0.6a -> 0.6b). Wenn Du also die 0.6b bereits eingespielt hast, musst Du also lediglich folgendes machen...

rm dl/openvpn-2.1_rc1-dsmod-0.6b-lzo.tar.bz2
make openvpn-dirclean
make openvpn-precompiled

Geändert hat sich nur, das knox das Paket nicht mehr im Beitrag zum Download bereitgestellt hat, sonder nur den Patch.

[knox]

Hab's zwar noch nicht eingespielt, aber ich denke, man soll nur den folgenden Teil erneut durchführen, da das Patch lediglich die Versionsnummer ändert (von 0.5 -> 0.6a, bzw. jetzt 0.6a -> 0.6b).

wenn man die neuste version benutzen will, muss die versionsnummer entsprechend angepasst werden. das geht übrigens auch per hand.

Geändert hat sich nur, das knox das Paket nicht mehr im Beitrag zum Download bereitgestellt hat, sonder nur den Patch.

geändert hat sich vor allem das package, das auf meinem webserver liegt und beim make precompiled herunter geladen wird. das package selbst habe ich aus faulheit nicht wieder in den thread gepostet, weil das sowie keinen sinn macht.

[hermann72pb]

Zunächst will ich ein großes Lob an knox aussprechen. Das man fast alle Möglichkeiten und Feinheiten der OpenVPN-Konfiguration mit ds-Webinterface an der Fritz!Box realisiert, hätte ich wirklich nicht gedacht. Andererseits, kriegt man langsam ein Schrecken von all den Eingabemasken, die unter ds-mod-Einstellungen zu OpenVPN gehören. Die Sache verliert langsam die Übersicht, geschweige davon, dass ein Anfänger durch die Vielfalt der Einstellungen gar nicht wissen wird, wo und was er genau einzustellen hat.

Einige Ideen:

1. Vielleicht sollte man von dem ursprunglichen Menü-Konzept von DS-MOD mit Aufteilung auf Pakete, Dienste und Einstellungen weg gehen und die Einstellungen z.B. für OpenVPN unter dem Paket OpenVPN bringen.

2. Ist es wirklich notwendig, alle Zertiffikate und Schlüssel durch die Eingabemasken einzugeben? Könnte man es vielleicht stattdessen mit einem Upload entsprechender Dateien lösen? Meistens liegen diese Zertiffikate und Schlüssel in Form einer Datei vor. Das würde die Übersicht deutlich verbessern.

3. Eine einstellungsabhängige Menümaske wäre auch wünschenswert. Z.B. wählt man "static key", sieht man die anderen Masken (pem usw.) gar nicht, nur die Maske für "static key".

Bitte sehe meine Vorschläge nicht als Kritik ein. Ich kann mir gut vorstellen, dass meine Wünschliste nicht einfach zu realisieren ist.

MfG

Hermann

[wonderdoc]

Hallo,

ich habe mal auf das letzte Paket lt Beschreibung geupdatet.
Ich habe öffters mal das Problem, daß die Verbindung neugestartet wird.
im log steht dann immer:

Jan 17 22:39:58 fritz daemon.err openvpn[1596]: Connection reset, restarting [0]
Jan 17 22:39:58 fritz daemon.notice openvpn[1596]: TCP/UDP: Closing socket
Jan 17 22:39:58 fritz daemon.notice openvpn[1596]: /sbin/route del -net 192.168.30.0 netmask 255.255.255.0
Jan 17 22:39:58 fritz daemon.notice openvpn[1596]: Closing TUN/TAP interface
Jan 17 22:39:58 fritz daemon.notice openvpn[1596]: SIGUSR1[soft,connection-reset] received, process restarting
Jan 17 22:39:58 fritz daemon.notice openvpn[1596]: Restart pause, 5 second(s)

Könnte es damit zusammen hängen, daß der Client mit der 0.6b aber der Server noch mit der 0.4er Paketversion läuft?

mfg
Wonderdoc

[Schmide1]

Hallo,
wenn ich meinen Debian als VPN-Server benutze funktionierts ohne Probleme, kann pingen..., wenn ich es mit der FB mache funktionierts leider nicht.
Vielleicht kann mir einer einen Tipp geben.

Mhh wo sind denn die Symbole für den Code Block?

debian config:

dev tun0
ifconfig 192.168.200.2 192.168.200.1
tun-mtu 1500
float
mssfix
secret /etc/openvpn/zertifikate/secret.key
proto tcp-server
port 1194
verb 4
route 192.168.1.0 255.255.255.0
ping 15
ping-restart 120

mit dieser Config funktionierts.

Da ich leider das config von der Box nicht finde poste ich das Log:

log:
openvpn[3297]: TCPv4_SERVER link remote: 84.145.177.157:4440
openvpn[3297]: TCPv4_SERVER link local (bound): [undef]:1194
openvpn[3297]: Socket Buffers: R=[43689->131072] S=[16384->131072]
openvpn[3297]: TCP connection established with 84.145.177.157:4440
openvpn[3297]: Listening for incoming TCP connection on [undef]:1194
openvpn[3297]: Data Channel MTU parms [ L:1547 D:1450 EF:47 EB:135 ET:0 EL:0 AF:3/1 ]
openvpn[3297]: /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.200.1
openvpn[3297]: /sbin/route add -net 192.168.200.0 netmask 255.255.255.0 gw 192.168.200.1
openvpn[3297]: /sbin/ifconfig tun0 192.168.200.2 pointopoint 192.168.200.1 mtu 1500
openvpn[3297]: TUN/TAP TX queue length set to 100
01-21-2007 17:55:35 Daemon.Notice 192.168.178.1 openvpn[3297]: TUN/TAP device tun0 opened
01-21-2007 17:55:35 Daemon.Notice 192.168.178.1 openvpn[3297]: LZO compression initialized
01-21-2007 17:55:35 Daemon.Notice 192.168.178.1 openvpn[3297]: Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
01-21-2007 17:55:35 Daemon.Notice 192.168.178.1 openvpn[3297]: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
01-21-2007 17:55:35 Daemon.Notice 192.168.178.1 openvpn[3297]: Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
01-21-2007 17:55:35 Daemon.Notice 192.168.178.1 openvpn[3297]: Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
01-21-2007 17:55:34 Daemon.Notice 192.168.178.1 openvpn[3297]: Restart pause, 1 second(s)
01-21-2007 17:55:34 Daemon.Notice 192.168.178.1 openvpn[3297]: SIGUSR1[soft,ping-restart] received, process restarting
01-21-2007 17:55:34 User.Error 192.168.178.1 multid[975]: mrouter: tun0: can't del interface - Cannot assign requested address (126)
01-21-2007 17:55:34 User.Error 192.168.178.1 multid[975]: setsockopt for 0.0.0.0 failed - Cannot assign requested address (126)
01-21-2007 17:55:34 Daemon.Notice 192.168.178.1 openvpn[3297]: Closing TUN/TAP interface
01-21-2007 17:55:34 Daemon.Notice 192.168.178.1 openvpn[3297]: /sbin/route del -net 192.168.200.0 netmask 255.255.255.0
01-21-2007 17:55:34 Daemon.Notice 192.168.178.1 openvpn[3297]: /sbin/route del -net 192.168.1.0 netmask 255.255.255.0
01-21-2007 17:55:34 Daemon.Notice 192.168.178.1 openvpn[3297]: TCP/UDP: Closing socket
01-21-2007 17:55:34 Daemon.Notice 192.168.178.1 openvpn[3297]: Inactivity timeout (--ping-restart), restarting
01-21-2007 17:53:33 Daemon.Notice 192.168.178.1 openvpn[3297]: TCPv4_SERVER link remote: 84.145.177.157:4439
01-21-2007 17:53:33 Daemon.Notice 192.168.178.1 openvpn[3297]: TCPv4_SERVER link local (bound): [undef]:1194
01-21-2007 17:53:33 Daemon.Notice 192.168.178.1 openvpn[3297]: Socket Buffers: R=[43689->131072] S=[16384->131072]
01-21-2007 17:53:33 Daemon.Notice 192.168.178.1 openvpn[3297]: TCP connection established with 84.145.177.157:4439
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: Listening for incoming TCP connection on [undef]:1194
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: Data Channel MTU parms [ L:1547 D:1450 EF:47 EB:135 ET:0 EL:0 AF:3/1 ]
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.200.1
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: /sbin/route add -net 192.168.200.0 netmask 255.255.255.0 gw 192.168.200.1
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: /sbin/ifconfig tun0 192.168.200.2 pointopoint 192.168.200.1 mtu 1500
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: TUN/TAP TX queue length set to 100
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: TUN/TAP device tun0 opened
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: LZO compression initialized
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
01-21-2007 17:53:29 Daemon.Notice 192.168.178.1 openvpn[3297]: Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
01-21-2007 17:53:28 Daemon.Notice 192.168.178.1 openvpn[3297]: Restart pause, 1 second(s)
01-21-2007 17:53:28 Daemon.Notice 192.168.178.1 openvpn[3297]: SIGUSR1[soft,ping-restart] received, process restarting
01-21-2007 17:53:28 User.Error 192.168.178.1 multid[975]: mrouter: tun0: can't del interface - Cannot assign requested address (126)
01-21-2007 17:53:28 User.Error 192.168.178.1 multid[975]: setsockopt for 0.0.0.0 failed - Cannot assign requested address (126)
01-21-2007 17:53:28 Daemon.Notice 192.168.178.1 openvpn[3297]: Closing TUN/TAP interface
01-21-2007 17:53:28 Daemon.Notice 192.168.178.1 openvpn[3297]: /sbin/route del -net 192.168.200.0 netmask 255.255.255.0
01-21-2007 17:53:28 Daemon.Notice 192.168.178.1 openvpn[3297]: /sbin/route del -net 192.168.1.0 netmask 255.255.255.0
01-21-2007 17:53:28 Daemon.Notice 192.168.178.1 openvpn[3297]: TCP/UDP: Closing socket
01-21-2007 17:53:28 Daemon.Notice 192.168.178.1 openvpn[3297]: Inactivity timeout (--ping-restart), restarting

evtl. sieht einer den Fehler
Gruss
Schmide

[MicAlter]

@knox:
Ich habe immer noch ein Problem mit der "crl.pem"... obwohl ich diese nicht angegeben bzw. nichts eingetragen habe, meldet mir der OpenVPN-Server bei einem Verbindungseingang den Fehler, dass er die Datei nicht findet...

Ich habe nun nach der "easy-rsa" Anleitung eine crl.pem mit einem Dummy-Zertifikat erzeugt (man kann offenbar keine "leere" Datei erzeugen) und in die WebConfig eingetragen. Nun läuft alles wunderbar.

Kannst Du das nachvollziehen? Oder mache ich noch irgendwas falsch?

[knox]

@knox:
Ich habe immer noch ein Problem mit der "crl.pem"... obwohl ich diese nicht angegeben bzw. nichts eingetragen habe, meldet mir der OpenVPN-Server bei einem Verbindungseingang den Fehler, dass er die Datei nicht findet...

hast du ganz sicher die letzte version im einsatz? denn: wenn keine crl.pem im webinterface eingetragen wird, dann wird auch diese option nicht in die config geschrieben. der fehler sollte also gar nicht mehr auftreten.

zur sicherheit kannst du noch mal prüfen, ob es die datei /var/flash/crl.pem gibt und sie ggf löschen.

[MicAlter]

hast du ganz sicher die letzte version im einsatz?...

zur sicherheit kannst du noch mal prüfen, ob es die datei /var/flash/crl.pem gibt und sie ggf löschen.

Ich bin mir ->wirklich<- sicher, dass ich die letzte Version im Einsatz habe:

/usr/sbin $ ./openvpn --version
OpenVPN 2.1_rc1 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jan 17 2007
Developed by James Yonan
Copyright (C) 2002-2005 OpenVPN Solutions LLC <info@openvpn.net>
/usr/sbin $

Ich habe im /var/flash nachgeschaut, aber keine crl.pem gefunden. Laut /mod/etc/openvpn-lzo.conf sollte diese in /tmp/flash/crl.pem liegen - aber die meintest Du sicherlich...

Dort liegt meine crl.pem mit dem Dummy-Zertifikat. Ich habe diese nun mal gelöscht und bin in die WebConfig gegangen. Wahrscheinlich habe ich das Problem bereits gefunden:
- Da keine crl.pem vorliegt ist die Textbox entsprechend leer.
- WENN ich nun -ohne eine Eingabe zu machen - auf "Übernehmen" klicke, dann schreibt er eine 1-Byte große crl.pem in /tmp/flash !
- Da kommt beim Verbindungsaufbau die Meldung: "CRL: cannot read CRL from file /tmp/flash/crl.pem"

-> Ohne diese Datei, da gebe ich Dir recht, funktioniert der Verbindungsaufruf korrekt.

Anmerkung1:
Vielleicht wäre im nächsten Update die Möglichkeit gegeben, das Einbinden der Datei über eine Checkbox zu realisieren.

Anmerkung2:
Ich war etwas verwundert, dass er nicht die Meldung mit der fehlenden Datei gebracht hat...sehr komisch, aber 100%ig plausibel...aber zumindest hat die Frage einen anderen "mini"-Bug zum Vorschein gebracht...

[knox]

Ich bin mir ->wirklich<- sicher, dass ich die letzte Version im Einsatz habe:

meine frage bezog sich auf die ds-mod package version. einfach diesen thread hier aufmerksam lesen und du weisst, was ich meine...

Ich habe im /var/flash nachgeschaut, aber keine crl.pem gefunden. Laut /mod/etc/openvpn-lzo.conf sollte diese in /tmp/flash/crl.pem liegen - aber die meintest Du sicherlich...

genau, die meine ich.

- WENN ich nun -ohne eine Eingabe zu machen - auf "Übernehmen" klicke, dann schreibt er eine 1-Byte große crl.pem in /tmp/flash !

das ist blöd.

-> Ohne diese Datei, da gebe ich Dir recht, funktioniert der Verbindungsaufruf korrekt.

so soll es sein. seit dem letzten update für das ds-mod package ist in openvpn-lzo_conf eine abfrage eingebaut, welche die entsprechende option nur in die config schreibt, wenn die datei vorhanden ist.

Ich war etwas verwundert, dass er nicht die Meldung mit der fehlenden Datei gebracht hat...sehr komisch, aber 100%ig plausibel...

das ist nicht komisch. siehe oben.

aber zumindest hat die Frage einen anderen "mini"-Bug zum Vorschein gebracht...

welchen mini bug meinst du jetzt?

[MicAlter]

meine frage bezog sich auf die ds-mod package version. einfach diesen thread hier aufmerksam lesen und du weisst, was ich meine...

Da habe ich wohl was falsch verstanden. Ich dachte, dass Deine Frage auf das letzte OpenVPN-Patch (0.6b) abzielt...natürlich lese ich diesen und andere Threads sehr aufmerksam

Ich setze aber z.Zt. nicht die aktuellste dsmod-Version ein, die Oliver hier beschreibt (siehe Signatur). Grund: Falls das mit dem OpenVPN mal nicht richtig funktioniert, möchte ich noch über die AVM VPN Lösung Zugriff auf mein Netz haben. Und Oliver schreibt ja, dass nur die Versionen 29.04.29 + 30 genutzt werden können. Toolchain usw. sind zwar schon erzeugt, aber die VPN-Firmware passt ja leider nicht...

welchen mini bug meinst du jetzt?

Mini-Bug in Form der 1-Byte großen Datei. Wenn man einmal dieses Problemchen hatte, da macht man den Fehler bestimmt kein 2. Mal...

Ich hatte unwissenderweise keine gültigen Daten in die Config eingetragen und die Änderungen übernommen. Als ich das Problem dann gefunden hatte, habe ich kurzerhand die fehlerhaften Daten gelöscht - in der Annahme, dass nun a) keine Datei geschrieben wird und b) der VPN-Server ohne die Option startet.