OpenVPN - Networkmanager Verbindungsprobleme

jojo91 · October 31, 2017, 6:32pm

Hallo,

seit der Neuinstallation von OpenSuse 42.3 habe ich folgendes Problem:

Eine OpenVPN-Verbindung, erstellt über den Networkmanager, wird normal gestartet und auch als bereit angezeigt. Allerdings ist weder ein Zugriff auf das interne Netzwerk noch das Internet möglich. In journalctl findet man für den NetworkManager keine Fehler bezüglich OpenVPN, die einzige komische Zeile ist die folgende: (nm-openvpn-service:8071): GLib-CRITICAL **: g_propagate_error: assertion ‘src != NULL’ failed. Die Log-Meldungen danach sehen aber normal aus (Initiierung der Verbindung, Pushen der Routen, …). Merkwürdig ist auch, dass wenn ich das VPN nur für lokale Ressourcen freigebe, nach einiger Zeit das WLAN-Symbol auf “kein Internetzugriff” wechselt (Internetzugriff ist in diesem Szenario auch nicht möglich).

Wenn ich mich jedoch direkt über die Kommandozeile mit dem OpenVPN-Server verbinde tritt kein Problem auf.

Mit der vorher installierten OpenSuse Version (42.1?, vllt. auch älter) gab es keine Probleme.

Hat vllt. jemand eine Idee wonach ich weiter suchen könnte?

Vielen Dank & viele Grüße,

jojo

hendwolt · October 31, 2017, 8:34pm

Hi,

hast Du mal geprüft, ob/wie sich die Routen, DNS-Einträge (resolv.conf) etc. verändern?

Gruß,
Hendrik

jojo91 · November 1, 2017, 8:54am

Hi Hendrik,

also, hab das ganze mal für drei Zustände ermittelt.

Ganz normal im WLAN, kein VPN


# ip route
default via 192.168.2.1 dev wlan0  proto static  metric 600 
192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.249  metric 600 
# cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain
nameserver 192.168.2.1

VPN gestartet über den Netzwerkmanager


# ip route
default via 10.97.83.5 dev tun0  proto static  metric 50 
default via 192.168.2.1 dev wlan0  proto static  metric 600 
10.97.83.0/24 via 10.97.83.5 dev tun0  proto static  metric 50 
10.97.83.5 dev tun0  proto kernel  scope link  src 10.97.83.6  metric 50 
192.168.1.0/24 via 10.97.83.5 dev tun0  proto static  metric 50 
192.168.2.0/24 via 10.97.83.5 dev tun0  proto static  metric 50 
192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.249  metric 600 
192.168.3.0/24 via 10.97.83.5 dev tun0  proto static  metric 50

# cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain
nameserver 192.168.2.1

Wenn man sich die Eigenschaften der resolv.conf ansieht, stellt man fest, dass sie zum Start des VPN’s immer neu geschrieben wird. Allerdings ändert sich nichts…

VPN gestartet über die Kommandozeile


# ip route
0.0.0.0/1 via 10.97.83.5 dev tun0 
default via 192.168.2.1 dev wlan0  proto static  metric 600 
10.97.83.0/24 via 10.97.83.5 dev tun0 
10.97.83.5 dev tun0  proto kernel  scope link  src 10.97.83.6 
128.0.0.0/1 via 10.97.83.5 dev tun0 
192.168.1.0/24 via 10.97.83.5 dev tun0 
192.168.2.0/24 via 10.97.83.5 dev tun0 
192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.249  metric 600 
192.168.2.1 dev wlan0  scope link 
192.168.3.0/24 via 10.97.83.5 dev tun0

Die resolv.conf habe ich mir beim dritten Mal gespart, die sieht identisch zu den beiden vorherigen Versuchen aus.
Was mir gestern noch aufgefallen ist, auch diese Verbindung hat ab und zu Abbrüche (stellt sich nach einem Timeout aber auch wieder selbst her).

Zwischen den Routen in Zustand 2 und 3 gibt es ja einige Unterschiede, wie sind die denn zu interpretieren?

Viele Grüße,

jojo

hendwolt · November 1, 2017, 8:46pm

Ich weiß ja nicht, was Du mit dem VPN alles bezwecken/umleiten willst.
Was mir auffällt ist,
a) mit NetworkManager hast Du 2 default-Routen; mit cli kommt 0.0.0.0/1 ins Spiel, was Vorrang hat.
b) 192.168.2.0/24 wird sowohl über wlan0 als auch über den Tunnel geleitet.
Ich bin jetzt nicht der große Netzwerkexperte, aber das sieht für mich nicht sauber aus.
Das sollte sich m.E. nicht überschneiden.

Wie man das im Networkmanager gerade biegt, kann ich nicht sagen, da ich persönlich auschließlich die Kommandozeile für sowas verwende.

Gruß,
Hendrik

jojo91 · November 2, 2017, 4:23pm

Hi Hendrik,

das war wohl der richtige Hinweis:

Wenn ich die zweite Default-Route entferne (die über wlan0) und in der resolv.conf einen anderen Nameserver setze (z.B. 8.8.8.8) läuft es so wie erwartet (erwartet hätte ich, dass der gesamte Verkehr durch den Tunnel geleitet wird). Mir stellt sich jetzt nur die Frage was sich da so sehr in die Quere kommt, dass der Netzwerk Manager die Routen nicht sauber konfiguriert…

