Openvpn 2 Verbindungen

Edelhacker

Neuer User
Mitglied seit
20 Jan 2006
Beiträge
15
Punkte für Reaktionen
0
Punkte
0
Ich würde gerne auf meiner Fritzbox 2 Openvpn-Verbindungen gleichzeitig halten. Dazu habe ich 2 Client Konfigurationen angelegt.
Immer wenn ich die 2. mit
Code:
/var/tmp/vpn/openvpn --cd /var/tmp/vpn --config speedy.conf --daemon ovpn-speedy --dev-node /dev/misc/net/tun1 &
starte, bleibt der erste Daemon zwar im Speicher, aber die Verbindung bricht zusammen. Nur die gerade gestartete zum 2. Server bleibt erhalten.
Wie kann ich 2 Verbindungen mit der Fritzbox halten?
 
Meine Vermutung geht in dieselbe Richtung, dass ich eine Ressource explizit zuweisen muss. Der Port ist es aber definitiv nicht, weil es sich ja um 2 Clients handelt.
 
Okay, Problem gelöst.

Die 2. openvpn Instanz putzt nur die Routen der ersten aus der Tabelle. Weil ich keine Option gefunden habe, ihr das abzugewöhnen, füge ich sie in der debug.cfg durch 2 entsprechende route add commands wieder hinzu.
 
Edelhacker schrieb:
füge ich sie in der debug.cfg durch 2 entsprechende route add commands wieder hinzu.

Dafür gibt es die route Optionen in den Configs ;)
 
AndreR schrieb:
Dafür gibt es die route Optionen in den Configs ;)
Was genau sind "route Optionen"? Ich hab nirgendwo einen Hinweis auf sowas gefunden.

Ich hab auch das Problem, dass eine zweite OpenVPN-Verbindung auf meiner Fritz!-Box 7170 die Route der vorherigen Verbindung entfernt.

Ich kriegs bisher nicht hin, dass mehrere Verbindungen gleichzeitig klappen.

Auch scheint es so zu sein, dass die route add-Anweisung in der debug.cfg keine dauerhafte Lösung ist.

Spätestens, wenn die Zwangstrennung kommt, verschwinden diese.

mfg Ulrich Scheske
 
In der Client-Config z.B. kann man folgende Zeile einfügen:

Code:
route 192.168.179.0 255.255.255.0
in diesem Fall ist der Server im Netz 192.168.179.x beheimatet...

Dann routet das Interface selbstständig
 
AndreR schrieb:
In der Client-Config z.B. kann man folgende Zeile einfügen:

Code:
route 192.168.179.0 255.255.255.0
in diesem Fall ist der Server im Netz 192.168.179.x beheimatet...

Dann routet das Interface selbstständig
Danke für den Tip, aber soweit war ich auch schon.

Vielleicht erstmal die Aufgabenstellung:
Im Moment gibt es vier Netze, die gekoppelt werden sollen, später auch noch mehr.
Jedes hat eine Fritz!Box 7170 oder 7050 mit aktueller Firmware 29.04.15.
Im ersten Schritt soll ein Netz die Zentrale bilden (Server) an dem die anderen angeschlossen sind.
Später soll es auch Querverbindungen geben.
Auf dem Servernetz habe ich 3 Instanzen von OpenVPN (neueste Version von hier geladen) nach Anleitung von http://www.tecchannel.de/ eingerichtet.
Jede hat eine eigene Portnummer.
Und im Prinzip funktioniert das auch so.
Aber: Sobald die zweite Instanz startet, wird die Route der ersten Instanz gelöscht und so weiter.
Damit geht das Routing nur zu einer Box und das ist mein Problem.
Ich kann zwar das Routing mit "route add ..."-Befehlen ans Laufen kriegen und das klappt dann wunderbar.
Aber spätestens bei der nächsten Zwangstrennung ist wieder Schluß.

Ich bin bis jetzt noch nicht dahintergekommen, wie man das richtig macht.
Zuerst beschäftigt mich: Ist es überhaupt richtig, mehrere Instanzen zu verwenden und wenn es nur mit einer gehen muss, wie sieht die Konfigurationsdatei aus?
Und spätestens, wenn die Client-Installationen gekoppelt werden, hab ich Client- und Server-Konfiguationen auf einer einzelnen Box.
 
Zuletzt bearbeitet:
Puh, 3 Serverinstanzen, das ist ne ganze Menge.

Ich empfehle dir dringend(!!) auf eine Multi-Client-Lösung mit Zertifikaten umzubauen. Die COnfig ändert sich teilweise doch massiv, gerade auf Serverseite.

