Frage zu OpenVPN Konfiguration über Freetz GUI

[maceis]

Hallo zusammen,

ich habe seit etlichen Jahren OpenVPN in einer Server-Client Konfiguration mit mehreren Clients am Laufen (insgesamt 5 Fritzboxen an unterschiedlichen Standorten).
Authentifizierung läuft über Zertifikate.
Ich habe das damals alles händisch eingerichtet, also nicht über die Freetz (bzw. ds-mod) Oberfläche.
Das Routine zwischen den 5 Netzen läuft ohne Probleme,

Nun ist ein Standort mit einer weiteren Box dazu gekommen, den ich über die Freetz Weboberfläche konfiguriert habe.
Der neue openvpn Client authentifiziert sich ordentlich und auch die Routen werden gepullt.
Nur: Die Verbindung zum neuen Netz funktioniert nicht; ich kann noch nicht mal pingen und zwar weder vom Server noch von den anderen Clients aus.

Ich komm leider nicht drauf, woran das liegen kann und würde mich über einige Denkanstöße sehr freuen.

Hier mal Auszüge aus den Routing Tabellen.
Das lokale Netzt des Servers ist 192.168.100.0/24
Die Netze der Clients, die "laufen" 192.168.101 bis 104.0/24
Das Netz des neuen Clients der nicht geht ist 192.168.105.0/24

### Server 192.168.100.1 ###
route | grep tun
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
[COLOR="#008000"]192.168.101.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.102.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.103.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0[/COLOR]
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
[COLOR="#B22222"][COLOR="#008000"]192.168.104.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0[/COLOR]
192.168.105.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0[/COLOR]

### Client 192.168.103.1 ###
route | grep tun
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
1[COLOR="#0000CD"]92.168.100.0   10.8.0.5        255.255.255.0   UG    0      0        0 tun0[/COLOR]
[COLOR="#008000"]192.168.101.0   10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.102.0   10.8.0.5        255.255.255.0   UG    0      0        0 tun0[/COLOR]
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
[COLOR="#008000"]192.168.104.0   10.8.0.5        255.255.255.0   UG    0      0        0 tun0[/COLOR]
[COLOR="#B22222"]192.168.105.0   10.8.0.5        255.255.255.0   UG    0      0        0 tun0[/COLOR]

### neuer Client 192.168.105.1 ###
route| grep tun
10.8.0.17       *               255.255.255.255 UH    0      0        0 tun0
[COLOR="#0000CD"]192.168.100.0   10.8.0.17       255.255.255.0   UG    0      0        0 tun0[/COLOR]
[COLOR="#008000"]192.168.101.0   10.8.0.17       255.255.255.0   UG    0      0        0 tun0
192.168.102.0   10.8.0.17       255.255.255.0   UG    0      0        0 tun0
192.168.103.0   10.8.0.17       255.255.255.0   UG    0      0        0 tun0[/COLOR]
10.8.0.0        10.8.0.17       255.255.255.0   UG    0      0        0 tun0
[COLOR="#008000"]192.168.104.0   10.8.0.17       255.255.255.0   UG    0      0        0 tun0[/COLOR]

Die Routing Tabelle sehen für mich in Ordnung aus.
Ich kann hier keinen Fehler entdecken.

Woran kann es also liegen, dass beim Client 192.168.105.1 trotzdem keine Verbindungen über den Tunnel möglich sind?
Falls ich die Konfigurationen posten soll, bitte Bescheid geben

Danke im Voraus und Gruß
maceis

 

[MaxMuster]

Die iroute-Einträge (GUI: "erweiterte Clientconfig") sind aber eingerichtet? Ohne die Configs ist es immer schwer zu raten, was "falsch" sein könnte.

 

[maceis]

Hallo,

das Routing wird doch alles vom Server gepusht.
Von daher verstehe ich nicht, was ich da am Client einrichten soll.
Die Routing tabellen werden ja auch m. E. richtig aufgebaut.

Zwischenzeitlich hab ich verschiedene Feststellungen gemacht.
Auf allen beteiligten openvpn Instanzen (server und clients) werden auch bei Verbindungsversuchen mit der nicht funktionierenden Verbindung Pakete in das tun-Interface geschrieben.
die Pakete kommen auf der jeweiligen Gegenseite aber nicht aus dem tun Interface heraus.
Das gilt für client->client, client<-client, server->client, server<-client, abet nur bei dem neuen "Teilnehmer"

