[Problem] Freetz/OpenVPN Client, Routen auf Fritz.Box

[wambolino]

Hallo,

ich habe auf der FB mit Freetz OpenVPN als Client laufen, und möchte damit 2 ferne Subnetze tunneln. VPN-Server ist ein RaspberryPi (auch DNS/DHCP) hinter einem Speedport Router (böse)
(FB: 192.168.178.x, Speedport: 192.168.2.x, VPN 10.8.0.x)

Ich habe auf dem Pi schon per NAT routen erstellt so dass ich von Clients aus auf Server-Nachbarn zugreifen kann. (Andersherum geht (noch) nicht :-/)
Die VPN configs sollten auch passen.

Was jetzt noch fehlt, wären Routen in der FB auf sich selbst, bzw. auf das tunnel-Interface, für alles was ans Speedport-Subnetz oder ans VPN Subnetz geht.
Ich habe schon im Freetz/OpenVPN Paket unter Portforwarding (was ich ja als CLient nicht brauche) gesehen, dass die FritzBox routen auf sich selbst per Webinterface nicht zulässt.
Es wurden Methoden genannt (die wohl veraltet sind) und erwähnt dass sich mit aktuellen FWs die Methode geändert hat.

Jetzt die Frage: wie stelle ich solche routen an meiner Fritzbox/Freetz ein? Braucht es ein extra Paket? (ist Ip-forward geeignet?) könnte ich mit NAT arbeiten wie auf Server Seite? Und wie gebe ich das NAT der Fritzbox zu futtern?

Falls irgendwas unklar ist, kann ich auch gerne nochmal ein Schaubild oder VPN-configs geben.

 

[MaxMuster]

Du möchtest von der FB (oder aus dem Netz an der FB ?) auf Netze "hinter" dem VPN-Server?
Dazu brauchst du zweierlei:
- Die Fritzbox muss diese Netze ins VPN routen. Das kann z.B. in der Freetz Seite für die Client Konfiguration gemacht werden ("Entferntes Netz", da können auch per Semikolon getrennt mehrere Netze eingetragen werden)
- Die anderen Netze und der "Server" müssen das Netz bei deiner Fritzbox zu dieser Box routen. Das geht analog in der Konfiguration des Servers, ist aber von der genauen Konfig abhängig. Du brauchst auf dem Server immer ein "route <dein LAN> <Netzmaske des LAN>" und ggf. noch einen iroute-Eintrag, (im Client-Config-Dir oder per connect-script) wenn es eine Mulit-Client Config ist.

Das ist aber letztlich "OpenVPN-Standard" und unabhängig vom Freetz ;-)

 

[wambolino]

Ja, fast. Ich möchte von Nachbarn der Fritzbox auf (ein) Netz hinter dem VPN Server.
Soweit ich das verstanden habe, siehe LINK, dienen die route (dieses Subnet über VPN) bzw. iroute (server: welches SUbnet zu welchem client)einträge nur für VPN, bzw. den Kernel sobald das ganze schon am VPN "Interface" angekommen ist. Also wenn ich Pakete an der Fritzbox starte, dann geht das klar.
Damit Pakete an 192.168.2.x ankommen, die irgendwo im 192.168.178.x gestartet sind, müssen diese ans VPN Interface geroutet werden, oder? Also angenommen mein VPN Server sitzt nicht in der Fritzbox, diese notwendige "physische" route fehlt mir - klar, dass das dann nur ankommenden Paketen an eth0 sagt: jo ihr geht direkt ans tun0. Falls das nicht nötig ist, dann muss was an meiner Konfig nicht stimmen.

Edit: ja stimmt, zweimal mein Fehler:
- "The last step, and one that is often forgotten, is to add a route to the server's LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won't need this if the OpenVPN server box is the gateway for the server LAN)." Sprich, das was ich dachte, ist nicht nötig. Aber es funktioniert trotzdem nicht:

- ich habe das >push "route 192.168.178.0 255.255.255.0"< noch auskommentiert gehabt, wenn ich das "aktiviere", dann funktioniert mein ganzes Client1 Subnetz nicht mehr. (Ich sitze gerade dort, und kam nicht mehr ins Internet und nicht mehr auf den Client1 = Fritz.box, bei früheren Tests wo Client1 nicht gleich Router, ging nur der Client nicht mehr)

