[Gelöst] Freetz OpenVPN mit TUN und mehreren clients

TheBadFish

Neuer User
Mitglied seit
10 Sep 2006
Beiträge
69
Punkte für Reaktionen
0
Punkte
6
Hallo zusammen,

Ich habe bis dato mit einer recht ähnlichen Konfiguration recht gute Erfahrungen gemacht, (dev tun und secret/static key), möchte jetzt jedoch mehr als einen Client anbinden und komme deshalb mit static key nicht mehr weit.

Mit folgender Konfiguration kann ich den Router auf der IP 192.168.200.1 sowie auf der 192.168.179.1 ohne Probleme anpingen:

devtun_cert_1client.jpg

Ab hier fangen jedoch die Probleme an.
Füge ich in die Liste der Clients einen zweiten Client hinzu, ohne die maximale Anzahl der Clients zu erhöhen und ändere sonst nichts, wird mir in die openvpn.conf folgendes eingetragen:

Code:
/var/mod/root # cat /mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Wed Jun 22 11:59:41 CEST 2011
proto udp
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
port 55213
[COLOR="red"]ifconfig 192.168.200.1 255.255.255.0[/COLOR]
mode server
client-config-dir /var/tmp/clients_openvpn
topology subnet
push "topology subnet"
max-clients  1
push "route 192.168.179.0 255.255.255.0 192.168.200.1"
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
daemon
cipher BF-CBC
comp-lzo
keepalive 10 120

Die rot markierte Zeile sorgt dann freundlicherweise dafür, dass beim connect eines Clients folgende Fehlermeldung geworfen wird

Code:
Wed Jun 22 12:01:12 2011 WARNING: Since you are using --dev tun, the second argument to --ifconfig must be an IP address.  You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)
Wed Jun 22 12:01:12 2011 There is a problem in your selection of --ifconfig endpoints [local=192.168.200.5, remote=255.255.255.0].  The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet.  This is a limitation of --dev tun when used with the TAP-WIN32 driver.  Try 'openvpn --show-valid-subnets' option for more info.
Wed Jun 22 12:01:12 2011 Exiting

Ändere ich die Einstellungen jetzt zurück, indem ich den zusätzlichen Client wieder lösche, bleibt die openvpn.conf jedoch so wie oben gepostet fehlerhaft bestehen. Hab ich da einen Bug entdeckt?

Erst wenn ich im Webinterface auf Standard zurückschalte und alle Einstellungen neu wie oben im Screenshot setze, kann ich mich wieder mit einem Client verbinden.

Wie kriege ich es hin, dass sich mehrere Clients verbinden können? Eigentlich bin ich kein Vollhonk was Netwerktechnik angeht, aber ich verzweifle gerade irgendwie. Sämtliche gescheiten Howtos die ich gefunden habe, erklären entweder die Kombination TUN und static key, oder alternativ TAP und Zertifikate.

