- Mitglied seit
- 9 Apr 2006
- Beiträge
- 687
- 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):
Hier das selbe für den neuen (nicht funktionieren) Clients (10.8.0.2/24):
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:
Clientbox:
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.
Hat jemand diese Verhalten schon beobachtet?
Was kann ich versuchen, um den Fehler zu beheben.
Danke im Voraus und Gruß
maceis
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):
- Wenn ich "Optionen vom Server empfangen" einstelle (wie immer), startet OpenVPN, beendet sich nach ca. 5 bis 10 Sekunden aber wieder.
- 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.
- Mir ist außerdem aufgefallen, dass das tun0 Interface bei der neu eingerichteten Box anders angelegt, als bei den anderen Boxen.
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)
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)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
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-keyHier 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 errorHat jemand diese Verhalten schon beobachtet?
Was kann ich versuchen, um den Fehler zu beheben.
Danke im Voraus und Gruß
maceis
Zuletzt bearbeitet:
