Beiträge von LuiJones

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.

Failover kommt doch nur zum Einsatz, wenn ich WAN2 nutze und dort z.B. einen zusätzlichen LTE-Breakout habe oder? In meinem Fall wird nur Standart-WAN und LAN genutzt.

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:

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:

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?

Hat leider noch nicht geklappt. Habe gerade noch ein wenig herumprobiert. Trotz der freigegebenen Ports kommt der Tunnel nicht zustande.
Was mich immer wundert ist, sobald ich die VPN-Verbindung im USG von Standort B aktiviere, ist kurz darauf mein UAP von Standort B nicht mehr erreichbar. Es hat den Anschein, als würde dieser dann über das USG den Controler nicht mehr erreichen. Zuvor ist das ja noch möglich, weil der davorliegende TP-Link die VPN-Verbindung hergestellt hat und somit die Verbindung zum Controler ermöglicht. Das USG hat noch eine Verbindung, aber der UAP nicht. Selbst wenn ich die VPN-Verbindung im USG trenne, findet der UAP nichts. Ich muss das USG erst rebooten, bevor der UAP wieder eine Verbindung hat.

Das macht in sofern Sinn, da der UAP anscheinend das Routing schon nicht mehr über den TP-Link vornimmt, das USG hingegen schon, da es noch direkt daran hängt. Aber die Verbindung kommt an irgendeiner Stelle nicht zustanden, sonst wird der UAP den Controller von Standort A bereits wieder finden.

Danke für die Ports, ich werds gleich mal probieren ...

Eigentlich läufts diese nicht als Exposed Host. Anfang hatte ich damit experimentiert. Als die Verbindung dann aber auch ohne Freigaben bzw. Forwardings funktionierte, hatte ich alles wieder deaktiviert. Auch die selbstständige Freigabe ist inaktiv:

Guter Hinweis, das habe ich tatsächlich bisher noch nicht. Da es auf der FritzBox (Standort A) bisher aber auch ohne geklappt hatte, dachte ich bisher das dies in meinem Fall gar nciht notwendig sei.
Hast du die notwendigen Ports eventuell parat?

Hallo Liebe Gemeinde,

ich habe seit ein paar Wochen ein Problem, vielleicht könnt ihr mir helfen.

Ich habe zwei Standorte (Home & Garten) per VPN (IPSec) miteinander verbunden. Das hat auch soweit funktioniert. Im Home-Bereich kommt ein USG zum Einsatz und im Garten bisher ein TP-Link Router mit LTE Modem. Jetzt habe ich dort ebenfalls ein USG, um zukünftig meine APs über diesen verwalten zu können. Ich bekomme aber irgendwie die VPN Verbindung zwischen beiden USGs nicht zustande. Der TP-Link Router ist noch vor dem USG, bis dahin klappt es mit der VPN-Verbindung, aber bis zum USG dann nicht. Wir haben hier doppeltes NAT, aber das ist auch im Home-Bereich der Fall, da hier das USG auch hinter einer Fritzbox hängt.

Also es gibt folgende Netze:

Standort A:

192.168.2.0/24: Fritz-Box

192.168.1.0/24: Home-LAN mit USG

Standort B:

192.168.5.0/24; TP-Link

192.168.10.0/24: Garten-LAN mit USG

Es gibt nur einen Controller und der ist im Home-Bereich. Seltsam ist auch, das der AP der im Garten am USG hängt, nach der Definition der VPN-Verbindung nicht mehr erreichbar ist. Der sollte davon eigentlich gar nicht beeinflusst werden. Ich habe die Konfiguration hier analog der bereits bestehenden VPN-Verbindung vorgenommen, also mit entsprechender Gateway IP.

Ist das eigentlich ein Problem, wenn 2 VPN-Verbindungen bei der gleichen Peer-IP einlaufen?

Ich hoffe das war alles einigermaßen verständlich.

Zum besseren Verständnis habe ich hier noch mal eine Übersicht erstellt:

Um auszuschließen, das sich die bereits bestehende VPN-Verbindung zwischen USG (A) und TP-LINK (B) mit der zusätzlichen zwischen den beiden USG behindern, habe ich diese auch zwischenzeitig deaktiviert. Dennoch kamn die Verbindung zwischen beiden USG nicht zustande. Die Verbindung zwischen USG und TP-Link ermöglich mir im Moment jedoch das USG bei Standort B überhaupt zu konfigurieren, da der Controler innerhalb von Standort A ist und die Komponenten von Standort B nur bei bestehender VPN-Verbindung über diesen verwaltet werden können.

Kann man aus den Logdateien zusätzliche Hinweise gewinnen, wo es hier klemmt?