Starte ich auf dem Problemclient openvpn mit der altbewährten Konfiguration "von Hand", funktioniert alles und zwar mit den selben key- und crt-files.

Hier die funktionierende Konfiguration:

[COLOR="#808080"]ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key[/COLOR]
client
no-replay
[COLOR="#808080"]pull
dev tun
proto udp
[COLOR="#808080"]remote ......homeunix.net 1194[/COLOR]
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3[/COLOR]
;mute 20

und hier die nicht funktionieren Konfiguration, die von Freetz aus den Eingaben im Webinterface erzeugt wird.

#  OpenVPN 2.1 Config, Thu Mar 14 20:15:19 CET 2013
proto udp
dev tun
[COLOR="#808080"]ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key[/COLOR]
ns-cert-type server
[COLOR="#808080"]remote ......homeunix.net
nobind
pull[/COLOR]
tun-mtu 1500
mssfix
[COLOR="#808080"]verb 3[/COLOR]
cipher BF-CBC
[COLOR="#808080"]comp-lzo[/COLOR]
keepalive 10 120
resolv-retry infinite
chroot /tmp/openvpn
user openvpn
group openvpn
[COLOR="#808080"]persist-tun
persist-key[/COLOR]

So, und jetzt kommen die Preisfragen:

Welche Einträge sind bei der nicht funktionierenden Variante schuld daran, dass es nicht geht?
Ins Auge gestochen ist mir "ns-cert-type server", aber ich hab natürlich Client angeklickt.
Außerdem funktioniert die Authentifizierung ja.

Was muss ich am GUI einstellen, damit die von mir gewünschte Konfiguration herauskommt.

Ich würde nämlich zumindest bei den freetz (bzw z. Tl. ds-mod) Boxen auch gerne die Einrichtung über GUI machen.
Bei den nicht geflashten Boxen muss openvpn es weiter über debug.cfg konfiguriert und gestartet werden.

Vielen Dank im Voraus und Gruß
maceis

 

[MaxMuster]

Hatte es so verstanden, dass die Verbindung funktioniert und nur das Netz beim Client nicht erreichbar ist (dafür brauchst du halt beim Server ein passendes "iroute" Konstrukt).
Aber du kannst nicht mal die VPN-IP (10.8.0.17, wenn ich das richtig gelesen hab) erreichen?