Als Empfehlung sei dir die Anleitung von Hellspawn gegeben: Klick mich
 
Meine Lösung ist das route-up Kommando in der client config.

Sobald die route für die 1. Verbindung nach der Zwangstrennung steht, (und somit die anderen Routen gelöscht wurden,) füge ich sie mit route-up wieder hinzu (alle bis auf die aus der config in der das route-up steht).
 
Erstmal Danke für die Antworten.
Das mit dem route-up hat erstmal mein Problem gelöst.
Allerdings funktioniert das nur mit einem route-delay 5 (kleinere Werte hab ich jetzt nicht getestet).

Das Umstellen auf eine Multi-Client-Lösung halte ich auch für die bessere Lösung, da immer mehr Serverinstanzen (jetzt 4!) irgendwann die Kapazität der Fritz!Box sprengen.
Allerdings ist das nicht so schnell zu erreichen, da die Cleints meistens räumlich getrennt sind.
Das kompliziert das Testen erheblich.

Ich hab in meinem Zentralnetz noch einen Windows 2003 Server, der als OpenVPN-Server nicht so leicht an Grenzen stößt.
Damit werde ich das Multi-Client mal testen, er könnte allerdings auch bei der Mehrinstanzen-Version gute Dienste leisten.

Mal gucken...
 
Hi,

ich glaube ich habe auch so ein ähnliches Problem. Bei mir ist der Server eine Fritzbox 5140. Daran hängen über zwei Openvpn Verbindungen zwei Red Hat 9 Server. Jedesmal nach der Zwangstrennung stehen zwar die tun0 und tun1 Devices und die Hauptrouten. Leider fehlt bei der zweiten Verbindung die Gateway Route. Ich habe in der config auch schon mit route-delay gearbeitet. Wenn ich die Fritzbox rebooten würde, läuft alles wieder einwandfrei.

Gibt es da irgendeinen Trick?
 
Wäre interessant, wenn Du Deine Konfiguration posten könntest.

Ob es einen "Trick" gibt, weiß ich nicht, aber auf der openvpn.net Website (Howto 2) ist beschrieben wie's geht ;).
 
Leider fehlt bei der zweiten Verbindung die Gateway Route.
Ich hatte ja das gleiche Problem.
Die Lösung war die neue Firmware mit dem 2.6 Kernel.
Mit dieser Firmware (.29) und dem dazu passenden OpenVPN lief das dann endlich einwandfrei.
Das wird Dir aber nicht weiterhelfen, denn für Deine 5140 gibt es die ja (noch) nicht.

Ich hatte vorher auch mit dem route-delay rumprobiert (s.o.), aber war zum Schluß doch nicht erfolgreich.
Es ging zwar erst, aber fiel dann doch ständig aus, mit den von Dir beschriebenen Symptomen.

Ich hab jetzt ein Netz aus 8 Fritz!-Boxen (eine ist meine, 7 Verbindungen, 5x7170 und 2x 7050). Demnächst kommen noch zwei dazu.
Die laufen wirklich rund.

Ich bin jetzt dabei, alle Fritz!-Boxen untereinander zu vernetzen.
Die beiden 7050 muß ich dabei außen vorlassen, die haben auch noch den alten Kernel und können nur 1 Verbindung.

Um die auch zu vernetzen, route ich die Verbindung zu den 7050 über eine einzige Fritz!-Box.

Beispiel mit 4 Boxen:
A, B und C: 7170
D: 7050
Ich verbinde A mit B, A mit C und A mit D.
Dann noch B mit C.
Die Boxen A, B und C bilden jetzt ein Dreieck, alle Pakete laufen den direkten Weg.
Die Pakete von B und C nach D laufen aber über A.
Verstanden bis hier?
Das ist zwar nicht performant und alles andere als optimal, weil dabei die Bandbreite von A benutzt wird.
Aber es läuft.

@Invader2004: vielleicht kannst Du das ähnlich machen?
Die 5140 wird nur mit einem Red Hat 9 Server verbunden und erreicht den anderen über ein Weiter-Routen?
Das würde solange helfen, bis AVM auch für die 5140 die neue Firmware bereitstellt.
 
Hi,

erstmal gibt es hier die Configs ...

client 1 (Red Hat 9)
remote fritzbox.xxx.xxx
dev tun0
ifconfig 192.168.250.3 192.168.250.1
secret /etc/openvpn/secret.key
daemon
ping-restart 60
ping 5
float
proto udp
mssfix
port 5002
route 192.168.178.0 255.255.255.0 vpn_gateway