Hier mal meine server.conf

;local a.b.c.d
port 1196
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key  # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
# Sage Clients, Ips aus Subnet per VPN zu routen
push "route 192.168.2.0 255.255.255.0"
client-config-dir ccd
# Sage anderen Clients, Ips aus Subnet(Client1) per VPN zu routen
# in ccd muss 'client1-file' liegen in dem 'iroute 192.168.178.0 255.255.255.0' steht  
# Das sagt VPN welches Subnet, zu welchem Client geroutet werden soll
# -> Scheint auch dem Client1 (oder allen im Client 1 Subnetz) die Möglichkeit zu nehmen, lokale Nachbarn zu erreichen
# push "route 192.168.178.0 255.255.255.0"
# Auch Server soll wissen dass Ips aus Subnet per VPN gehen sollen
route 192.168.178.0 255.255.255.0
#ALLEN Traffic per VPN leiten
;push "redirect-gateway"
#Clients zusätzlichen DNS WINS Server durchgeben
#push "dhcp-option DNS 192.168.2.2"
#push "dhcp-option WINS 192.168.2.2"
client-to-client
keepalive 20 120
;tls-auth ta.key 0 # This file is secret
cipher AES-128-CBC   # AES
comp-lzo
;max-clients 10
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log
log         /var/log/openvpn.log
verb 5 
;mute 20
tls-server

Client1-Config:

client
dev tun
proto udp
remote DYNDNS PORT
#resolv-retry infinite
#nobind
#user nobody
#group nobody
persist-key
persist-tun
mute-replay-warnings
#ns-cert-type server
#tls-auth ta.key 1
cipher AES-128-CBC    #Wie server
comp-lzo    #Wie Server
verb 3
mute 10
pull
# to use Keys and Certs from GUI here are samples
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem

Aber eigentlich hat das Problem nichts mehr mit der Fragestellung zu tun :-/

 

[MaxMuster]

Also ...

Der Client (hier deine FB) muss "nur" das Zielnetz durch das VPN routen. Das macht er, wenn in seiner Konfig ein "route" für das Netz steht, oder (wie bei dir) wenn ihm der Server per "push" diese Route zukommen lässt. Damit "weiß der Client Bescheid" und kann routen. Sofern dieser VPN-Client auch zugleich das "Defaultgateway" im Netz ist, ist auf dieser Seite alles fertig, ansonsten muss das Defaultgateway das Netz "hinter dem VPN-Server" zur Fritzbox routen.
So, jetzt kommen die Pakete für das Zielnetz aus deinem LAN zum VPN Server, der weiß natürlich auch, wo das Zielnetz ist, und schickt alles weiter.

Zweiter Schritt: Aus dem Zielnetz muss "dein LAN" wieder zurück zu dir. Also muss es zum VPN und damit gilt analog zu oben: "Dein LAN" muss zum OpenVPN-Server. Ist der das Default-Gateway, dann ist alles gut, ist er es nicht, muss in dem Gateway auf der "Server-Seite" eine Route eingetragen sein: Dein LAN zum OpenVPN-Server routen.
Der VPN-Server wiederum braucht in deinem Fall "zwei Routen". Die eine für den Kernel, damit die Pakete für dein LAN zum VPN-Prozess gelangen. DAs erfolgt in der Konfig des OpenVPN-Servers mittels "route 192.168.178.0 255.255.255.0". Das erzeugt die Route in der "normalen" Routingtabelle. Damit der Server, der potenziell viele Clients bedient, weiß "wohin damit", gibt es den "iroute" Eintrag, der laut deiner Konfig auf dem Server im Ordner "ccd" (der Parameter "client-config-dir ccd"). Dort muss also eine Datei exakt mit dem Namen "deines" Zertifikates (der CN [Common Name] in deinem Client-Zertifikat) existieren, in der der "iroute" Eintrag steht.

Heißt also der CN in deinem Zertifikat "Wambos_FB", so muss die Datei "ccd/Wambos_FB" existieren, z.B. so:

# ClientConfigDir Datei für Wambos_FB
push "route 192.168.2.0 255.255.255.0"
iroute 192.168.178.0 255.255.255.0

