Hallo an alle,

Wenn ich einen 2ten Remote Eintrag (Dyndns) in meiner ClientConfig mache und versuche mit dem Server zu verbinden tritt auf der Server Seite folgende Fehlermeldung
auf: Connection refused (code=111)

Nehm ich den Eintrag raus funktioniert alles einwandfrei.
Hat jemand eine Idee??

einen zweite Eintrag auf die gleiche Maschine (Server) ?
ein zweiter Eintrag auf eine zweite (Server) Maschine funktioniert prima. Beo Provoiderausfall connect der automatisch um auf den zweiten Weg - allerdings: zwei openVPN-Server, die "parallel" laufen (na gut, andere Addressen, andere Routen...aber Zugang zum gleichen Netz)


F.

Nein nur einen Server, 2 Router mit dyndns die auf den Server weiterleiten!
ich habe auf meinen clients einen 2ten dydns Eintrag. Wenn der erte Eintrag nicht verfügbar ist soll sich der Client über den zweiten dyndns mit meinem Server connecten.
Das geht aber definitiv nicht der Client läuft bis:
Wed Mar 10 20:56:49 2010 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Wed Mar 10 20:56:49 2010 MANAGEMENT: TCP Socket listening on 127.0.0.1:7505
Wed Mar 10 20:56:58 2010 LZO compression initialized
Wed Mar 10 20:56:58 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Mar 10 20:56:58 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Mar 10 20:56:58 2010 Local Options hash (VER=V4): '41690919'
Wed Mar 10 20:56:58 2010 Expected Remote Options hash (VER=V4): '530fdded'
Wed Mar 10 20:56:58 2010 UDPv4 link local: [undef]
Wed Mar 10 20:56:58 2010 UDPv4 link remote: dyndns1:1194

Und auf dem Server wird eben diese Fehlermeldung ausgegeben.

Meine CientConfig:
client
dev tun
proto udp
port 1194
management localhost 7505
remote DYNDNS1 1194
remote DYNDNS2 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:\\openvpn\\config\\ca.crt
cert C:\\openvpn\\config\\client1.crt
key C:\\openvpn\\config\\client1.key
ns-cert-type server
comp-lzo
verb 3
pull
auth-user-pass
auth-nocache
route-method exe ##<-- diese Einträge
route-delay 2 ##<-- waren nötig um xp und vista zu routen

Ein Computer kann grundsätzlich nur einen Router als Standardgateway verwenden.

Der Server kann nicht eine Verbindung von einer anderen IP übernehmen
(dyndns1 und Dyndns2 sind ja unterschiedliche IP/Verbindungen)..von dem Rest mag ich gar nicht reden...
Gehen tut, wenn du 2 openVPN-Server laufen lässt (fast die simpelste Lösung)
man könnte z.B. ein Alix-Board mit IPCop+Zerina(=openVPN-Server + GUI) verwenden.
2 mal DSL-Zugang - 2 Modems, 2 Router (auf denen ein openVPN-Server läuft), dann funktioniert dein Plan..und Modem/Router brauchst du bei DSL so oder so...und es ist eine relativ günstige Lösung ( o.k. man kann auch openVPN auf WRT-Router oder wohl auch Fritzboxen laufen lassen..? sagt man).

F.

Also noch mal:

client ---> router DYNDNS1(router1 Firmennetz) Dyndns2(router2 Firmennetz)
| __________________ |
+
|
OPENVPN-SERVER (Firmennetz)
Dem Windowsclient ist es wohl egal ob ich DYNDNS1 oder DYNDNS2 eintrage!?
Ich verbinde vom Home-Office über einen!! Router. In der HOWTO steht eindeutig drin, dass am Client mehrere Remote eingetragen werden können die dann wahlweise benutzt werden wenn der andere nicht verfügbar ist und genau dass klappt nicht. Der Router1 läßt zwar den UDP durch aber der Server stellt sich stur wenn vorher die Verbindung über Dyndns2 lief.

Hallo

Der Server antwortet auf jedes Paket von außerhalb über seinen Standardgateway und das kann eben nur 1 Router sein, entweder Router 1 oder 2, nehmen wir an der Server hat Router 1 eingestellt:
Wenn du eine Verbindung von außen über Router 2 initiierst, dann kommt zwar das erste UDP Paket am Server an (weil Router 2 das Paket direkt an den Server weiterleiten kann). Jedoch versucht dann der Server über sein Standardgateway (Router 1) dem Client zu antworten. Der sieht, dass das Paket von einer falschen Source-IP (Router 1) kommt und verwirft es.

Ein bekanntes Routingproblem, da Antwortpakete bei IP nicht zwangsweise den selben Weg zurück nehmen müssen wie die eingehenden Pakete.

und genau das geht so ..siehe mein Vorschlag oben.
Damit umgehst du auch das Routingproblem, weil du auf jedem openVPN-Server mit einem anderen Addressbereich kommst.
Hier läuft openVPN auf einigen Maschinen als Dienst und bei Providerausfall ist zwar die Verbindung weg, d.h. offene Files werden u.U. nicht gespeichert, aber ansonsten ist der Client im Minutenbereich wieder da, oft ohne das der User es merkt

F.