Viele Grüße,

jojo

rlux477 · February 16, 2018, 8:27am

Hallo Community,

diese Unterhaltung ist ja schon etwas älter. Da ich aber ein ganz ähnliches Problem habe, möchte ich es erst einmal hier versuchen, bevor ich ein neues Thema eröffne:

Problem: **Suse Linux Leap 42.3 Problem VPN L2TP/IPSec oderOpenVPN Zugang zu Heimnetz
**
Zum Heimnetz
Adresse: 192.168.45.0
Netzbereich: 255.255.255.0 (192.168.45.0/24)
Gateway: 192.168.45.1 / Fritzbox
DHCP: 192.168.45.10 / SynologyDS
DNS: 192.168.45.10 / SynologyDS Zentraler DNS für Heimnetz mit Auflösung lokaler Servernamen undForwarding der Clientanfragen nach 192.168.45.1 (DNS Fritzbox)
LokaleDomain: luxnet002.local

VPN1
Server auf SynologyDS lokale IP 192.168.45.10
Adresse intern: 192.168.99.0
Adresse extern: No-Ip DDNS Adresse
Protokolle: L2TP/IPSec
Verschlüsselung mit PSK
Portfreigaben UDP … auf Fritzbox eingerichtet
Statische Route 192.168.99.0 auf Gateway 192.168.45.10 auf den Geräten wo erforderlich eingerichtet

VPN2
Server auf SynologyDS lokale IP 192.168.45.10
Adresse intern: 192.168.98.0
Adresse extern: No-Ip DDNS Adresse
Protokolle:OpenVPN
Portfreigaben TCP auf Fritzbox eingerichtet
Statische Route 192.168.98.0 auf Gateway 192.168.45.10 auf den Geräten wo erforderlich eingerichtet

Problem:
VPN Verbindung mit beiden Konfigurationen funktioniert auf Windows- und IOs-Geräten ohne Probleme.
Auf PC mit SUSE LINUX LEAP 42.3 sind die VPN sowie der normale Internetzugang über den Network Manager eingerichtet. Internet wahlweise über WLAN0 und Iphone als Router oder UMTS Stick. Funktioniert beides.
Die VPN Netzwerke sind so konfiguriert dass der gesamte Datenverkehr darüber laufen soll (absichtlich).
Die VPNs werden korrekt verbunden, es findet aber kein Netzwerkverkehr in das VPN statt. Ping 100% Paket Loss.
Die lokale Firewall ist für Testzwecke erst mal aus.

Konfigurationsausgaben von VPN2
[route]

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.98.9    0.0.0.0         UG    50     0        0 tun0
default         172.20.10.1     0.0.0.0         UG    600    0        0 wlan0
172.20.10.0     *               255.255.255.240 U     600    0        0 wlan0
192.168.45.0    192.168.98.9    255.255.255.0   UG    50     0        0 tun0
192.168.98.0    192.168.98.9    255.255.255.0   UG    50     0        0 tun0
192.168.98.1    192.168.98.9    255.255.255.255 UGH   50     0        0 tun0
192.168.98.9    *               255.255.255.255 UH    50     0        0 tun0
pD950D88C.dip0. 172.20.10.1     255.255.255.255 UGH   600    0        0 wlan0

[FONT=arial]

[ip route]

default via 192.168.98.9 dev tun0  proto static  metric 50 
default via 172.20.10.1 dev wlan0  proto static  metric 600 
172.20.10.0/28 dev wlan0  proto kernel  scope link  src 172.20.10.2  metric 600 
192.168.45.0/24 via 192.168.98.9 dev tun0  proto static  metric 50 
192.168.98.0/24 via 192.168.98.9 dev tun0  proto static  metric 50 
192.168.98.1 via 192.168.98.9 dev tun0  proto static  metric 50 
192.168.98.9 dev tun0  proto kernel  scope link  src 192.168.98.10  metric 50 
217.80.216.140 via 172.20.10.1 dev wlan0  proto static  metric 600

[if Config]


lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:96 errors:0 dropped:0 overruns:0 frame:0
          TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:7568 (7.3 Kb)  TX bytes:7568 (7.3 Kb)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.98.10  P-t-P:192.168.98.9  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:840 (840.0 b)

wlan0     Link encap:Ethernet  HWaddr 74:EA:3A:E8:E9:2B  
          inet addr:172.20.10.2  Bcast:172.20.10.15  Mask:255.255.255.240
          inet6 addr: 2a01:598:8187:a326:76ea:3aff:fee8:e92b/128 Scope:Global
          inet6 addr: fe80::76ea:3aff:fee8:e92b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3417 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2787 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3152045 (3.0 Mb)  TX bytes:385638 (376.5 Kb)

[ping]

PING 192.168.45.10 (192.168.45.10) 56(84) bytes of data.

--- 192.168.45.10 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4031ms

Woran kann das liegen?
Falls es am Network-Manager liegt, wäre ich auch über Hinweise, wie man das alternativ einrichtet, dankbar (Yast, notfalls auch erstmal mit Kommandozeile, hauptsache, es geht überhaupt.

Freundliche Grüße
Rainer

[/FONT]
**
**