[Gelöst] Probleme mit neuer OpenVPN Version

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
660
Punkte für Reaktionen
4
Punkte
18
Hallo zusammen,

ich habe seit vielen Jahren eine OpenVPN Server-Client Umgebung mit Zertifikaten am Laufen.
Der folgende Beitrag ist sehr lang, weil ich versuche ausführlich zu sein. Es kommt aber wahrscheinlich nur auf wenige Parameter an.

Auf meiner eigenen Box läuft der OpenVPN Server (OpenVPN 2.3.18). An insgesamt fünf Standorten laufen jeweils OpenVPN Clients (2.3.18 und 2.4.7) auf unterschiedlichen FritzBoxen.
Das ganze läuft, wie gesagt, seit vielen Jahren sauber und zuverlässig.

Heute habe ich auf einer 7490 ein neu gebautes Image (6.93) aufgespielt, das OpenVPN 2.4.8 enthält. Die übrigen Boxen (7390, 7490 und eine Kabelbox) laufen unter 6.93 oder 6.83.
Probleme (Konfigurationen und Logdaten stelle ich ans Ende):
  1. Wenn ich "Optionen vom Server empfangen" einstelle (wie immer), startet OpenVPN, beendet sich nach ca. 5 bis 10 Sekunden aber wieder.
  2. Wenn ich "Optionen vom Server empfangen" einstelle, startet OpenVPN und läuft auch weiter, ich habe aber kein Routing, auch nicht, wenn ich die Routen von Hand anlege. Das Routing in den Tunnel hinein, scheint dann zwar zu funktionieren, auf der Gegenseite kommt aber nichts an und es kommt nichts zurück.
  3. Mir ist außerdem aufgefallen, dass das tun0 Interface bei der neu eingerichteten Box anders angelegt, als bei den anderen Boxen.
So sieht das tun Interface bei den alten (funktionierenden) Boxen aus. 10.8.0.1/24 (255.255.255.0) ist die Tunnel-IP des Servers; 10.8.0.4/24, die eines Clients. Die dahinter stehenden Netze sind "echte" Class-C Netze (192.168.xxx.0/24)
Code:
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.8.0.4  P-t-P:10.8.0.4  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:106 errors:0 dropped:0 overruns:0 frame:0
          TX packets:98 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:8531 (8.3 KiB)  TX bytes:61942 (60.4 KiB)
