@thbo
Du zitierst Fehlermeldungen vom openvpn -mktun. Genau das passiert bei mir auch wenn ich diesen Befehl ein zweites mal ausführe (nachdem er bereits vom debug.cfg ausgeführt wurde). Dieser Befehl legt ein netzwerk interface tap0 an, was man mittels ifconfig sehen kann, und kann/muss nach einen Reboot genau einmal ausgeführt werden. Ist also normal.
Lass doch openvpn auf dem PC mal mit --verb n laufen. n=4,5 oder 6 und schau mal was passiert. Beispiel: openvpn --verb 5 --config openvpn-clnt.cfg
Für die Optionen siehe auch
http://openvpn.net/man.html.
Dann mal eine Verbindung aufbauen. Das geht überigens nicht vom internen Netz wenn man beim remote-befehl in der client-config die externe Addresse angibt (was ja normal ist). Für den Test also am besten zusätzlich per Modem einwählen. Oder in der client config im remote-befehl fritz.box angeben. Dann sollte der Log irgendwann mal den Erfolg vermelden: Initialization Sequence Completed.
Tut er dass dann sollte der Tunnel stehen und man kann nach weiteren Problemem suchen wie "keine Addresse zugewiesen".
Ich denke der Clientlog reicht zum analysieren, aber du kannst zusätzlich auch auf der Box mehr Einblick kriegen, indem du den vom debug.cfg gestarteten openvpn killst (killall openvpn) und ihn genauso startest wie in debug.cfg aber mit --verb n und ohne --daemon.
mfg Michael
ps: wenn's nicht klappt, dann schick mir mal dein Logfile und ich schau mal ob ich was sehe.
pps: ich sehe gerade dass ich das PC openvpn-config file auch mit Unix-Zeilenende-konvention erstellt habe. Sorry. Am besten dann mit einem Editor bearbeiten der das kann wie z.B. textpad, der sich über
http://www.heise.de/software/ finden laesst.