OpenVPN-Paket

[wildbat]

Ich hatte auch das gleiche Problem.
So kann man das ständige reboot vermeiden.

1. DSL Leitung trennen
2. unter fritz.box:81 anmelden
3. Pakete / Openvpn wählen und den Starttype auf Manuell stellen
4. Jetzt noch unter Dienste openvpn stoppen

Jetzt könnt ihr wieder ins Internet um die neue Firmware zu laden

[Alphaman]

Hi Leute,

ich will bei mir auf der 7170 OpenVPN einrichten, nur leider hab ich damit groessere Probleme damit.

Ich hab nicht viel veraendert, nur die dyndns Adresse eingetragen unter der der Server zu erreichen ist und die IP Netzadresse unter dem der Server läuft.

Den Static Key hab ich in der Box selber berechnen lassen und mittel winscp runtergezogen und im Menü eingetragen.

Wenn ich nun den Server starten will bekomme ich nur failed als antwort ;(

Ich hab die ds-mod 0.2.9 am laufen.

Kann mir einer Helfen. Dickes Danke schonmal im voraus.

Cu,
Alphaman

[supamicha]

ein paar beiträge weiter oben steht die lösung : http://www.ip-phone-forum.de/showthr...=101980&page=5

[Alphaman]

Jo, da steht die lösung. Vor lauter threads findet man die lösungen nicht mehr. Leider hab ich die alter Firmware nicht mehr und auf dem avm server ist nur noch die neue und mit der lässt sich das ds-mod nicht mehr generieren.

Hat evtl einer die alter Firmware noch. Oder sollte man evtl noch bissel warten da es evtl bald ein update beim ds-mod evtl gibt.

[lord-of-linux]

Ich habe noch irgend welche alten. Aber du kannst natürlich auch die aktuellste Labor nehmen: http://www.ip-phone-forum.de/showthread.php?t=117670

[MicAlter]

Hi,

habe nun das dsmod 0.2.9-26-10 mit der Labor-Firmware xxx-5550_Labor an laufen bekommen. Habe nur ein arges Problem mit OpenVPN - warum ich auch hier gelandet bin...

Ich habe einen Static.Key erzeugt, in die Weboberfläche eingefügt und eine simple Client-Config erzeugt.

Der Verbindungsaufbau geht erst einmal durch, doch erscheint immer im Syslogd die Meldung:

openvpn[2038]: Authenticate/Decrypt packet error: packet HMAC authentication failed


Meine Client-Config sieht so aus:

remote xxx.dyndns.org 1194

port 1194
proto udp
dev tap                           ("tun" ebenfalls erfolglos)
keysize 160                       (mal rein mal raus, keine Änderung)
ifconfig 10.0.0.2 10.0.0.1
secret static.key
cipher BF-CBC
auth SHA1
comp-lzo                          (ist serverseitig ebenfalls eingestellt)
keepalive 10 60
verb 6

Kann mir jemand weiterhelfen???

[hermann72pb]

"proto udp" könnte dein Fehler sein. lord-of-linux hatte sich damals für tcp entschieden. Warum auch immer. Ich hatte es schon seit ewigen Zeiten kritisiert. Durch Webinterface kannst du es noch nicht umstellen. Also serverseitig ist "proto tcp" fest vorgegeben. Außerdem nicht vergessen den Port 1194 auf der Box freizugeben. Als tcp eben. Es können auch andere Fehler da sein.

[phoenix.tom]

"proto udp" könnte dein Fehler sein. lord-of-linux hatte sich damals für tcp entschieden. Warum auch immer. Ich hatte es schon seit ewigen Zeiten kritisiert.

Was gibt es daran zu kritisieren?
Warum sollte man eine VPN-Connection über das verbindungslose UDP machen?
Wäre ja völlig widersinnig...
Bei UDP werden keine Pakete neu übertragen, da es kein ACK gibt.

[knox]

Warum sollte man eine VPN-Connection über das verbindungslose UDP machen?
Wäre ja völlig widersinnig...

das ist zufälliger weise das default-protkoll von openvpn. und das ist sogar sehr sinnvoll.
außerdem kann man es im ds-mod webinterface beliebig wählen.

[phoenix.tom]

und das ist sogar sehr sinnvoll.

und warum soll das sogar sehr sinnvoll sein?

[knox]

Da vor Übertragungsbeginn nicht erst eine Verbindung aufgebaut werden muss, können die Hosts schneller mit dem Datenaustausch beginnen. Dies fällt vor allem bei Anwendungen ins Gewicht, bei denen nur kleine Datenmengen ausgetauscht werden müssen.

http://de.wikipedia.org/wiki/UDP

[hermann72pb]

Zitat von http://www.linux-magazin.de/Artikel/...n/openvpn.html

Zum Tunneln von TCP/IP ist ein verbindungsloses Protokoll wie UDP am besten geeignet: Es vermeidet, dass die Timeouts der OpenVPN- sowie der gekapselten TCP-Verbindung gleichzeitig ablaufen, was schlimmstenfalls zu einer ganzen Lawine an Retry-Paketen führt. Firewalls und Router in Unternehmen oder Internetcafés verbieten aber meist, dass Clients UDP-Pakete aus dem Internet empfangen. Die einzige Alternative ist daher, auf TCP auszuweichen. Damit kann jedoch nur noch der Client den Aufbau des VPN anstoßen.

Zum TCP als default kann ich nichts sagen, liest doch bitte

http://openvpn.net/howto.html

Da wird tcp nur als Notlösung empfohlen

Aber wenn es funzt, kann ich nichts gegen sagen, ist eure Entscheidung. Ich bleibe bei UDP.


MfG

Hermann

[phoenix.tom]

http://de.wikipedia.org/wiki/UDP

Logisch hat TCP einen Overhead. Dennoch benötigt man für eine garantierte Verbindung TCP, genau WEGEN des Overheads.

Wenn die Verbindung nicht gerade stabil wird, muss sich die Software auf den höheren Layern darum kümmern, daß Pakete neu angefordert werden. Das führt dazu, daß die schon schlechte Leitung noch mehr belastet wird.

Außerdem hat UDP kein congestion control.

[knox]

liest doch bitte

http://openvpn.net/howto.html

Da wird tcp nur als Notlösung empfohlen

.

[phoenix.tom]

Es vermeidet, dass die Timeouts der OpenVPN- sowie der gekapselten TCP-Verbindung gleichzeitig ablaufen, was schlimmstenfalls zu einer ganzen Lawine an Retry-Paketen führt.

Das ist ein Argument.
Aber is ja wie schon geschrieben jedem seine eigen Wahl.

[knox]

Das ist ein Argument.

das argument wurde schon genannt, aber du wolltest ja lieber herum diskutieren.

[phoenix.tom]

das argument wurde schon genannt, aber du wolltest ja lieber herum diskutieren.

Is ja schon gut. Immer locker bleiben.

EDIT: Außerdem, wenns schon genannt wurde hätte ein Link auch gereicht, statt es nochmals zu posten.

[knox]

Is ja schon gut. Immer locker bleiben.

http://de.wikipedia.org/wiki/Locker ??

[MicAlter]

Da ich bereits das OpenVPN mit Zertifikaten mit einer älteren Firmware erfolgreich nutzen konnte (siehe hier) - alter Kernel, OpenVPN 2.0.5, und Zertifikate. Ebenfalls mit UDP.
Die ar7.cfg habe ich mir in einer Telnet-Session anzeigen lassen und die korrekte Firewalleinstellung von Port 1194 gefunden. Daran sollte es also nicht liegen...

Die Änderung sind ja nun an einigen Ecken zu finden:
- OpenVPN 2.1_rc1 (Server und Client) mit LZO-Komprimierung
- Static Key

Ich habe den OpenVPN-Server mal neu gestartet und versucht eine Verbindung aufzubauen. Der Syslog-Client hat folgende Meldung erhalten:

Notice		openvpn[374]: OpenVPN 2.1_rc1 mipsel-linux [SSL] [LZO2] [EPOLL] built on Dec  5 2006
Warning		openvpn[374]: WARNING: file '/tmp/flash/static.key' is group or others accessible
Notice		openvpn[374]: Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Notice		openvpn[374]: Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Notice		openvpn[374]: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Notice		openvpn[374]: Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Notice		openvpn[374]: LZO compression initialized
Notice		openvpn[374]: TUN/TAP device tun0 opened
Notice		openvpn[374]: TUN/TAP TX queue length set to 100
Notice		openvpn[374]: /sbin/ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2 mtu 1500
Notice		openvpn[374]: /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.0.2
Notice		openvpn[374]: Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
Notice		openvpn[381]: Socket Buffers: R=[110592->131072] S=[110592->131072]
Notice		openvpn[381]: UDPv4 link local (bound): [undef]:1194
Notice		openvpn[381]: UDPv4 link remote: [undef]
Error		openvpn[381]: Authenticate/Decrypt packet error: packet HMAC authentication failed
Error		openvpn[381]: Authenticate/Decrypt packet error: packet HMAC authentication failed
...

Die abschließende Zeile erscheint immer, wenn der Client ein UDP-Paket sendet.

Der Client schreibt die folgenden Daten in Log:

us=78000  OpenVPN 2.1_rc1 Win32-MinGW [SSL] [LZO2] built on Oct 31 2006
us=168000 Static Encrypt: Cipher 'BF-CBC' initialized with 160 bit key
us=168000 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
us=168000 Static Decrypt: Cipher 'BF-CBC' initialized with 160 bit key
us=168000 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
us=168000 LZO compression initialized
us=339000 WARNING: Since you are using --dev tap, the second argument to --ifconfig must be a netmask, for example something like 255.255.255.0. (silence this warning with --ifconfig-nowarn)
us=339000 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{AFE8F9B4-96D3-4A13-9D08-45B7A4AD490A}.tap
us=349000 TAP-Win32 Driver Version 8.4 
us=349000 TAP-Win32 MTU=1500
us=349000 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.0.0.1/10.0.0.2 on interface {AFE8F9B4-96D3-4A13-9D08-45B7A4AD490A} [DHCP-serv: 10.0.0.0, lease-time: 31536000]
us=349000 Successful ARP Flush on interface [196615] {AFE8F9B4-96D3-4A13-9D08-45B7A4AD490A}
us=349000 Data Channel MTU parms [ L:1577 D:1450 EF:45 EB:135 ET:32 EL:0 AF:3/1 ]
us=349000 Local Options String: 'V4,dev-type tap,link-mtu 1577,tun-mtu 1532,proto UDPv4,ifconfig 10.0.0.0 10.0.0.2,comp-lzo,cipher BF-CBC,auth SHA1,keysize 160,secret'
us=349000 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1577,tun-mtu 1532,proto UDPv4,ifconfig 10.0.0.0 10.0.0.2,comp-lzo,cipher BF-CBC,auth SHA1,keysize 160,secret'
us=349000 Local Options hash (VER=V4): 'cf524d59'
us=349000 Expected Remote Options hash (VER=V4): 'cf524d59'
us=349000 Socket Buffers: R=[8192->8192] S=[8192->8192]
us=359000 UDPv4 link local (bound): [undef]:1194
us=359000 UDPv4 link remote: xxx.xxx.xxx.xxx:1194
us=359000 UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=715000 TUN READ [42]
us=715000 UDPv4 WRITE [84] to xxx.xxx.xxx.xxx:1194:  DATA len=84
us=436000 TUN READ [42]
us=436000 UDPv4 WRITE [84] to xxx.xxx.xxx.xxx:1194:  DATA len=84
us=437000 TUN READ [42]
us=437000 UDPv4 WRITE [84] to xxx.xxx.xxx.xxx:1194:  DATA len=84
us=163000 UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=377000 UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=377000 UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=13000  UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=13000  UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=648000 UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=648000 UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=472000 UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=472000 UDPv4 WRITE [60] to xxx.xxx.xxx.xxx:1194:  DATA len=60
us=365000 Inactivity timeout (--ping-restart), restarting
us=365000 TCP/UDP: Closing socket
us=365000 Closing TUN/TAP interface
us=375000 SIGUSR1[soft,ping-restart] received, process restarting
us=375000 Restart pause, 2 second(s)

Und hier nochmal eine Client-Config:

remote xyz.dyndns.org 1194

port 1194
proto udp
dev tap

keysize 160
ifconfig 10.0.0.1 10.0.0.2
secret static.key
cipher BF-CBC
auth SHA1
comp-lzo
keepalive 10 60
verb 6

Hat noch einer eine Idee? Oder kann mir kurz jemand mitteilen, wie er sein OpenVPN ans laufen bekommen hat. Also in dieser Konstellation: Labor-Firmware mit dsmod mit OpenVPN 2.1_rc (Server/Client).

EDIT: Noch ne Frage hinterher: Wie habt ihr (unter Windows) euren Static Key erzeugt?

Viele Grüße,
MicAlter

[olistudent]

Wenn das schonmal funktioniert hat, dann nehme ich mal an, dass du nicht diesen Anfängerfehler gemacht hast, oder?

MfG Oliver