Hier das selbe für den neuen (nicht funktionieren) Clients (10.8.0.2/24):
Code:
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.8.0.2  P-t-P:10.8.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Auffällig sind die Werte bei P-t-P (hier: steht nicht wie oben die Tunnel Adresse des jeweiligen Clients, sondern die des Servers. Noch mehr habe ich mich über die Netzmaske gewundert, weil diese würde hier bedeuten, dass die IP-Adressen gar keine host-Anteil haben. Wenn ich das Routing von Hand (mit route add) identisch wie bei den "alten" Clients anlege und einen Host in einem der entfernten Netze anpinge, sehe ich unter TX, dass Pakete in den Tunnel gehen. Auf der Gegenstelle und am Server kommen die Pakete aber anscheinend nicht an (tcpdump -i tun0 icml oder tcpdump -i any icml).

Hier nun die Konfigurationen;
Serverbox:
Code:
% cat /mod/etc/openvpn.conf
# OpenVPN 2.3.18 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Feb  9 2018
# library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
#  Config date: Thu Jan  1 01:01:12 CET 1970
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
port 1194
ifconfig 10.8.0.1 255.255.255.0
push "route-gateway 10.8.0.1"
topology subnet
push "topology subnet"
push "route 192.168.100.0 255.255.255.0"
max-clients 20
mode server
client-config-dir clients_openvpn
route 192.168.102.0 255.255.255.0 10.8.0.2
route 192.168.103.0 255.255.255.0 10.8.0.3
route 192.168.104.0 255.255.255.0 10.8.0.4
route 192.168.105.0 255.255.255.0 10.8.0.5
route 192.168.001.0 255.255.255.0 10.8.0.32
client-to-client
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
Clientbox:
Code:
% cat /mod/etc/openvpn.conf
# OpenVPN 2.3.18 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Feb  9 2018
# library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
#  Config date: Thu Jan  1 01:01:09 CET 1970
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
ns-cert-type server
remote homebox.mydomain.de
nobind
pull
ifconfig 10.8.0.4 10.8.0.1
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
Der einzige Unterschiede in der Konfiguration der Clients liegt darin, dass in der Zeile ifconfig die erste IP Adresse sich jeweils in der letzen Ziffer unterscheidet.

Hier noch der relevante Teil des debug-logs. Die Aushandlung der Authentifizierung habe ich der Übersichtlichkeit halber weggelassen. Mir scheint der Fehler passiert beim Erstellen des tun0 Interfaces. Bis zum push (bzw. pull) der Routen kommt es dann wohl gar nicht mehr.
Code:
% tail -6 /var/tmp/debug_openvpn.out
Tue Dec 24 12:17:02 2019 TUN/TAP device tun0 opened
Tue Dec 24 12:17:02 2019 TUN/TAP TX queue length set to 100
Tue Dec 24 12:17:02 2019 /sbin/ifconfig tun0 10.8.0.2 netmask 10.8.0.1 mtu 1500 broadcast 255.255.255.254
ifconfig: SIOCSIFNETMASK: Invalid argument
Tue Dec 24 12:17:02 2019 Linux ifconfig failed: external program exited with error status: 1
Tue Dec 24 12:17:02 2019 Exiting due to fatal error
Hat jemand diese Verhalten schon beobachtet?
Was kann ich versuchen, um den Fehler zu beheben.

Danke im Voraus und Gruß
maceis
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,526
Punkte für Reaktionen
851
Punkte
113

Suche nach
Note: Using –topology subnet changes the interpretation of the arguments of –ifconfig to mean “address netmask”, no longer “local remote”.
, da kannst Du Dir auch gleich noch die Bedeutung von "ifconfig" in Abhängigkeit vom Typ und Modus des verwendeten virtuellen Interfaces ansehen (kleiner Tipp: Du brauchst gar kein "ifconfig" am Client, wenn Du am Server die Vergabe der Adressen für die Tunnel der Clients zentral konfigurierst und per "push" zum Client übermittelst.)

Denn Dein "ifconfig x y" am Client ist vermutlich auch der Auslöser für das sichtbare und falsche(!) "ifconfig"-Kommando im Protokoll, denn "netmask 10.8.0.1" ist ja offensichtlicher Unsinn und bis zum "pull" kommt es hier ja noch nicht einmal.

Wobei man nicht mal richtig sicher weiß, ob das gezeigte Protokoll jetzt vom Server oder vom Client sein soll ... vermutlich ist es das vom Client. Nur warum man einem TLS-Client überhaupt eine lokale Adresse mit auf den Weg geben sollte und das nicht über die CCD-Dateien auf dem Server macht, verstehe ich ohnehin nicht.
 

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
660
Punkte für Reaktionen
4
Punkte
18
Mit folgenden Kommandos habe ich jetzt das tun0 Interface so konfiguriert, wie ich es auf den funktionierenden Boxen ist und eine Route von Hand angelegt:
Code:
# /sbin/ifconfig tun0 10.8.0.2 netmask 255.255.255.0 dstaddr 10.8.0.2 mtu 1500 broadcast 255.255.255.0
# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.8.0.2  P-t-P:10.8.0.2  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:2268 (2.2 KiB)

# route add -net 192.168.100.0 netmask 255.255.255.0 gw 10.8.0.1
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     2      0        0 dsl
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
93.195.186.57   *               255.255.255.255 UH    2      0        0 dsl
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
192.168.100.0   10.8.0.1        255.255.255.0   UG    0      0        0 tun0
192.168.102.0   *               255.255.255.0   U     0      0        0 lan
192.168.179.0   *               255.255.255.0   U     0      0        0 guest
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
217.237.148.102 *               255.255.255.255 UH    2      0        0 dsl
217.237.151.115 *               255.255.255.255 UH    2      0        0 dsl
Die "TX packets:27" sind pings, die ich in das Netz 192.168.100.0 geschickt habe.
Auf der OpenVPN Box in diesem Netz gibt es folgende Zurückroute:
Code:
192.168.102.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0
Trotzdem scheint dort nichts anzukommen; jedenfalls kommt keine Antwort und
Code:
# tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
Ich weiß nicht, was ich noch probieren könnte.

Gruß
maceis

-- Zuammenführung Doppelpost by stoney

Wobei man nicht mal richtig sicher weiß, ob das gezeigte Protokoll jetzt vom Server oder vom Client sein soll ... vermutlich ist es das vom Client. Nur warum man einem TLS-Client überhaupt eine lokale Adresse mit auf den Weg geben sollte und das nicht über die CCD-Dateien auf dem Server macht, verstehe ich ohnehin nicht.
Das Protokoll ist von dem Client, der nicht funktioniert.
Früher habe ich die Konfigurationsdatei ja noch über die debug.conf beim Start der Boxen erstellt und startete OpenVPN auch über die debug.cfg. Jetzt mache ich alles über das Freetz Webinterface.

Deine Hinweis deutet vielleicht in die richtige Richtung.
Mich wundert nur, dass ich ja schon einen Client unter OpenVPN 2.4.7 mit analoger Konfiguration am Laufen habe.
Die Konfiguration ist dort (abgesehen von der lokalen IP Adresse) identisch und funktioniert. Außerdem habe ich ja in meiner conf kein "topology subnet"

Ich werde das mal weiterverfolgen und dann berichten.

Gruß
maceis
 
Zuletzt bearbeitet von einem Moderator:

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
660
Punkte für Reaktionen
4
Punkte
18
Hallo nochmal,

es hat sich zwar etwas hingezogen, aber ich habe jetzt alles kontrolliert und ausprobiert, was Peter empfohlen hat, was ich in der Dokumentation gefunden habe und was mir sonst noch so eingefallen ist. Ich bin zu folgenden Ergebnissen gekommen (Einzelheiten s. weiter unten):
  1. Der Fehler tritt nur auf einer bestimmten Fritzbox 7490 auf. Auf anderen Fritzboxen (7490 und andere) tritt der Fehler bei identischer Konfiguration (abgesehen von den IP-Adressen) nicht auf.
  2. Der Fehler tritt unabhängig von der verwendeten OpenVPN Version (2.3.18, 2.4.7, 2.4.8) auf dem Client auf.
  3. Der Fehler tritt auch auf, wenn ich die IP-Adresse am Client "vom Server empfangen" lasse. OpenVPN startet dann zwar, aber die IP-Adresse wird nicht gepusht (bei anderen Clients funktioniert das). Das sieht man auch in den Beispieausgaben ganz unten.
  4. Ich habe "-topology" nicht ausdrücklich konfiguriert. Der Server und die Clients scheinen automatisch "subnet" zu nehmen, was ich daraus schließe, dass in der PUSH_EREPLY Message "topology subnet" steht (s. Ausgaben zum Punkt 6); Edit: liegt wohl an der Serconfig, die über die Freetz-Oberfläche generiert wird.
  5. Bei der betreffenden Box startet openvpn nur dann (jetzt ohne "IP Adressen vom Server empfangen"), wenn ich bei der Konfiguration "-ifconfig" als zweiten Parameter die Subnetzmaske angebe, sonst:
    Fri Jan 17 14:44:54 2020 /sbin/ifconfig tun0 10.8.0.2 netmask 10.8.0.1 mtu 1500 broadcast 255.255.255.254
    ifconfig: SIOCSIFNETMASK: Invalid argument
    Fri Jan 17 14:44:54 2020 Linux ifconfig failed: external program exited with error status: 1
    Fri Jan 17 14:44:54 2020 Exiting due to fatal error
    Bei allen anderen Boxen muss ich als zweiten Parameter die IP-Adresse des TUN-Interfaces am Server geben.
  6. Offensichtlich funktioniert das pull/push bei der betreffenden Box anders, als bei den anderen Boxen. Es werden wesentlich weniger Einstellungen gepusht. Insbesondere werden die Routen (blau) zu den anderen openVPN Netzen nicht gepusht.
    Funktionierende Box:
    Fri Jan 17 14:49:48 2020 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,route 192.168.100.0 255.255.255.0,ping 10,ping-restart 120,route 192.168.102.0 255.255.255.0 10.8.0.2,route 192.168.103.0 255.255.255.0 10.8.0.3,route 192.168.105.0 255.255.255.0 10.8.0.5,route 192.168.001.0 255.255.255.0 10.8.0.32'
    Nicht Funktionierende Box:
    Fri Jan 17 14:44:54 2020 SENT CONTROL [homebox]: 'PUSH_REQUEST' (status=1)
    Fri Jan 17 14:44:54 2020 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,route 192.168.100.0 255.255.255.0,ping 10,ping-restart 120'
  7. Selbst wenn ich die Routen von Hand eingebe, funktioniert das Routing nicht (auch nicht bis zum Server).
Hier mal der Vergleich der Ausgaben von zwei "identisch" konfigurierten Boxen beim Start. Nur der zweite Parameter von ifconfig ist unterschiedlich (s. oben, Punkt 5). Die Ausgaben die mir wichtig erscheinen, habe ich rot gemacht.
####funktionierende Box:
openvpn --config /mod/etc/openvpn.conf --writepid /var/run/openvpn.pid
Fri Jan 17 14:49:42 2020 OpenVPN 2.3.18 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Feb 9 2018
Fri Jan 17 14:49:42 2020 library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.10
Fri Jan 17 14:49:42 2020 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Fri Jan 17 14:49:42 2020 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Fri Jan 17 14:49:42 2020 Socket Buffers: R=[229376->229376] S=[229376->229376]
Fri Jan 17 14:49:42 2020 NOTE: chroot will be delayed because of --client, --pull, or --up-delay
Fri Jan 17 14:49:42 2020 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Fri Jan 17 14:49:42 2020 UDPv4 link local: [undef]
Fri Jan 17 14:49:42 2020 UDPv4 link remote: [AF_INET]xx.xx.245.127:1194
Fri Jan 17 14:49:42 2020 TLS: Initial packet from [AF_INET]xx.xx.245.127:1194, sid=9e8558af 15ad33e1
Fri Jan 17 14:49:43 2020 VERIFY OK: depth=1, C=DE, ST=BAYERN, L=N, O=xxx, CN=xxxCA, emailAddress=[email protected]
Fri Jan 17 14:49:43 2020 VERIFY OK: nsCertType=SERVER
Fri Jan 17 14:49:43 2020 VERIFY OK: depth=0, C=DE, ST=BAYERN, L=N, O=xx CN=xx, emailAddress=[email protected]
Fri Jan 17 14:49:46 2020 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jan 17 14:49:46 2020 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 17 14:49:46 2020 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jan 17 14:49:46 2020 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 17 14:49:46 2020 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Jan 17 14:49:46 2020 [homebox] Peer Connection Initiated with [AF_INET]xx.xx.245.127:1194
Fri Jan 17 14:49:48 2020 SENT CONTROL [homebox]: 'PUSH_REQUEST' (status=1)
Fri Jan 17 14:49:48 2020 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,route 192.168.100.0 255.255.255.0,ping 10,ping-restart 120,route 192.168.102.0 255.255.255.0 10.8.0.2,route 192.168.103.0 255.255.255.0 10.8.0.3,route 192.168.105.0 255.255.255.0 10.8.0.5,route 192.168.001.0 255.255.255.0 10.8.0.32,ifconfig 10.8.0.4 255.255.255.0'
Fri Jan 17 14:49:48 2020 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jan 17 14:49:48 2020 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jan 17 14:49:48 2020 OPTIONS IMPORT: route options modified
Fri Jan 17 14:49:48 2020 OPTIONS IMPORT: route-related options modified
Fri Jan 17 14:49:48 2020 TUN/TAP device tun0 opened
Fri Jan 17 14:49:48 2020 TUN/TAP TX queue length set to 100
Fri Jan 17 14:49:48 2020 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Jan 17 14:49:48 2020
/sbin/ifconfig tun0 10.8.0.4 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Fri Jan 17 14:49:48 2020 /sbin/route add -net 192.168.100.0 netmask 255.255.255.0 gw 10.8.0.1
Fri Jan 17 14:49:48 2020 /sbin/route add -net 192.168.102.0 netmask 255.255.255.0 gw 10.8.0.2
Fri Jan 17 14:49:48 2020 /sbin/route add -net 192.168.103.0 netmask 255.255.255.0 gw 10.8.0.3
Fri Jan 17 14:49:48 2020 /sbin/route add -net 192.168.105.0 netmask 255.255.255.0 gw 10.8.0.5
Fri Jan 17 14:49:48 2020 /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.32
Fri Jan 17 14:49:48 2020 chroot to '/var/tmp/openvpn' and cd to '/' succeeded
Fri Jan 17 14:49:48 2020 GID set to openvpn
Fri Jan 17 14:49:48 2020 UID set to openvpn
Fri Jan 17 14:49:48 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Jan 17 14:49:48 2020 Initialization Sequence Completed
Nicht funktionierende Box:
/var/tmp/openvpn-bin --config /mod/etc/openvpn.conf --writepid /var/run/openvpn.pid
Fri Jan 17 15:08:04 2020 OpenVPN 2.3.18 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Feb 9 2018
Fri Jan 17 15:08:04 2020 library versions: OpenSSL 1.0.2t 10 Sep 2019, LZO 2.10
Fri Jan 17 15:08:04 2020 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Fri Jan 17 15:08:04 2020 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Fri Jan 17 15:08:04 2020 Socket Buffers: R=[229376->229376] S=[229376->229376]
Fri Jan 17 15:08:04 2020 NOTE: chroot will be delayed because of --client, --pull, or --up-delay
Fri Jan 17 15:08:04 2020 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Fri Jan 17 15:08:04 2020 UDPv4 link local: [undef]
Fri Jan 17 15:08:04 2020 UDPv4 link remote: [AF_INET]xx.xx.245.127:1194
Fri Jan 17 15:08:04 2020 TLS: Initial packet from [AF_INET]xx.xx.245.127:1194, sid=6ff9875d 97592262
Fri Jan 17 15:08:04 2020 VERIFY OK: depth=1, C=DE, ST=BAYERN, L=N, O=xx, CN=xx CA, emailAddress=[email protected]
Fri Jan 17 15:08:04 2020 VERIFY OK: nsCertType=SERVER
Fri Jan 17 15:08:04 2020 VERIFY OK: depth=0, C=DE, ST=BAYERN, L=N, O=xx, CN=homebox, emailAddress=[email protected]
Fri Jan 17 15:08:07 2020 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jan 17 15:08:07 2020 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 17 15:08:07 2020 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jan 17 15:08:07 2020 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 17 15:08:07 2020 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Jan 17 15:08:07 2020 [homebox] Peer Connection Initiated with [AF_INET]xx.xx.245.127:1194
Fri Jan 17 15:08:09 2020 SENT CONTROL [homebox]: 'PUSH_REQUEST' (status=1)
Fri Jan 17 15:08:09 2020 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,route 192.168.100.0 255.255.255.0,ping 10,ping-restart 120'
Fri Jan 17 15:08:09 2020 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jan 17 15:08:09 2020 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jan 17 15:08:09 2020 OPTIONS IMPORT: route options modified
Fri Jan 17 15:08:09 2020 OPTIONS IMPORT: route-related options modified
Fri Jan 17 15:08:09 2020 TUN/TAP device tun0 opened
Fri Jan 17 15:08:09 2020 TUN/TAP TX queue length set to 100
Fri Jan 17 15:08:09 2020 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Jan 17 15:08:09 2020 /sbin/ifconfig tun0 10.8.0.2 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Fri Jan 17 15:08:09 2020 /sbin/route add -net 192.168.100.0 netmask 255.255.255.0 gw 10.8.0.1
Fri Jan 17 15:08:09 2020 chroot to '/var/tmp/openvpn' and cd to '/' succeeded
Fri Jan 17 15:08:09 2020 GID set to openvpn
Fri Jan 17 15:08:09 2020 UID set to openvpn
Fri Jan 17 15:08:09 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Jan 17 15:08:09 2020 Initialization Sequence Completed

Danke fürs Durchlesen des lange Postings.
Ich bin echt ratlos und hoffe auf Tipps und Anregungen.
Falls noch Infos geraucht werden, bitte Bescheid geben.

Gruß
maceis

PS: Hier noch mal die configs:
Server:
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
port 1194
ifconfig 10.8.0.1 255.255.255.0
push "route-gateway 10.8.0.1"
topology subnet
push "topology subnet"

push "route 192.168.100.0 255.255.255.0"
max-clients 20
mode server
client-config-dir clients_openvpn
route 192.168.102.0 255.255.255.0 10.8.0.2
route 192.168.103.0 255.255.255.0 10.8.0.3
route 192.168.104.0 255.255.255.0 10.8.0.4
route 192.168.105.0 255.255.255.0 10.8.0.5
route 192.168.001.0 255.255.255.0 10.8.0.32
client-to-client
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
Client:
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
ns-cert-type server
remote homebox.mydomain.de
nobind
pull
ifconfig 10.8.0.2 255.255.255.0
# bei den funktionierenden Clients steht hier z. B.
# ifconfig 10.8.0.4 10.8.0.1

tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,526
Punkte für Reaktionen
851
Punkte
113
Hast Du Dir denn die Protokoll-Datei auch mal angesehen?

Was denkst Du denn, will Dir:
Code:
Fri Jan 17 14:49:42 2020 WARNING: using --pull/--client and --ifconfig together is probably not what you want
sagen?

Warum verwendest Du denn sowohl das "pull" (damit kriegt die Box ihre Konfiguration vom OpenVPN-Server) als auch das "ifconfig" in demselben Kontext? Und nun schreibe bitte nicht: "Weil es bisher so funktionierte ..." - eine sinnlose Konfiguration wird ja nicht dadurch plausibler, daß eine Software am Ende schlauer ist als ihr Benutzer.

Ich habe zumindest eine Theorie, warum das für die anderen Clients vielleicht noch - gerade so - gut geht, auch wenn deren Konfiguration ebenso Unfug ist ... anders als die anderen Adressen würde die Tunnel-IP dieses - nicht funktionierenden - Clients mit der IP des Server auch das Subnetz bilden, was bei "topology net30" zum Einsatz käme (.0 wäre das Netz, .1 und .2 die verfügbaren Adressen und .3 die Broadcast-Adresse in so einem Szenario). Schon daraus könnte sich eine andere Reaktion auf die PUSH-Messages ableiten, wenn bereits über "ifconfig" ein anderes Netz konfiguriert wurde.

In der Server-Konfiguration ist außerdem von einer CCD-Konfiguration (client-config-dir) die Rede ... dabei wird im angegebenen Unterverzeichnis für jeden zur Verbindung berechtigten Client eine eigene Konfiguration hinterlegt und (bei Zertifikatnutzung) dann anhand des CN im Zertifikat die richtige Datei ausgewählt. Diese sollte dann auch die Konfigurationsangaben für diesen speziellen Client enthalten (solange der mit "pull" eine solche beim Server abruft) und dann hat ein "ifconfig" auf einem Client eigentlich gar nichts zu suchen (was mein Tipp in #2 eigentlich schon zum Ausdruck bringen wollte).

Du solltest hier (ungeachtet der Tatsache, daß auch eine "vergurkte" Konfiguration bei Clients mit IP > 10.8.0.3 bei Dir funktioniert ... mich würde mal interessieren, ob die .3 tatsächlich auch reibungslos funktioniert oder ob da nur eine Fehlfunktion nicht aufgefallen ist - aber das nur am Rande) mal etwas aufräumen in den Konfigurationen und Dich entscheiden, ob Du die Client nun zentral (über CCD, was bei Identifikation anhand von CN in Zertifikaten zu empfehlen wäre) konfigurieren lassen willst oder ob jeder Client seine eigene Konfiguration kriegen soll. Auch bei letzterem solltest Du die Konfiguration dann auf das Notwendige ausdünnen und Dich nicht darauf verlassen, daß OpenVPN schon die Einstellungen ignoriert, die gar nicht zur konfigurierten Arbeitsweise passen.

Außerdem solltest Du mal eine "Bestandsaufnahme" im CCD auf dem Server machen ... ggf. finden sich auch da Unterschiede in den Client-Konfigurationen. Wenn weder Zertifikate noch serverseitige Konfiguration verwendet werden, braucht's das ganze CCD eigentlich auch nicht, außer die (berechtigten) Client verwenden am Ende noch unterschiedliche (statische) Keys - was dann wieder ein Faktor wäre, warum man eigentlich auf die client-seitige Konfiguration verzichten würde und das lieber "zentral" am Server macht. Was sollte man sich von einer "Mischkonfiguration" (ein Teil am Server, ein Teil am Client) versprechen, selbst wenn es keine Widersprüche in den Konfigurationsdaten gäbe?

=========================================================

Ansonsten verstehe ich auch:
Falls noch Infos geraucht werden, bitte Bescheid geben.
nicht so richtig ... wenn ich irgendwas rauchen will (den Nikotinmißbrauch habe ich vor 8 Jahren eingestellt), dann eher keine Infos - wenn Du andere Sachen im Angebot hast, würde ich das (weil's "Handel" wäre) auch nicht über eine offene Plattform abwickeln, sofern die "Ware" unter das BTMG fallen würde.
 

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
660
Punkte für Reaktionen
4
Punkte
18
Hallo Peter,

vielen Dank für Deine Bemühungen.
Zunächst mal: Ich habe den Fehler gefunden und, wie schon geahnt, lag er bei mir.
Dazu später mehr. Zuerst möchte ich kurz auf Deine Kommentare eingehen.

Die Warnung hatte ich natürlich gelesen, aber nicht für mein aktuelles Problem verantwortlich gemacht. Ich hatte das eher als Hinweis verstanden, dass man meist wohl etwas anderes will. Meine Konfiguration hat sich über Jahre entwickelt. Die IP-Adressen der Clientadressen waren zuerst da. Später kam das "pull" dazu, um die Routen automatisch einzurichten. Inzwischen lass ich auch die IP Adressen pushen, was natürlich sinnvoll ist.

Und ja, die .3 funktioniert tatsächlich völlig einwandfrei. Aktuell habe ich 10.8.0.1 für den Server und .2, .3, .4, .5 und .32 bei den Clients.

Mein Problem wurde tatsächlich durch einen tückischen Tippfehler im Zertifikat des betreffenden Clients verursacht.
Wenn der CN im Zertifikat des Clients nicht exakt mit dem Namen in der Client-Konfiguration des Severs übereinstimmt, liefert der Server mit pull nicht die notwendigen Einstellungen an den Client. Das ist ja auch einleuchtend.

Nachdem gleiche Konfigurationen auf der gleichen Hardware und mit der gleiche OpenVPN-Version zu unterschiedlichen Ergebnissen führten, habe ich alles noch einmal durchgeforstet und den Tippfehler letztlich bemerkt. Gewundert hat mich nachträglich nur, dass überhaupt eine Verbindung zustandekommen ist und die Authentifizierung als solche durchgelaufen ist.

Nochmal viel Dank.
Gruß
maceis
 
  • Like
Reaktionen: PeterPawn

hallihallo2

Neuer User
Mitglied seit
3 Jun 2016
Beiträge
18
Punkte für Reaktionen
0
Punkte
3
Hallo Maceis, könntest du bitte noch mal deine funktionierende Client, Server und CCD posten? Herzlichen Dank!
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,526
Punkte für Reaktionen
851
Punkte
113
@maceis:
Glückwunsch ... und danke für die Änderung des Präfix.
 

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
660
Punkte für Reaktionen
4
Punkte
18
@hallihallo2

Server:

Code:
# OpenVPN 2.3.18 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Feb  9 2018
# library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
#  Config date: Sun Jan 19 02:13:52 CET 2020
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
port 1194
ifconfig 10.8.0.1 255.255.255.0
push "route-gateway 10.8.0.1"
topology subnet
push "topology subnet"
push "route 192.168.100.0 255.255.255.0"
max-clients 20
mode server
client-config-dir clients_openvpn
route 192.168.102.0 255.255.255.0 10.8.0.2
route 192.168.103.0 255.255.255.0 10.8.0.3
route 192.168.104.0 255.255.255.0 10.8.0.4
route 192.168.105.0 255.255.255.0 10.8.0.5
route 192.168.001.0 255.255.255.0 10.8.0.32
client-to-client
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
auth-nocache
Beispiel CCD:
Code:
ifconfig-push 10.8.0.2 255.255.255.0
iroute 192.168.102.0 255.255.255.0
push "route 192.168.103.0 255.255.255.0 10.8.0.3"
push "route 192.168.104.0 255.255.255.0 10.8.0.4"
push "route 192.168.105.0 255.255.255.0 10.8.0.5"
push "route 192.168.001.0 255.255.255.0 10.8.0.32"
Client:
Code:
# OpenVPN 2.4.8 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Dec 22 2019
# library versions: OpenSSL 1.0.2t  10 Sep 2019, LZO 2.10
#  Config date: Sun Jan 19 02:12:44 CET 2020
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
ns-cert-type server
remote mybox.mydomain.de
nobind
pull
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
auth-nocache
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
234,016
Beiträge
2,041,625
Mitglieder
353,302
Neuestes Mitglied
Franzlüer