Zuletzt: Ja, ein push "route 192.168.178.0 255.255.255.0" ist nicht so toll, dass heißt, wenn es zu deinem Client kommt, ja "schicke alles für 192.168.178.0 ins VPN". Das ist eine gute Idee, wenn das dein LAN ist ;-).
Das wäre aber u.U. ein "guter" Parameter für einen anderen Client, falls dieser dein Netz durch das VPN erreichen soll. Dann gehörte dieser "push"-Befehl sinnvollerweise in dessen "ccd-Datei", damit dieser Client das Netz (dein LAN) zum VPN-Server schickt.

 

[wambolino]

Der Client (hier deine FB) muss "nur" das Zielnetz durch das VPN routen. Das macht er, wenn in seiner Konfig ein "route" für das Netz steht, oder (wie bei dir) wenn ihm der Server per "push" diese Route zukommen lässt. Damit "weiß der Client Bescheid" und kann routen. Sofern dieser VPN-Client auch zugleich das "Defaultgateway" im Netz ist, ist auf dieser Seite alles fertig, ansonsten muss das Defaultgateway das Netz "hinter dem VPN-Server" zur Fritzbox routen.
So, jetzt kommen die Pakete für das Zielnetz aus deinem LAN zum VPN Server, der weiß natürlich auch, wo das Zielnetz ist, und schickt alles weiter.

Check. Das funktioniert ja eigentlich problemlos.

Zweiter Schritt: Aus dem Zielnetz muss "dein LAN" wieder zurück zu dir. Also muss es zum VPN und damit gilt analog zu oben: "Dein LAN" muss zum OpenVPN-Server. Ist der das Default-Gateway, dann ist alles gut, ist er es nicht, muss in dem Gateway auf der "Server-Seite" eine Route eingetragen sein: Dein LAN zum OpenVPN-Server routen.
Der VPN-Server wiederum braucht in deinem Fall "zwei Routen". Die eine für den Kernel, damit die Pakete für dein LAN zum VPN-Prozess gelangen. DAs erfolgt in der Konfig des OpenVPN-Servers mittels "route 192.168.178.0 255.255.255.0". Das erzeugt die Route in der "normalen" Routingtabelle. Damit der Server, der potenziell viele Clients bedient, weiß "wohin damit", gibt es den "iroute" Eintrag, der laut deiner Konfig auf dem Server im Ordner "ccd" (der Parameter "client-config-dir ccd"). Dort muss also eine Datei exakt mit dem Namen "deines" Zertifikates (der CN [Common Name] in deinem Client-Zertifikat) existieren, in der der "iroute" Eintrag steht.

Antworten (=zurück) kommen ja an. Weil der VPN Server natted, und damit das Default Gateway ans bekannte Subnetz routet. Aber wenn eine Anfrage direkt an "mein LAN" = Clientlan kommt das Problem, dass ich auf VPN-Serverseite das Default-Gateway nicht beeinflussen kann. Das werde ich vorerst mit NAT / routen auf den Server-Nachbarn einzeln machen müssen. (Ist hier jetzt aber evtl. schon zu weit vom Topic weg?)

Also die ccd/client1 existiert und die iroute steht dort auch schon drin. Client1 ist auch sicher der CN

