VPN Probleme "unable to install source route"

Es gibt 13 Antworten in diesem Thema, welches 3.973 mal aufgerufen wurde. Der letzte Beitrag () ist von LuiJones.

    Hallo,


    ich habe das Problem, dass das Routing innerhalb meiner VPN Verbindung nicht sauber funktioniert. Die VPN-Verbindung (Site-to-Site / Manual IPSec) wird zwar auf beiden Seiten hergestellt, doch erreiche ich die Systeme untereinander nicht. Da ich nur einen Controller für beide Seite verwendet, ist das ein Problem.


    Gelegentlich funktioniert es auch, die letzten Tage jedoch eher weniger, also bin ich grad auf der Suche nach der Ursache.


    Kurze Umgebungsbeschreibung:


    Seite A (Home): FritzBox (192.168.2.0/24) -> USG (192.168.1.0/24)

    Seite B (Garten): TPLink (192.168.5.0/24) -> USG (192.168.10.0/24)


    Nachdem die VPN-Verbindung hergestellt wurde, bekomme ich im Controller (7.1.61.0) nur bei Gesendet die übertragenen Daten angezeigt, wenn ich z.B. ein Gerät auf der anderen Seite anpinge. Mir ist aufgefallen, dass der Datenverkehr in dem Fall auch über das Internet geht, da beim tracert der erste Hop nach dem USG immer die FritzBox ist. D.h. der Traffic geht nicht über VPN sondern über WAN. Somit ist die Anzeige der gesendeten Bytes in diesem Fall möglicherweise irrführend.


    Innerhalb der VPN-Verbindung auf Seite A habe ich als Subnet 192.168.5.0/24 hinterlegt. Dynamisches Routing ist inaktiv, da ich in der Vergangenheit, gerade bei der Angabe mehrerer Subnets damit Probleme hatte. Ich vermute die Gegenstelle (TPLink) kann damit nicht umgehen. So wie ich gelesen hatte, ist es eigentlich nicht erforderlich, zusätzliche statische Routen zu hinterlegen.


    Da es sporadisch auch funktioniert, muss es ein anderes Problem sein. Ich hatte die Vermutung es hängt mit der Routing-Table zusammen, das die gewünschte Route eine zu hohe Metrik hat und er in den meisten Fällen aktuell einen anderen Weg geht.


    Was mich wundert ist, dass es innerhalb der Routing-Table dazu gar keinen Eintrag gibt:

    Code
    ubnt@USG:~$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         fritz.box       0.0.0.0         UG        0 0          0 eth0
loopback        *               255.0.0.0       U         0 0          0 lo
192.168.1.0     *               255.255.255.0   U         0 0          0 eth1
192.168.2.0     *               255.255.255.0   U         0 0          0 eth0

    Beim Durchforsten der Logdatei ist mir folgender Eintrag aufgefallen:

    Code
    ubnt@USG:~$  show vpn log
