Firewallkonfiguration für mehrere Unifi Installationen, die per VPN verbunden sind

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

    Hallo,



    ich tue mich etwas schwer mit der Syntax (lan, internet, in, out, …) und brauchte mal Eure Hilfe.



    Ich betreibe 5 Unifi Installationen, die per fester Internet-IP und VPN miteinander verbunden. Jede Installation hat ihren eigenen Cloud Key, oder UDM.



    Zentrale 10.1.0.0/24


    Objekt1 10.2.0.0/24


    Objekt2 10.3.0.0/24


    ……


    Objekt5 10.6.0.0/24



    Im Moment ist alles aus jedem Netz erreichbar.



    Ich möchte:



    - aus der Zentrale alle IP-Adresse in den Objekten erreichen können


    - aus Objekt1 soll die Zentrale und die anderen Objekte nicht erreichbar sein


    - bei Bedarf möchte ich für eine einzelne IP-Adresse aus Objekt1 eine Ausnahme gestallten: 10.2.0.100 soll 10.1.0.100 erreichen



    Für ein konkretes Beispiel wäre ich Euch sehr dankbar



    VG Gerd

    Hi,


    alle VPN Verbindungen "Site-to-Site" und Routenbasiert?


    Habe vor kurzem erst ein ähnliches Projekt umgesetzt.


    Größtes Problem dabei war es zu verstehen, dass der gesamte Verkehr über Lan OUT Rules gemanaged werden muss da die "Zentrale" den Datenverkehr bei einem Site-to-Site VPN als Lokal ansieht und erst ab seiner eigenen LAN Schnittstelle kennt. (so habe ich es zumindest verstanden)


    Habe alle VPN Netze in einer Portgruppe zusammengefasst und eine LAN Out Reject Regel erstellt um den Datenverkehr untereinader zu unterbinden. Gleichzeitig eine Regel für das Hauptnetz - in deinem Fall "Zentrale" angelegt welche vorher greift und den Verkehr auf bestimmte IP Adressen zulässt.


    Reject statt Drop damit ich im Zweifelsfall etwas im Syslog sehen kann..

    Zitat von aequus

    Du VPN Tunnel gehen immer von Zentrale zu Objekt 1 bis 5. Objekt 1 kann Objekt 2 nicht erreichen

    Ahh ok, hätte mich auch gewundert. Das geht übrigens, wenn Du in Objekt 1 eine Route für Objekt 2 anlegst und auf die Zentrale zeigst. Das gleiche dann in Objekt 2 für Objekt 1. Gut ist meistens nicht erwünscht und belastet dann die Zentrale sinnfrei. Da würde sich dann ein Tunnel von Objekt 1 zu 2 direkt besser machen.


    Das nur so als Info.

    Das sieht schonmal gut aus. Entspricht in etwa dem was man auch Konfiguriert wenn man Inter VLAN Traffic blockt. Ist ja technisch auch nix anderes.


    Müsste man auch bei den Aussenstellen in LAN/IN packen können, dann schubst Du keinen Traffic durch den Tunnel der am anderen Ende rejected oder gedroppt wird. Muss dann natürlich angepasst werden Source -> das Aussenstellen Netz und Destination das Netz der Zentrale. Und in der Zentrale sollte es für Pakete zu den Aussenstellen auch in LAN/IN klappen. Denn hat man RFC1918 zu RFC 1918 geblockt (wegen Inter VLAN Traffic), dann blockt das ohne Anpassung auch den Traffic in den Tunnel, denn da sollten ja nur private IPs am anderen Ende sein.


    Kann man je Richtung an 2 Stellen machen. Wer es extrem möchte macht es an beiden Stellen :smiling_face:

    Zitat von DoPe

    Das sieht schonmal gut aus. Entspricht in etwa dem was man auch Konfiguriert wenn man Inter VLAN Traffic blockt. Ist ja technisch auch nix anderes.


    Müsste man auch bei den Aussenstellen in LAN/IN packen können, dann schubst Du keinen Traffic durch den Tunnel der am anderen Ende rejected oder gedroppt wird. Muss dann natürlich angepasst werden Source -> das Aussenstellen Netz und Destination das Netz der Zentrale. Und in der Zentrale sollte es für Pakete zu den Aussenstellen auch in LAN/IN klappen. Denn hat man RFC1918 zu RFC 1918 geblockt (wegen Inter VLAN Traffic), dann blockt das ohne Anpassung auch den Traffic in den Tunnel, denn da sollten ja nur private IPs am anderen Ende sein.


    Kann man je Richtung an 2 Stellen machen. Wer es extrem möchte macht es an beiden Stellen :smiling_face:

    Genau so ist es am Sinnvollsten und natürlich performanter wie du bereits geschrieben hast macht es keinen Sinn den Traffic erst über den Tunnel zu schicken nur damit er am anderen Ende wieder abgelehnt wird :D. Steht auch noch auf meiner Liste das abzuändern. :thumbs_up:

    Zitat von LD Tech-Solutions


    Habe alle VPN Netze in einer Portgruppe zusammengefasst und eine LAN Out Reject Regel erstellt um den Datenverkehr untereinader zu unterbinden. Gleichzeitig eine Regel für das Hauptnetz - in deinem Fall "Zentrale" angelegt welche vorher greift und den Verkehr auf bestimmte IP Adressen zulässt.


    Reject statt Drop damit ich im Zweifelsfall etwas im Syslog sehen kann..

    ich hoffe ich habe es richtig verstanden: Alle Netze (zentrall + alle Objekte) habe ich ein eine Port/IP Gruppe zusammen gefasst. Mit der Reject Regel kann ich der Zentrale nicht mehr erreichen -> soweit wohl richtig

    kannst die Allow Regel für die Zentrale noch zeigen?

    habe ich gemacht, es funktioniert aber nicht. Die Regel ist unter der Nummer 2001 aktive, aber ich trotzdem noch von Object1 nach Zentrale pingen. in der Portgroup habe ich alle Netze, ausser Zentrale in der Form 10.2.0.0/24 beschrieben. Bei deinem Bespiel taucht die Portgruppe Aussenstelle sowohl bei Source, als auch bei Destination auf, ist das richtig

    In meinem Beispiel kann keine der Aussenstellen zu einer anderen Aussenstelle kommunizieren. Alle Aussenstellen dafür aber ins Hauptnetz und genau so andersherum.

    Die gleiche Gruppe für Source und Destination ist eigentlich widersprüchlich aber der interne Datenverkehr der Aussenstelle passiert ja nicht die LAN out Schnittstelle der "Zentrale" daher egal.

    Wenn Du Ping Tests machst, bitte immer ein Gerät anpingen welches im Zielnetz ist. Nicht die IP des Routers im Zielnetz anpingen ... da greifen die LAN/IN und LAN/OUT Regeln nicht


    Wenn Du den Zugriff von den Nebenstellen zur Hauptstelle nicht möchtest, dann musst Du jetzt noch die States der IP Pakete mit einbauen. Wenn ich mich nicht irre, hast Du in der Zentrale LAN/OUT jetzt keine Eingrenzung getroffen. Versuch da mal bitte Neu zu verbieten. Dann lässt Du keine Pakete mehr raus die eine neue Verbindung aufbauen. Erlaubt sein muss Related und Establisht. Das sind Pakete die zu einer bestehenden Verbindung gehören oder mit einer in Verbindung stehen. Das wären also die Antworten aus den Filialen auf die Anfragen aus der Zentrale.