client 2 (Red Hat 9)
dev tun0
ping 30
ping-restart 60
remote fritzbox.xxxx.xx
float
mssfix
ifconfig 192.168.250.2 192.168.250.1
secret /etc/openvpn/secret.key
proto udp
port 5001
route 192.168.178.0 255.255.255.0 vpn_gateway

Server Fritz Box
config File 1
dev tun0
dev-node /dev/misc/net/tun
ifconfig 192.168.250.1 192.168.250.3
tun-mtu 1500
float
mssfix
remote server1.xxxx.xxxx

#Pfad zum Key File
secret /var/tmp/secret.key

#Protokoll auf TCP und Port 1194
proto udp
port 5002

#Protokollierung auf 4
verb 4

daemon
#Routen setzen, bei route Subnetz des Clients eintragen
route 192.168.0.0 255.255.255.0 vpn_gateway

#Verbindung erhalten
ping 15
ping-restart 120

config File 2
dev tun1
dev-node /dev/misc/net/tun
ifconfig 192.168.250.1 192.168.250.2
tun-mtu 1500
float
mssfix
remote server2.xxxxx.xxxx

#Pfad zum Key File
secret /var/tmp/secret.key

#Protokoll auf TCP und Port 1194
proto udp
port 5001

#Protokollierung auf 4
verb 4

daemon
#Routen setzen, bei route Subnetz des Clients eintragen
route 192.168.200.0 255.255.255.0 vpn_gateway
route-delay 90

#Verbindung erhalten
ping 15
ping-restart 120

Die Tunnel werden dann nacheinander in der debug.cfg gestartet.

So sieht die Tabelle nach nem Reboot aus..
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.250.2 * 255.255.255.255 UH 0 0 0 tun1
192.168.250.3 * 255.255.255.255 UH 0 0 0 tun0
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 * 255.255.255.0 U 0 0 0 lan
192.168.0.0 192.168.250.3 255.255.255.0 UG 0 0 0 tun0
192.168.200.0 192.168.250.2 255.255.255.0 UG 0 0 0 tun1
default * 0.0.0.0 U 2 0 0 dsl
#

und so nach einer Zwangstrennung ...
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.250.2 * 255.255.255.255 UH 0 0 0 tun1
192.168.250.3 * 255.255.255.255 UH 0 0 0 tun0
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 * 255.255.255.0 U 0 0 0 lan
192.168.0.0 192.168.250.3 255.255.255.0 UG 0 0 0 tun0
default * 0.0.0.0 U 2 0 0 dsl
#
 
Zuletzt bearbeitet:
Sieht kompliziert aus.
Wenn ich das richtige sehe, brauchst Du auf dem Server zwei Instanzen von OpenVPN auf zwei verschiedenen Ports

Warum machst Du es nicht so, wie im OpenVPN 2.0 HOWTO beschrieben.
Das funktioniert bei mir tadellos. Die Anleitung sieht lang aus, ist aber sehr ausführlich und man muss nicht alles lesen.
 
Hallo nochmal,

ich bin hier gerade am verzweifeln. Anstelle der zwei RedHat Server ist jetzt nur noch einer vorhanden, zu dem auch alles einwandfrei funktioniert. Der andere wurde durch eine mit dem Ds-Mod geimpften Speedport W701v ersetzt. Am Kopf des Ganzen sitzt eine FB 5140.

Es gibt also insgesamt drei Netze

Netz 1 192.168.178.0 mit FB 5140
Netz 2 192.168.0.0 mit RedHat 9
Netz 3 192.168.200.0 mit Speedport W701v

Die Netze werden über zwei Tunnel verbunden. Nun zum Problem: Bei der Verbindung 5140 zum W701v soll eigentlich der udp Port 5001 verwendet werden. So steht es zumindestens in den Configs. Nach dem Start "bestätigen" beide quasi den Port 5001 und das die Verbindung steht. Doch dann passiert folgendes. Einer von beiden will nur noch an dem Port 61000 oder 61008 oder 61038 lauschen. Der Port scheint irgendwie willkürlich gewählt.