Wo ist denn der Unterschied zw. dem push in der server.conf und dem ccd/client1, wenn client1 praktisch durchgehend verbunden ist? Warum ist es "nicht so toll", ist aber eine gute Idee wenn es mein LAN ist?
(Zerstört mir diese route die "Verbindung untereinander im 178er? Warum wird das dann so im Howto beschrieben?)
Es ist doch bei allen Clients eine gute Idee, die sich nicht in einem 192.168.178er Subnetz befinden, aber mit diesem kommunizieren sollen, oder?
Ich habe aber keine Möglichkeit gesehen es auszuschließen für client1, also müsste ich es bei allen clients manuell in die config mit reinnehmen (außer client1) ?

Ich habe mich eigentlich ans OpenVPN Howto gehalten:

Next, ask yourself if you would like to allow network traffic between client2's subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.

client-to-client
push "route 192.168.4.0 255.255.255.0"​

This will cause the OpenVPN server to advertise client2's subnet to other connecting clients.

cat /etc/openvpn/ccd/client1
iroute 192.168.178.0 255.255.255.0
#dhcp-option DNS 192.168.178.1
#dhcp-option WINS 192.168.178.1

Oder anders gefragt? Was mache ich denn jetzt falsch? Was fehlt?

 

[MaxMuster]

Das "push" in der Server-Config bekommen alle Clients --> hier sollten z.B. die LANs "hinter dem Server" stehen.

Die pushs im CCD gehen immer an einen speziellen Client, und für "alle anderen" (außer deinem eigenen) ist es "gut", Pakete für "dein LAN" zum Server zu schicken, damit er das dann zu dir weiterleitet. Nur du selbst solltes deine LAN-Pakete im LAN behalten und lieber nicht zum Server schicken...
(Gilt natürlich immer nur bei verschiedenen LANs bei den Clients, sonst geht das eh nicht ...)

Und, sofern du auf einzelne Geräte willst und die direkt mit dem OpenVPN-Server verbunden sind, kannst du natürlich auch "dein LAN" vom Server direkt zum VPN-Server routen.

 

[wambolino]

Ah, okay, ich hatte im Kopf, dass die ccd eine Erweiterung der server.conf ist, die immer nur dann ausgeführt wird, wenn der entsprechende Client verbunden ist.
Auch hab ich irgendwie angenommen, bei deiner beispiel ccd wäre das 178er Netz drin, aber das 2er ist ja überflüssig, das steht ja schon in meiner server.conf drinnen = für alle.
Wenn ich nur bestimmte Clients haben möchte die aufs Server-Netz kommen müsste ich das so handhaben.

Ich komme immer ein bisschen mit "dein LAN" durcheinander. Beides sind meine LANs^^ Aber du meinst damit das Client LAN.

Und, sofern du auf einzelne Geräte willst und die direkt mit dem OpenVPN-Server verbunden sind, kannst du natürlich auch "dein LAN" vom Server direkt zum VPN-Server routen.​

Ich nehme an hier fehlt "Zugriff auf" oder? "direkt verbunden" = VPN-Clients ? Von welchem Server zum VPN-Server?

Vom Verständnis (das jetzt glaub ich langsam da ist XD) abgesehen: Was läuft denn im Moment falsch? Warum kann ich nicht vorgehen wie im VPN-Howto beschrieben? (push "route ... im server.conf)
Und wie sollte ich vorgehen? Für jeden ANDEREN Client eine ccd-File anlegen und die route durchgeben?


​

 

[MaxMuster]

Ich meinte: Wenn der Server den (oder allgemein: die Geräte, die) du vom "Client LAN" durch das VPN erreichen willst (ich nenne sie mal "Ziele"), in ihrem LAN direkt den OpenVPN-Server erreichen können. Denn (nur) dann kannst du (wie du schon geschrieben hattest) diesen Geräten auch direkt eine Route für das "Client-LAN" eintragen, auf den OpenVPN-Server
Bsp.: Der OpenVPN-Server hat 192.168.2.3; die "Zielsysteme" sind 192.168.2.50 und 192.168.2.75. Damit sind ja alle im LAN 192.168.2.0 und du kannst
nicht nur auf dem "Defaultgateway" eintragen: "Route 192.168.178.0 zu 192.168.2.3, sondern alternativ auf allen "Zielen" dieses Routing einrichten.

Meiner Meinung ist das Howto da nicht ganz korrekt, denn die Default-Metrik für eine Route ist 0, genauso wie "direkt verbunden". Damit hättest du "identisch gute" Routen für dein LAN.
Umgehen könntest du das (nicht ausprobiert, nur aus der Doku) z.B. mit einem Eintrag für die Metrik in der Server-Config, wenn du "dein Client LAN" auf dieser Ebene "an alle" per push schickst:

push "route-metric 10"

Damit bekommt alle (auch dein VPN-Client) die Route für dein LAN, eine evtl. vorhandene "bessere Route" (z.B. ein direkt angeschlossenes Netzwerk) würde aber bevorzugt, die Route kann dann "nichts kaputt machen".

 

[wambolino]

Also kann ich dieses
push "route-metric 10"
zum
push "route 192.168.178.0 255.255.255.0"
in die server.conf dazugeben, und mal testen ob immer noch der Client1 (..178.1) durchdreht?

 

[MaxMuster]

Ja, so warst gedacht.
Da du (wenns nicht geht) deinen Zugriff auf die Box verlierst, kannst du (wenn das die einzige FB im Netz ist) auch die Adresse von "lan:0" ansprechen (die 169.254.1.1) oder über "ein anderes Netz" auf die FB (du kannst ja z.B. mit "ifconfig lan:2 192.168.123.1" und analogem Befehl auf einem PC die 192.168.123.4 vergeben,) dann "kann nix passieren".
Alternativ geht "Internet weg" oder (wenn das OpenVPN nicht auf "automatisch" steht) Box neu starten.

Ziel wäre, dass ein "route -n" dir zwei Routen für 192.168.178.0/24 anzeigt, eine mit Metric "0" am lan, eine mit "10" an tun.

 

[wambolino]

Jo, ich teste das sofort.
Oh ja! Sieht doch schonmal gut aus.

192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.178.0   10.8.0.5        255.255.255.0   UG    10     0        0 tun0

- - - Aktualisiert - - -

Es geht immer weiter OT, aber leider kommen vom Server keine Pings an den Client1 an. Auch nicht ans Clientnetz
Von Server-Nachbarn an den Client1 ganz zu schweigen.
:-/ Ideen?


Edit: Ich habe die Config von Client1 jetzt mal an einem Rechner im FritzBox Subnetz getestet. In der FB stat. routen gesetzt (10.8.0.0 und 192.168.2.0 auf ClientIP)
Jetzt kann ich aber, sobald verbunden, keine IPs im eigenen Subnetz (192.168.178.0 ) mehr erreichen. :-/
Woran kann das nun wieder liegen?
Leider Auch vom VPN Server aus - erreiche ich keine 178er IP

 

[sf3978]

Edit: Ich habe die Config von Client1 jetzt mal an einem Rechner im FritzBox Subnetz getestet. ...
Leider Auch vom VPN Server aus - erreiche ich keine 178er IP

Kannst Du vom VPN-Server aus, den Rechner (VPN-Client) im FB-Subnetz, über seine 178er-IP-Adresse (per Ping) erreichen?

 

[wambolino]

Nein, auch das nicht.

Achja: aktuelle config: (habe aber glaub ich nichts geändert)

clientdev tun
proto udp
remote XXXXXX
#resolv-retry infinite
#nobind
#user nobody
#group nobody
persist-key
persist-tun
mute-replay-warnings
#ns-cert-type server
#tls-auth ta.key 1
cipher AES-128-CBC    #Wie server
comp-lzo    #Wie Server
verb 3
mute 10
pull




# to use Keys and Certs from GUI here are samples
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem

Über Dinge am Server (pi) bin ich auch in einem Thread im Rasberrypi-Forum bis zu diesem Problem gekommen:
http://www.forum-raspberrypi.de/Thread-raspbian-noobs-openvpn-zugriffe?pid=243334#pid243334

 

[MaxMuster]

Bitte prüfe auf jeden Fall mal das Log des Servers, ob da was zu sehen ist. Wenn die Client-Config im CCD nicht gezogen wird, siehst du bei den Versuchen aus dem 192.168.178.-er Netz sowas wie "MULTI: bad source address from client [x.x.x.x], packet dropped".
Ohne Zugriff auf das Server-Log könntest du eine "besondere" Route in dieser Config pushen (z.B. push "route 1.2.3.4") um zu sehen, ob die bei dir auftaucht...

Ein Traceroute wäre auch gut um zu sehen, wie weit du jeweils kommst, also ob du den VPN-Server/VPN-Client erreichst, wenn es durch das VPN gehen soll ...

[EDIT]
Zu deinem Edit: Vielleicht klappt das vom PC-Client nicht, weil das da mit der Metric nicht klappt, und der so das lokale Netz wieder "wegroutet"? Wenn du da weiter forschen willst: Wie sieht dann die Routingtabelle aus, wenn das VPN "steht"?
[/EDIT]

[EDIT2]
Wegen "kommen keine Pings an" hilft auf jeden Fall der Trace. Auch können (besonders z.B. bei Windows-Geräten) Pings aus "fremden Netzen" wegen der internen Firewall auch unbeantwortet bleiben, obwohl sie eigentlich "ankommen". Deshalb ist ein Ping/Trace auf die "LAN-IP" der Fritzbox im Netz 192.168.178. immer ein guter erster Schritt...
[/EDIT2]

 

[wambolino]

Also Zugriff auf das Server log habe ich.

Ja gaaaanz viele:

RTue Oct  4 13:23:28 2016 us=585049 Client1/ÜWANIP*:36602 MULTI: bad source address from client [192.168.178.27], packet dropped

.27 ist der Rechner an dem ich gerade sitze. Wollte nicht die gesamte Log posten, die bläht sich als ziemlich auf.

Traceroute vom Server aus auf Client-Subnetz IP? nichts - danach auf Client-VPN-IP

pi@raspberrypi:~ $ traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  * * *
...
30  * * *
pi@raspberrypi:~ $ traceroute 10.8.0.6
traceroute to 10.8.0.6 (10.8.0.6), 30 hops max, 60 byte packets
 1  10.8.0.6 (10.8.0.6)  45.706 ms  45.915 ms  46.643 ms

Vom Client auf Server-Nachbar:

root@fritz:/var/mod/root# traceroute 192.168.2.100traceroute to 192.168.2.100 (192.168.2.100), 30 hops max, 38 byte packets
 1  10.8.0.1 (10.8.0.1)  40.980 ms  40.087 ms  39.406 ms
 2  192.168.2.100 (192.168.2.100)  40.006 ms  40.104 ms  40.107 ms

 

[MaxMuster]

"MULTI: bad source address from client [192.168.178.27]" heißt: Der iroute-Eintrag "wird nicht gezogen".

Prüfe bitte nochmals, ob der Pfad zum ccd stimmt und ob der Name "richtig" ist (Klein- und Großschreibung beachten !).
Im Server-Log sollte stehen, wie der Client "heißt", darauf hin nochmal den Dateinamen prüfen.

Oben schreibst du "... ccd/client1 existiert..." laut Log heisst der Client1 (großes C)

 

[wambolino]

Ah Herr im Himmel!
Ja, stimmt!

Geil! Ping von VPN-Server und Server-Nachbar (2.100) geht auf Client und Client Nachbar (178.27)
Außerdem Ping von Client Nachbar auf Server (2.2) Server-Nachbar, der eine Route auf 178.0 hat (2.100)
Sehr geil!

Ich hätte noch ein paar Fragen nebenbei zu optionen, ich denke es lohnt nicht dazu noch einen extra Thread zu eröffnen.

#push "dhcp-option DNS 192.168.2.2"
#push "dhcp-option WINS 192.168.2.2"

Überschreiben diese den eigentlichen DNS oder werden sie "hinten angefügt?"
Erreichen will ich, dass ich vom einen Subnetz auch hosts des anderen Auflösen kann (und umgekehrt)
(Edit: irgendwo gesehen, dass dies den Primären DNS Server ersetzt / einträgt. Möglicherweise nur beim TUN/TAP-Device/Interface.

tls-server / tls-client
tls-auth ta.key 0/1

Ergänzen sich die Optionen oder sollte ich nur eines benutzen?
Edit: Ergänzen! Ersteres gilt für den ersten Handshake, letzteres für extra Layer HMAC

#ns-cert-type server

Ebenso: zusätzlich oder Alternativ?
Edit: Zusätzlich, aber das Server-Cert muss entsprechend gestaltet sein (meins anscheinend nicht)

Das Freetz-Interface bietet noch Static-Key, ist das im Prinzip die ta.key?
-> Ja: 'tls-auth /tmp/flash/openvpn/static.key 1'
Läuft jetzt bei mir !


Interessant ist noch, dass ich in der FB die optionen 'user nobody' 'group nobody' nicht setzen darf, sonst kann er nicht starten / behauptet er würde nicht laufen (Im Interface unter Dienste)



Eben noch getestet mit nem zusätzlichen Roadwarrior-Client: Kann Server- und Client1-Nachbarn anpingen! Geil!

 

[MaxMuster]

Das Meiste hast du ja selbst rausbekommen, trotzdem ein paar Hinweise/Erklärungen:

"tls-server / tls-client" <-- ist für TLS ein "zwingender" Parameter (Client oder Server, einer muss sein ;-))
"tls-auth ta.key 0/1" <-- ist optionaler Parameter, der "zusätzliche Sicherheit" bietet. Die "Richtung" (0/1) muss auf den beiden Seiten "verschieden" sein
"ns-cert-type server" <-- erzwingt, dass das Zertifikat beim Server auch ein "Serverzertifikat" ist





Den User nobody muss es auf der FB nicht zwingend geben; OpenVPN auf der FB läuft "standardmäßig" mit User und Group "openvpn".