...
Jul 21 21:59:58 00[DMN] Starting IKE charon daemon (strongSwan 5.2.2, Linux 3.10.107-UBNT, mips64)
Jul 21 21:59:59 07[KNL] received netlink error: Network is unreachable (128)
Jul 21 21:59:59 07[KNL] unable to install source route for 192.168.1.1
...

    Hat jemand eine Idee, wo genau das Problem besteht?

    Hast du zufällig Failover aktiviert?

    Falls ja, deaktiviere es mal bitte Testweise.

    Gruß

    defcon

    Was mich wundert ist, das in der Routing-Table nichts von dem Subnet drin steht, aber vielleicht ist das ja auch normal so. Ich habe allerdings noch ein weiteres VPN auf meinem USG bei Standort A hinterlegt, ein Remote-Benutzer VPN (L2TP) für die Einwahl z.B. per Handy. Hier habe ich als Subnet 192.168.50.0/24 hinterlegt. Beim letzten Mal hatte ich dieses Subnetz von 192.168.1.0./24 in 192.168.50.0/24 geändert, der USG hat sich reprovisioniert und plötzlich stand meine site-to-site VPN-Verbindung, bzw. hat das Routing erwartungsgemäß funktioniert. Ich hatte daher im ersten Moment angenommen, es würde mit dem ursprünglichen Subnetz zusammenhängen. Da es nun aber wieder nicht geht, muss es eine andere Ursache geben. Aber auch das 192.168.50.0/24 sehe ich in der Routing-Table nicht.

    Zitat von LuiJones

    Seite A (Home): FritzBox (192.168.2.0/24) -> USG (192.168.1.0/24)

    Seite B (Garten): TPLink (192.168.5.0/24) -> USG (192.168.10.0/24)

    ?????

    Irgendwie komme ich da nicht mit. Üblicherweise wird eine IPsec Site2Site Verbindung zwischen jeweils zwei Geräten (z.B. VPN-Routern) an den Netzwerkkanten aufgebaut - wer macht hier bei Dir was?


    An sonst ist IPsec zweiteilig, der Transportmodus stellt die Verbindung zwischen den Endpunkten her und der Tunnelmodus verbindet die (zwei) entfernten Netze miteinander. Ersteres scheint bei Dir ja zu funktionieren, nur die Netze finden nicht zueinander. Hierfür gibt man i.d.R. aber lediglich die wechselseitig zu verbindenden Netze an, z.B so:


    Standort A --> lokales Netz 192.168.x.0 - entferntes Netz 192.168.y.0

    Standort B --> lokales Netz 192.168.y.0 - entferntes Netz 192.168.x.0


    Das funktioniert immer -auch zwischen völlig unterschiedlichen VPN-Routern-, besondere Routingangaben sind nicht erforderlich. Lustig wird es aber, wenn man sich an diese einfache Regel nicht hält und versucht, irgendwelche wilden Subnetze oder Vlans miteinander zu verknüpfen, so wie Du es augenscheinlich mit Deinen vier Netzen vor hast. Dann viel Glück bei der Konfiguration :smiling_face:

    Bei mir wird die Verbindung zwischen dem USG (Seite A) und dem TP-Link (Seite B) hergestellt. Das USG auf Seite B ist erst später dazu gekommen und die FritzBox auf Seite A dient als Internetzugang für einen Mehrfamilienhaushalt.

    Das mit dem Tunnelmodus, welcher womöglich nicht zustande kommt, klingt interessant. Kann man das irgendwo auf dem USG nachvollziehen?


    Bei mir sieht das wie folgt aus:




    Innerhalb des USG kann ich ja mehrere Subnetze angeben, wenn ich das erforderlich ist. Im TP-Link ist das jedoch nicht möglich. Die Option "Dynamsiches Routing" hat in der Vergangheit bei mir nie funktioniert. Ich hatte hier die Vermutung, das der TP-Link diese Option nicht unterstützt.

    Einmal editiert, zuletzt von LuiJones ()

    Zitat von LuiJones

    Bei mir wird die Verbindung zwischen dem USG (Seite A) und dem TP-Link (Seite B) hergestellt.

    Also wenn der TP-Link schon VPN kann (und macht), warum nicht auf der anderen Seite nicht die Fritzbox? Dann hättest Du zwei Kisten an den Netzwerkkanten, welche sich sicher ohne Probleme miteinander verbinden ließen.

    So musst Du nun die Fritte dazu bringen, einen auf VPN-Passtrought zu machen und auf NAT zu verzichten, ob dies gelingt . Auch ist das Durchleiten von Vlans durch einen VPN-Tunnel ohnehin problematisch und nur mit Tricks möglich (siehe z.B. hier , bitte auch den Link im Link beachten).


    Wenn du dann tatsächlich an Deinen Standorten eine Netzwerksegmentierung benötigt, mach diese jeweils lokal und lass das VPN damit in Ruhe. So mache ich es und dies funktioniert ohne Weiteres im Prinzip so: lokales Netz -> Tunnel -> entferntes Netz -> Routing zu weiteren entfernte Netzen. Damit komme ich z.B. von lokal in die DMZ auf der entfernten Seite (allerdings mit ganz anderen Routern) :smiling_face:


    Ach so, warum nimmst du eigentlich IKEv1? Das ist bei der Implementierung und Einrichtung fehlerträchtig (und langsam), versuche es mit v2 - vielleicht liegt ja schon da der Hund begraben. Und schalte mal alle "Autoptimierungen" auf dem USG ab.

    IKEv2 habe ich versucht, allerdings kommt da nicht mal der Tunnel zustande. Ich vermute das wird vom TP-Link nicht unterstützt. Dort steht es auf "Auto (IKE)". Als ich dann wieder IKEv1 kam zumindest der Tunnel wieder zustande.


    Wie schalte ich die "Autoptimierungen" auf dem USG ab, bzw. was ist damit gemeint?


    Zur meiner/unserer FritzBox. Bei uns ist es so, dass die FritzBox quasi die Einwahl in einem Mehrfamilienhaushalt übernimmt. Darunter hängen dann noch mal verschiedene Router, welche dann das Netzwerk bzw. WLAN für die jeweilige Familie bereitstellen. In meinem Fall sind das mittlerweile ein USG und ein AP. Ich administriere zwar auch die FritzBox, möchte dort aber ungern persönliche Zugänge und Passwörter hinterlegen. Firewall-Regeln oder Routen wären hingegen kein Problem.


    Dann hattest du was von VLANs geschrieben. Ich habe bisher noch gar keine VLANs bei mir im Einsatz. Eigentlich sind es auf beiden Seiten normal Netzwerke mit jeweils einem Subnetz. Auf Seite B (also im Garten) hängt zwar ebenfalls noch ein USG, doch habe ich zu diesem bisher über diesen Weg noch keine Verbindung aufbauen können. Da ich nur ein Controller für beide Standorte habe, muss man das auch immer etwas mit Vorsicht genießen, da man sonst ruckzuck die gegenüberliegende Seite gar nicht mehr erreicht.

    Die Tage hatte ich mal wieder Glück



    und konnte die Gegenüberliegende Seite erreichen



    Nachdem sich die PublicIP geändert hat und ich das VPN reprovisionieren musste, ging es dann jedoch wieder nicht mehr.

    Zitat von LuiJones

    Hier mal die Skizze aus einem anderen Posting von mir, ich hoffe das genügt fürs erste:

    Tja, da siehst Du doch schon selbst, wo der Hund begraben ist :grinning_face_with_smiling_eyes: Denn tatsächlich läuft der VPN-Traffic ja so (rote Linien):



    Damit dies so funktioniert und man Ipsec site2Site verwenden möchte, müssen beide den USGs vorgeschaltenen Kisten VPN-(Ipsec) Passthrough beherrschen. Die Fritzbox kann dies (ist hier ab Werk auch eingeschalten), der TP-Link kann es augenscheinlich nicht. Entweder bekommst Du diesem das dann auch beigebogen oder das Ganze wird nichts. Das Problem wird hier nämlich durch das Umschreiben (NAT) der IPsec-Pakete verursacht, wodurch diese ungültig werden. Hier kann man auch nichts dran drehen, denn die gesamten Informationen sind verschlüsselt und die kann der Router nicht mitlesen.


    Solltest du dann doch den TP-Link zu Ipsec-Passthrough überreden können, kommt das nächste Problem. Ipsec-Passthrough funktioniert nämlich nur mit genau einen (!) Client. Daher werden sich die USGs durchaus gegenseitig sehen können, was jedoch mit den Clients in den dahinter liegenden Netzen ist, . Das wirst Du schlicht und ergreifend probieren müssen.


    An sonst verstehe ich ohnehin nicht, warum du unbedingt die USGs zum Aufbau eines VPNs nutzen willst. Dass Dein TP-Link Ipsec kann, weißt Du ja und das die Fritten dies auch gut beherrschen, ist ebenfalls bekannt, das Einfachste ist daher, die beiden miteinander zu verheiraten (grüne Linien oben im Bild). Dann hast Du quasi eine Standleitung zwischen Deinem 2er und 5er Netz und regelst den Rest mittels Roting in den USGs. Aber ich sags ja immer, warum einfach, wenn es auch kompliziert geht!


    Willst du jedoch weiterhin die USGs verwenden, dann böte sich vielleicht OpenVpn an, welches keine NAt-Problem verursacht. Im Gegensatz zu Ipsec ist dies jedoch nicht im IP-Protokoll implementiert und braucht daher auf beiden Seiten die OpenVPN-Software, bzw. Router, auf welchen diese läuft. Dies soll bei der USG der Fall sein, jedoch nicht ohne ein paar Konfigurationsorgien Konfigurationsorgien.


    Aber egal, wie du es auch drehst, du wirst in jedem Fall entäuscht sein, was die erzielbare Bandbreite betrifft. Was dein TP-Link kann, weiß ich nicht, aber die herkömmlichen Fritten schaffen bestenfalls ca. 20 Mbit/s und die USGs werden nicht viel besser sein. Nur mal so zum Vergleich, ich liege z.Z. bei ca. 57 MB/s, daher rund 450 Mbit/s:



    Dies allerding mit richtigen Firewall-Appliancen und zufrieden bin ich damit auch noch nicht ganz. Allerdings kann man damit dann schon so mit den entfernten Netzwerken arbeiten, als wäre man direkt vor Ort. Dies wird mit Deiner Lösung nicht möglich sein.

    Ich kann dir leider nicht in allen Sätzen folgen. Du scheinst dich mit VPN sehr gut auszukennen, meine Kenntnisse sind da eher oberflächig.

    Ich hätte nicht gedacht, dass es kein Problem ist, wenn der Traffic über mehrere Zwischenstationen läuft. Wirkt sich das stark auf die Performance aus?


    Der TP-Link beherscht das Durchschleifen verschiedener Protokolle.



    Mir sind in den letzten Tagen auch verschiedene Verbindungen zwischen den USGs bzw. von Handy zu USG im Standort B gelungen. Seltsamerweise scheint auch meine SiteBySite-Verbindung aktuell zusätzlich zu bestehen.

    Ist es eigenltich ein Problem, wenn mehrere VPN-Verbindungen unterschiedlicher Art parallel bestehen?


    Was ich schade finde ist, das ich auf dem USG zwar ein PPTP- und L2TP-Server erstellen kann, aber nur einen PPTP-Client. :-/


    Aktuelle habe ich also eine SiteToSite Verbindung zwischen USG (A) und T-Link (B) und eine PPTP zwischen USG (A) und USG (B). Ich weiß das dies alles noch nicht optimal ist, aber bisher ist es mir noch nicht gelungen über die bestehende SiteToSite Verbindung auf das Subnet des darunterliegenden USGs zuzugreifen, welches noch mal zwei zusätzliche Subnetze bereitstellt. Würde sich das über ein Routing realisieren lassen? Im TP-Link ist die Route hinterlegt, aber Standort A weiß ja bisher nicht, dass die Ziel-Adressen bei Standort B liegen. Wenn ich die zusätzlichen Subnetze bei meiner VPN-Verbindung mit hinterlegt hatte, gab es immer Problem. Weil anscheinend der TP-Link auf der gegenüberliegenden Seite nicht mehr als ein Subnetz verarbeiten kann. Ich könnte nur noch mal versuchen die 2 Netze als zusätzliche Route anzugeben, aber ich glaub das hatte ich schon mal versucht, jedoch ohne Erfolg.


    Noch mal zurück zu deinem Tipp und meine Frage:

    Wie schalte ich die "Autoptimierungen" auf dem USG ab, bzw. was ist damit gemeint?