UDM-Pro - Site-to-Site VPN nicht anpingpar

Es gibt 14 Antworten in diesem Thema, welches 2.888 mal aufgerufen wurde. Der letzte Beitrag () ist von Alex1984.

    Hallo zusammen,


    ich möchte gerne einen Cloud-Server (Debian11 mit StrongSwan) mit meinem lokalen Netzwerk per Site-to-Site VPN verbinden.

    Hierzu habe ich eine entsprechende Konfiguration in der UDM-Pro hinterlegt (IPsec) und auch die Konfig auf dem Debian-Server hinterlegt, so dass die Verbindung erfolgreich aufgebaut werden kann.

    Allerdings kann ich von der UDM-Pro nicht die interne IP des Debian-Servers anpingen und andersherum.



    Ich hätte jetzt erwartet dass ich von der UDM-Pro den Debian-Server per 10.99.0.2 anpingen kann und ich andersrum die UDM-Pro unter 10.99.0.1 anpingen kann - aber das ist leider nicht der Fall.


    Könnt ihr mir helfen, welcher Schritt jetzt noch fehlt?


    Vielen Dank und viele Grüße,

    Alex

    Hallo Alex1984


    Ich war mal so frei und habe dein OP Titel angepasst sowie ins richtige Forum verschoben.


    LG
    ꧁𓊈𒆜 ƁєηLυє 𒆜𓊉꧂

    ⢀⣴⠾⠻⢶⣦⠀ Debian - The universal operating system user
    ⣾⠁⢠⠒⠀⣿⡁ https://www.debian.org
    ⢿⡄⠘⠷⠚⠋⠀
    ⠈⠳⣄⠀

    :right_arrow: Dumme Gedanken hat jeder, nur der Weise verschweigt sie. (Wilhelm Busch) :left_arrow:

    Gefällt mir 1
    Zitat von Alex1984

    Ich hätte jetzt erwartet dass ich von der UDM-Pro den Debian-Server per 10.99.0.2 anpingen kann und ich andersrum die UDM-Pro unter 10.99.0.1 anpingen kann - aber das ist leider nicht der Fall.

    Sehe ich das richtig, die Seite mit der UDM und die Seite mit dem Debian benutzen den gleichen Netzwerkbereich? Dann funktioniert die Sache nicht, rechtes und linkes, respektive lokales und entferntes Netz müssen sich unterscheiden, z.B. so (ok, sind ein paar mehr :smiling_face::frowning_face:



    Außerdem - was sitzt vor dem Debian? Ist da eine Firewall, muss die natürlich entsprechend konfiguriert sein um den Debian über die öffentliche IP zu erreichen, bzw. muss man den Debian den Verbindungsaufbau initieren lassen. Bei s2s-VPN ist es eh immer besser, dass von den Kisten an den Netzwerkgrenzen erledigen zu lassen, die Zugrifsrechte in den verbundenen LANs recgelt man dann per ACLs.

    Moin und danke erstmal für die Rückmeldung.


    Die UDM-Pro hat als interne Adresse die 192.168.1.1 (und noch die Gateway-IPS von ein paar weiten Netzwerken/VLANs).

    Der Debian-Server hat die lokale IP 10.99.0.2 (und natürlich seine öffentliche statische IP).


    Ein neues Netzwerk für das VPN habe ich noch nicht angelegt. Falls benötigt, würde ich mein „lokales“ DMZ-Netzwerk dafür verwenden. Ich habe aber bisher keine Möglichkeit gefunden, dieses zuzuordnen, wie z.B. bei einem Standard-VPN.



    Vielleicht noch ganz hilfreich: Was will ich eigentlich machen?

    Ich möchte auf dem Cloud-Server einen Reverse-Proxy laufen lassen, der dann autorisieren Traffic auf meine lokal gehosteten Services leitet.

    Einmal editiert, zuletzt von Alex1984 ()

    Zitat von Alex1984

    Die UDM-Pro hat als interne Adresse die 192.168.1.1 (und noch die Gateway-IPS von ein paar weiten Netzwerken/VLANs).

    Der Debian-Server hat die lokale IP 10.99.0.2 (und natürlich seine öffentliche statische IP).

    Also ich kenne es bei IPsec VPN angefangen mit der Fritte (noch über ISDN-DSL) über Netgear-VPN-Routern bis hin zur Sophos so, dass man zum Verbindungsaufbau neben der Authentifizierung (shared key / Zertifikat) und den Verschlüsselungsalgorithmen für die Phasen 1 und 2 vor allem dies benötigt:

    • die öffentliche IP, respektive den FQDN des lokalen und des entfernten VPN-Servers/Dienstes
    • den IP-Bereich des lokalen und des entfernten Netzes (können auch mehrere sein - siehe oben), wobei sich diese Bereiche immer unterscheiden müssen (z.B. lokal 192.168.10.0, entfernt 192.168.20.0 und halt umgedreht, wenn man von der anderen Seite schaut)
    • ein frei wählbarer ID-Typ (z.B. DNS, IP oder Email) nebst der lokalen und entfernten ID

    Auf diese Weise verbindet man dann i.d.R. die Borderrouter, wobei deren expliziten lokalen Adressen ohne Belang sind, denn schließlich verbindet man ganze Netze.


    Mit Deinem Strong Swan sollte dies eigentlich identisch funktionieren, wobei auf der UDM die öffentliche IP des Debian als entferntes Gateway und die lokale IP des Debian als entferntes Netz eingetragen werden müssten (funktioniert dies mit einem einzelnen Host nicht, muss man halt ein Mininetz anlegen). Ergo ist es sodann auf dem Debian genau umgekehrt. Hier trägt man dann die öffentliche IP der UDM als entferntes Gateway und die Netze, mit welchem die Verbindung erfolgen soll und welche die UDM verwaltet, als entferntes Netz ein.


    So sollte es eigentlich problemlos funktionieren. Denke aber bitte daran, dass die UDM-Pro nur die automatische Schlüsselverwaltung IKEv.1 kann und der Debian daher enstprechend konfiguriert werden muss. Außerdem akzeptiert die UDM kein FQDN für die entfernte Seite, hier möchte diese zwingend eine IP haben.

    Danke für die Antwort.


    Ich finde den Fehler nur leider irgendwie nicht in der Konfiguration:


    Die UDM ist über eine FQDN erreichbar (vpn.domain.de).

    Als lokale IP hat sie die 192.168.1.1 (255.255.255.0)


    Der Debian-Server ist über eine öffentliche, statische IPv4 erreichbar.

    Als lokale IP hat er die 10.99.0.2 (255.255.255.0)


    Die öffentliche IP des Debian-Servers ist in der UDM-Pro als Remote-Adresse hinterlegt.

    Die FQDN der UDM-Pro ist als "right" auf dem Debian-Server hinterlegt.


    Ich vermute ich verstehe etwas nicht richtig oder übersehe etwas - bin für eure Tipps sehr dankbar!


    Viele Grüße,

    Alex

    Right und left verwechselt? An sonst - ich schrieb es ja schon, die localen IP-Adressen der beteiligten Kisten sind eigentlich uninteressant, wichtig sind die Adressen der Netze, welche verbunden werden sollen (dabei dürfen sich Kisten natürlich in diesen Netzen befinden). Leider kann ich Dir nicht mit der Konfigurationsmaske einer UDM-Pro dienen, aber der Sophos sieht das so aus, wobei auf der anderen Seite dann die Einträge genau gespiegelt sind:



    Die Darstellung und Bezeichnungen mögen sich von Routermodell zu Routermodell unterscheiden, gleichen sich aber grundsätzlich, hier einmal von einem alten Netgear:



    Unter Umständen funktioniert es auch, die entfernte Seite auf "any" zu setzen, so hatte ich dies mal im Jahr 2011:



    Naja, vielleicht hilft es Dir ja.

    Ich bin jetzt schon mal ein Stück weiter und habe es geschafft, vom Cloud-Server auf mein internes Netzwerk zuzugreifen (IPSEC-Config auf dem Debian-Server angepasst).


    Jetzt komme ich nur nicht von der UDM-Pro auf den Cloud-Server, folgende Firewall-Regeln habe ich definiert:

    Ich habe heute noch mal rum probiert, bin aber nicht wirklich weiter gekommen.

    Die Route zum Remote Netzwerk sollte die UDM doch selbst erstellen, oder?

    Jedenfalls sehe ich einen Eintrag für das Netzwerk in der UDM-Pro:

    Zitat von Alex1984

    Die UDM ist mein Router. Ich habe kein doppeltes NAT.

    Sorry, dann habe ich Deinen Netzwerkaufbau nicht verstanden. Bisher nahm ich an, dass Du eine VPN-Verbindung übers Internet zwischen einer UDM auf der einen Seite und einem Debian auf der anderwen Seite aufbauen willst und bin automatisch davon ausgegangen, dass der Debian in einem LAN sitzt, welches wie üblich über ein Router ans Internet angebunden ist. Da dies ja nun nicht der Fall zu sein scheint, erklär doch mal, was Du da gebaut hast.


    Übrigens, von doppelten NAT schrieb ich an keiner Stelle etwas.

    Um noch mal zum eigentlichen Thema zurück zu kommen:


    Ich vermute, dass in der UDM noch was hakt - wenn ich Traceroute ausführe, bleibe ich bei der internen IP der UDM hängen:

    Code
    traceroute to 10.99.0.2 (10.99.0.2), 30 hops max, 46 byte packets
 1  unifi (192.168.1.1)  0.006 ms !H  0.006 ms !H  0.005 ms !H

    Sollte durch das S2S-VPN nicht automatisch die Route erzeugt werden?

    Weiter oben in einem Post konnte man ja auch sehen, dass die eigentlich vorhanden ist.


    Und noch eine Frage ergänzend:

    Die UDM hat leider nur eine dynamische IP. Mir ist jetzt aufgefallen, dass ich bei meinen Tests jetzt jeden Abend die "Unifi Gateway IP" neu auf WAN1 setzen muss. Ist das "normal" und kann man da was gegen machen? Ich hätte jetzt erwartet, dass die sich automatisch mit aktualisiert und das Feld nicht auf initial gesetzt wird.