Wenn die Verbindung aufgebaut wird und die Dinge gepullt werden, sollte das Zertifikat des Servers wirklich ein "Server-Zertifikat" sein (geprüft mit "ns-cert-type server", das könnte man mit dem Haken bei Keine Prüfung von "ns-cert-type" abschalten.

Könnte noch ein Problem der MTU sein, aber das stände auch im Log...

Was steht denn im Log beim Verbindungsaufbau?

EDIT :Du kannst auch "die GUI-Einstellung umgehen", und die Wunsch-Konfig nach /tmp/flash/openvpn/own_openvpn.conf speichern (danach "modsave"), dann wird diese die Einstellungen in der GUI "übertrumpfen".

 

[maceis]

Danke für Deine Geduld.

Die iroute Einträge beim Server habe ich.

Hier das clientseitige Log beim Verbindungsaufbau.
Sieht für mich normal aus.

Thu Mar 14 21:32:26 2013 OpenVPN 2.3.0 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Mar 12 2013 
Thu Mar 14 21:32:26 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables 
Thu Mar 14 21:32:26 2013 WARNING: file '/tmp/flash/openvpn/box.key' is group or others accessible 
Thu Mar 14 21:32:26 2013 Socket Buffers: R=[178176->131072] S=[178176->131072] 
Thu Mar 14 21:32:26 2013 NOTE: chroot will be delayed because of --client, --pull, or --up-delay 
Thu Mar 14 21:32:26 2013 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay 
Thu Mar 14 21:32:26 2013 UDPv4 link local: [undef] 
Thu Mar 14 21:32:26 2013 UDPv4 link remote: [AF_INET]77.7.+++.+++:1194 
Thu Mar 14 21:32:26 2013 TLS: Initial packet from [AF_INET]77.7.+++.+++:1194, sid=30d819c4 74738c10 
Thu Mar 14 21:32:26 2013 [B]VERIFY OK: depth=1, C=DE, ST= usw[/B]. 
Thu Mar 14 21:32:26 2013 VERIFY OK: nsCertType=SERVER 
Thu Mar 14 21:32:26 2013 [B]VERIFY OK: depth=0, C=DE, ST= usw.[/B] 
Thu Mar 14 21:32:27 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key 
Thu Mar 14 21:32:27 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 
Thu Mar 14 21:32:27 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key 
Thu Mar 14 21:32:27 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 
Thu Mar 14 21:32:27 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA 
Thu Mar 14 21:32:27 2013 [homebox] Peer Connection Initiated with [AF_INET]77.7.+++.+++:1194 
Thu Mar 14 21:32:29 2013 SENT CONTROL [homebox]: 'PUSH_REQUEST' (status=1) 
Thu Mar 14 21:32:29 2013 PUSH: Received control message: 'PUSH_REPLY,route 192.168.100.0 255.255.255.0,route 192.168.101.0 255.255.255.0,route 192.168.102.0 255.255.255.0,route 192.168.103.0 255.255.255.0,route 192.168.104.0 255.255.255.0,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' 
Thu Mar 14 21:32:29 2013 OPTIONS IMPORT: timers and/or timeouts modified 
Thu Mar 14 21:32:29 2013 OPTIONS IMPORT: --ifconfig/up options modified 
Thu Mar 14 21:32:29 2013 OPTIONS IMPORT: route options modified 
Thu Mar 14 21:32:29 2013 TUN/TAP device tun0 opened 
Thu Mar 14 21:32:29 2013 TUN/TAP TX queue length set to 100 
Thu Mar 14 21:32:29 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 
Thu Mar 14 21:32:29 2013 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500 
Thu Mar 14 21:32:29 2013 /sbin/route add -net 192.168.100.0 netmask 255.255.255.0 gw 10.8.0.5 
Thu Mar 14 21:32:29 2013 /sbin/route add -net 192.168.101.0 netmask 255.255.255.0 gw 10.8.0.5 
Thu Mar 14 21:32:29 2013 /sbin/route add -net 192.168.102.0 netmask 255.255.255.0 gw 10.8.0.5 
Thu Mar 14 21:32:29 2013 /sbin/route add -net 192.168.103.0 netmask 255.255.255.0 gw 10.8.0.5 
Thu Mar 14 21:32:29 2013 /sbin/route add -net 192.168.104.0 netmask 255.255.255.0 gw 10.8.0.5 
Thu Mar 14 21:32:29 2013 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.5 
Thu Mar 14 21:32:29 2013 chroot to '/tmp/openvpn' and cd to '/' succeeded 
Thu Mar 14 21:32:29 2013 GID set to openvpn 
Thu Mar 14 21:32:29 2013 UID set to openvpn 
Thu Mar 14 21:32:29 2013 [B]Initialization Sequence Completed [/B]
Thu Mar 14 21:32:42 2013 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #4198940672 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

 

[MaxMuster]

Hm, oben hatte aber der "103-er" die IP 10.8.0.6 bekommen und der 105-er die .18 ?!?

Machst du dann bitte mal vom Client einen Ping auf den Server, die 10.8.0.1 vermute ich?

 

[maceis]

Was genau hat das jetzt zu sagen?
Legt der Server das nicht abhängig von der Reihenfolge der Clientanmeldungen (oder nach anderen Kriterien?) fest und merkt sich die Zuordnungen dann in der ipp.txt?

Was mich halt wundert.
Bei allen Clients sind die Routing Tabellen "gleich"
Bei 4 von 5 clients kann ich feststellen, dass Pakete zum Beispiel von Client zu Client oder auch zum Server auf der einen Seite ins tun Interface geschrieben werden und auf der Gegenseite wieder herauskommen.

Nur bei dem über Webinterface konfigurierten Client geht es zwar auf der einen Seite ins tun Interface hinein, kommt aber auf der anderen Seite nicht mehr heraus.
Und das ist unabhängig davon, von welcher Seite aus die Kommunikation mit dem Client versucht wird.
Wenn dem nicht so wäre, würde ich sagen, das backrouting funktioniert nicht, aber so ...

Ich bin echt ratlos.

 

[MaxMuster]

Ich war davon ausgegangen, dass du für die Clients per client-config-dir nicht nur die iroutes einstellst, sondern auch immer eine IP vergibst.

Aber wenn die immer dynamisch vergeben werden...

Bitte: mach mal den Ping zwischen den VPN-IPs von Client und Server.

EDIT: Könntest du mal ein "ifconfig tun0" vergleichen zwischen dem "händischen" und dem "GUI-Aufruf"? Wie ist die MTU?