Dass es irgendwie möglich ist, weiss ich, denn ein Freund von mir hat auf seinem ipcop ein openvpn am Laufen, der mit Zertifikaten und Routing arbeitet. (Seh ich ja an meiner Client Config.

Der Vollständigkeit halber noch meine Client Conf:
Code:
remote xxxx 55213
proto udp
dev tun
ca ca.crt
cert client02.crt
key client02.key
tls-client
port 55213
client
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
keepalive 10 120
comp-lzo

Hoffe ihr könnt mir weiterhelfen. Hardwareconfig siehe Signatur.

Gruß, Sebi
 
Zuletzt bearbeitet:
"Erweiterte Clientconfig" und/oder "max-clients" > 1 setzt "topology subnet" voraus (siehe die Config beim Server).
Da dein Client scheinbar die Parameter nicht per "pull" holt (oder er die nicht kennt), müsstest du den Parameter hinzufügen. Das geht aber erst mit einer OpenVPN-Version ab 2.1 (oder entsprechend gepatchetem Client, genaueres hier bei --topology).

Jörg
 
Tatsache, Client Update gemacht und pull in die client conf aufgenommen, jetzt sind beide Clients verbunden. Bis hier hin auf jeden Fall mal Danke für den Tipp!

Leider komm ich jetzt nur bis an die IP der Fritzbox (192.168.179.1). Weiter gehts nicht. (Die 192.168.179.20 von der aus ich gerade schreibe, erreiche ich nicht, auch nicht wenn ich in der Fritzbox noch eine statische Route dazupacke.)

Die Route beim Client wird erzeugt, die 179.1 erreich ich ja...
Code:
C:\>route print
IPv4-Routentabelle
(...)
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
    192.168.179.0    255.255.255.0    192.168.200.1    192.168.200.9     30
    192.168.200.0    255.255.255.0   Auf Verbindung     192.168.200.9    286
    192.168.200.9  255.255.255.255   Auf Verbindung     192.168.200.9    286
  192.168.200.255  255.255.255.255   Auf Verbindung     192.168.200.9    286
===========================================================================
(...)
 
Sieht eigentlich ok aus. Könnte es die Firewall beim PC sein, den du erreichen willst? Der VPN Client kommt ja aus einem anderen IP-Netz...
Ansonsten mach mal einen Trace vom Client zum PC. Ist der erste Hop die VPN-IP der Box?

Jörg
 
Firewall kann es nicht sein. Die Windows Firewall ist auf beiden Maschinen ausgeschaltet, auch sonst sind nirgendwo Application Layer Firewalls am Laufen.

Ich schließe auch sonst alles aus, was nicht mit dem Tunnel zu tun hat, denn mit static key funktioniert es ja ohne Probleme und wurde von mir in der Form monatelang genutzt.

Traceroute vom VPN Client aus:
Code:
C:\>tracert 192.168.179.1

Routenverfolgung zu 192.168.179.1 über maximal 30 Abschnitte

  1    54 ms    54 ms    54 ms  192.168.179.1

Ablaufverfolgung beendet.

Traceroute vom VPN Client aus:
Code:
C:\>tracert 192.168.179.20

Routenverfolgung zu 192.168.179.20 über maximal 30 Abschnitte

  1    53 ms    54 ms    53 ms  192.168.200.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        * 
^C

Allerdings habe ich jetzt noch etwas interessantes festgestellt: Wenn ich in der Fritzbox eine statische Route von 192.168.200.0/255.255.255.0 über 192.168.200.1 einrichte, dann komm ich vom Client im LAN aus auf den VPN Client. Andersrum geht trotzdem nicht. Jetzt bin ich komplett verwirrt.

Traceroute vom Client im LAN aus:
Code:
C:\Windows\System32>tracert -d -4 192.168.200.9

Routenverfolgung zu 192.168.200.9 über maximal 30 Abschnitte

  1    <1 ms    <1 ms    <1 ms  192.168.179.1
  2    55 ms    54 ms    54 ms  192.168.200.9

Ablaufverfolgung beendet.

Ich glaube ich baue mal noch einen tcpdump ins freetz ein...
 
Der Trace ist o.k. und die Pakete gehen durch das VPN. Das Problem liegt also nicht am VPN, sondern woanders.
Wenn ich in der Fritzbox eine statische Route von 192.168.200.0/255.255.255.0 über 192.168.200.1 einrichte, dann komm ich vom Client im LAN aus auf den VPN Client.
Wie, und sonst nicht? Das Aktivieren des VPN müsste doch die Route für das angeschlossene Netz eintragen?!?
Wie sieht denn die Routingtabelle auf der Box aus ("route -n")?

Jörg
 
Hm,

bis gerade eben ging das definitiv nicht. Ich hab vorhin mal die Box neugestartet weil sie meinen USB Drucker nicht mehr erkennen wollte. Jetzt komm ich vom LAN Client auch ohne statische Route an den VPN Client. Kein Plan, mir solls recht sein. Die Route wird jetzt jedenfalls erzeugt:

Code:
/var/mod/root # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
84.1xx.xxx.xxx   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.179.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
[COLOR="red"]192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0[/COLOR]
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl
/var/mod/root #

Am Verhalten auf Seite des VPN Client ändert sich da allerdings nichts. die 1 krieg ich angepingt, die 20 nicht.
 
Also wenn du vom "LAN-PC" den "VPN-PC" anpingen kannst, funktioniert die Verbindung ja in beiden Richtungen:
LAN->VPN für die Ping-Anfrage (Echo request) und
VPN->LAN für die Ping-Antwort (Echo reply)

Daher bliebe ja eigentlich wirklich nur, dass der LAN-PC auf die Anfrage vom VPN nicht antwortet, denn der Trace zeigt, dass das Paket vom VPN-Client in Richtung LAN-PC ja zumindest bis zur Box kommt (ansonsten bleibe nur, dass die Box die Pakete nicht an den PC weiterleitet, was aber ja beim Ping mit den Antworten klappt)...

Jörg
 
Schande über mein Haupt. Die Windows Firewall am LAN-PC war doch an. :doof: Ping geht, Freigaben gehen, super.

Was ich dann jetzt aber immer noch nicht kapiere ist, warum es zuvor überhaupt funktioniert hat. Da hab ich per static key und openvpn einen Tunnel am Start gehabt und der hat anstandslos funktioniert. Und zwar in beide Richtungen. Ping, mstsc, windows-share,....

Nunja, dir aber trotzdem tausend Dank.

(Ich merke mal wieder dass ich Hardwareentwickler für integrierte Schaltungen bin und kein Netzwerkinformatiker ;) )
 
Das ist in der Tat sehr merkwürdig, nur mit "TAP" wäre es klar (weil der Client dann virtuell im gleichen Netz sein könnte).
Aber warum nachkarten, wenn's geht, ist doch alles gut ;-)
 
Richtig. Und ich bin glücklich, dass ich wieder alle Ports bis auf einen an meiner Box zumachen kann. :) Super.

Schönen Feiertag noch. :bier:
 
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.