Log der ersten Box
Thu Aug 30 11:12:21 2007 us=959421 OpenVPN 2.1_rc4 mipsel-linux [SSL] [LZO2] [EPOLL] built on Aug 11 2007
Thu Aug 30 11:12:21 2007 us=969585 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Aug 30 11:12:21 2007 us=970937 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Aug 30 11:12:21 2007 us=974031 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Aug 30 11:12:21 2007 us=975911 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Aug 30 11:12:22 2007 us=206227 TUN/TAP device tun0 opened
Thu Aug 30 11:12:22 2007 us=207438 TUN/TAP TX queue length set to 100
Thu Aug 30 11:12:22 2007 us=208791 /sbin/ifconfig tun0 192.168.250.1 pointopoint 192.168.250.2 mtu 1500
Thu Aug 30 11:12:22 2007 us=282514 /sbin/route add -net 192.168.200.0 netmask 255.255.255.0 gw 192.168.250.2
Thu Aug 30 11:12:22 2007 us=348681 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Thu Aug 30 11:12:22 2007 us=350010 Socket Buffers: R=[110592->131072] S=[110592->131072]
Thu Aug 30 11:12:22 2007 us=351092 UDPv4 link local (bound): [undef]:5001
Thu Aug 30 11:12:22 2007 us=352130 UDPv4 link remote: 84.129.227.118:5001
Thu Aug 30 11:12:22 2007 us=355481 UDPv4 WRITE [60] to 84.129.227.118:5001: DATA len=60
Thu Aug 30 11:12:22 2007 us=442605 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Thu Aug 30 11:12:22 2007 us=443153 UDPv4 READ [-1] from [undef]: DATA UNDEF len=-1
Thu Aug 30 11:12:26 2007 us=8494 UDPv4 READ [60] from 84.129.227.118:61055: DATA len=60
Thu Aug 30 11:12:26 2007 us=9686 Peer Connection Initiated with 84.129.227.118:61055
Thu Aug 30 11:12:26 2007 us=10202 Initialization Sequence Completed
Thu Aug 30 11:12:26 2007 us=12314 UDPv4 READ [76] from 84.129.227.118:61055: DATA len=76
Thu Aug 30 11:12:26 2007 us=15971 UDPv4 READ [92] from 84.129.227.118:61055: DATA len=92

Log der zweiten:
Thu Aug 30 11:12:25 2007 us=664570 OpenVPN 2.1_rc4 mipsel-linux [SSL] [LZO2] [EPOLL] built on Aug 11 2007
Thu Aug 30 11:12:25 2007 us=674524 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Aug 30 11:12:25 2007 us=675808 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Aug 30 11:12:25 2007 us=678195 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Aug 30 11:12:25 2007 us=680221 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Aug 30 11:12:25 2007 us=841106 TUN/TAP device tun0 opened
Thu Aug 30 11:12:25 2007 us=842254 TUN/TAP TX queue length set to 100
Thu Aug 30 11:12:25 2007 us=843534 /sbin/ifconfig tun0 192.168.250.2 pointopoint 192.168.250.1 mtu 1500
Thu Aug 30 11:12:25 2007 us=914647 /sbin/route add -net 192.168.178.0 netmask 255.255.255.0 gw 192.168.250.1
Thu Aug 30 11:12:25 2007 us=986424 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Thu Aug 30 11:12:25 2007 us=988908 Socket Buffers: R=[109568->131072] S=[109568->131072]
Thu Aug 30 11:12:25 2007 us=989928 UDPv4 link local (bound): [undef]:5001
Thu Aug 30 11:12:25 2007 us=991386 UDPv4 link remote: 79.204.29.250:5001
Thu Aug 30 11:12:25 2007 us=994460 UDPv4 WRITE [60] to 79.204.29.250:5001: DATA len=60
Thu Aug 30 11:12:25 2007 us=997567 UDPv4 WRITE [76] to 79.204.29.250:5001: DATA len=76
Thu Aug 30 11:12:26 2007 us=458 UDPv4 WRITE [92] to 79.204.29.250:5001: DATA len=92

Wo finde ich die Einstellung über diesen mysteriösen Port?? Ich steh gerade am Bahnhof. Was mir noch aufgefallen ist. Je nach dem welche Box zu erst den Tunnel startet, schaltet dann den merkwürdigen Port.

Ich hatte erst versucht eine Multi-Client Lösung zu verwenden, doch da taucht dieses Problem auch auf und es funktionierte leider kein Tunnel von beiden. :noidea:
 
Hm, ich sehe das Problem scheinbar nicht. Der "mysteriöse" Port ist der "Absende-Port" des Clients, der (ganz korrekt) auf den Port 5001 sendet (zu sehen z.B. hier am READ: UDPv4 READ [76] from 84.129.227.118:61055).

Jörg
 
ich wiederhole meine Frage:
Warum machst Du es nicht so, wie im OpenVPN 2.0 HOWTO beschrieben¿
Das funktioniert einwandfrei mit den Fritzboxen.
Die Anleitung findest Du auf der OpenVPN.net Website.
 

Statistik des Forums

Themen
244,693
Beiträge
2,216,639
Mitglieder
371,311
Neuestes Mitglied
agl7
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.