Kleine "private" Cloud mit pfSense als Firewall
-
@jegr sehr interessant. Danke für den Gedankenanstoss zu einem neuen Bastelprojekt! Werde ich am Wochenende gleich mal vertiefen und meine pfSense zu Hause per ipsec anbinden. Das durchrouten der externen IP finde ich sehr spannend.
Für mich ist noch nicht ganz klar wie das Routing des LAN Interfaces funktioniert. Standardmäßig wird ja auf dem LAN Interface eine Regel angelegt, die alles aus dem "LAN Net" to "Any" über jedes Protokoll erlaubt. Allerdings kann ich nicht von der 2. Hetzner Maschine die pfSense anpingen. Erst wenn ich eine zusätzliche Firewall Regel anlege und als source das Hetzner LAN netz angebe und als ziel die LAN address nehme, funktioniert auch ein ping.
Von der pfSense zum 2. Hetzner Server, kann ich ohne Probleme pingen, auch ohne diese Zusatz Regel. Es scheint als wenn "LAN NET" nicht das ist, wofür ich es halte ;)
Hast du auch ipv6 eingerichtet auf der pfSense? Zumindest holt er sich via dhcp6 auf dem WAN Interface keine Adresse. Das liegt aber wohl daran, dass dem Hetzner Server ja nur ein 64er Präfix zugewiesen wird und die pfSense wahrscheinlich versucht ebenfalls ein 64er Präfix abzurufen.
-
Ich versuche mir mal die Antwort bzgl. Firewall Rule selber zu geben.
Durch das DHCP auf dem LAN Interface ist ja das Netz 10.38.10.2/32 und nicht /24. Demzufolge ist wohl "LAN net" ebenfalls nur /32, was erklären würde warum der zweite Hetzner Server mit der 10.38.10.3 die 10.38.10.2 nicht anpingen kann. Liege ich mit der Vermutung richtig @JeGr ?
Was mir aber noch nicht ganz schlüssig ist: Wenn ich die public IP vom zweiten Server wegnehmen würde, hätte dieser ja nur noch die 10.38.10.3 und als Gateway die 10.38.10.1 (Hetzner Gateway). Müsste ich da dem zweiten Hetzner Server nicht manuell den Gateway pfsense (10.38.10.2) eintragen? Dieses Konstrukt ist mir noch nicht ganz klar. -
@m0nji said in Kleine "private" Cloud mit pfSense als Firewall:
Ich versuche mir mal die Antwort bzgl. Firewall Rule selber zu geben.
Durch das DHCP auf dem LAN Interface ist ja das Netz 10.38.10.2/32 und nicht /24. Demzufolge ist wohl "LAN net" ebenfalls nur /32, was erklären würde warum der zweite Hetzner Server mit der 10.38.10.3 die 10.38.10.2 nicht anpingen kann. Liege ich mit der Vermutung richtig @JeGr ?Jup. Das "Netz" ist nur die einzelne IP wegen Routing durch die .1 damit die unterschiedlichen Standorte machbar sind.
Was mir aber noch nicht ganz schlüssig ist: Wenn ich die public IP vom zweiten Server wegnehmen würde, hätte dieser ja nur noch die 10.38.10.3 und als Gateway die 10.38.10.1 (Hetzner Gateway). Müsste ich da dem zweiten Hetzner Server nicht manuell den Gateway pfsense (10.38.10.2) eintragen? Dieses Konstrukt ist mir noch nicht ganz klar.
Inwiefern was eintragen? Soferns nicht schon gemacht ist/wurde, muss das interne Netz (10.38.10.2) natürlich auf das LAN GW (.1) eingetragen/geroutet werden. Das ist klar. Sonst kommen die Pakete ja nicht beim anderen Server an ohne übers GW zu gehen. :)
-
@jegr ich teste heute oder morgen Abend noch etwas und geb dann noch mal Feedback. Das Routing innerhalb des privaten Netzes klappt schon, dass ist nicht das Problem. Muss aber erstmal noch eine weitere virtuelle Server Instanz erstellen weil die jetzige zweite produktiv ist und er will ich nicht einfach die Public IP entziehen. Wie hast du diese überhaupt entzogen. Über die Cloud Console ist das ja scheinbar nicht möglich. Hast du einfach den Adapter auf der virtuellen Maschine deaktiviert?
-
Ok meine Tests waren soweit erfolgreich. Hatte jetzt zum Test noch eine zweite virtuelle Maschine installiert und habe auch noch mal das private Netz neu erstellt. Laut zweier Anleitungen sollte man das Netz gleich größer spannen /16 oder /8 und dann ein Subnetz erstellen mit den virtuellen Servern. Warum....hm das weiß wohl nur hetzner, denn in FAQ steht auch: "Im Moment ist die Funktion Subnets nicht sehr nützlich. Dies wird sich jedoch in Zukunft ändern, wenn wir weitere Funktionen hinzufügen." ;)
Anyways mein Ziel war es, den neuen virtuellen Server über die virtuelle pfSense ins Internet gehen zu lassen.- Netzwerk 10.38.0.0/16 angelegt und Subnet 10.38.10.0/24
- virtuelle pfSense und Test Maschine in das 10.38.10.0/24 Netz gepackt
- Route in Cloud Console erstellt 0.0.0.0/0 via 10.38.10.1 (pfSense)
- dhcp für die Public IP auf der virtuellen Test Maschine deaktiviert und default route hinzugefügt via 10.38.0.1 (Hetzner Gateway für das virtuelle Netzwerk)
- /etc/resolv.conf angepasst "nameserver=10.38.10.1"
- in pfSense Outbound NAT angelegt, DNS Resolver Access für das 10.38.10.0 Netz und Standard LAN to ANY Firewall Rule geändet von LAN Net auf Network 10.38.10.0, da LAN Net in diesem Fall nur bedeutet 10.38.10.1/32
Als nächstes würde ich dann mal einen VPN Tunnel zwischen der virtuellen pfSense und meiner pfSense daheim probieren. Da werde ich aber wohl noch 2 Wochen warten und es dann gleich mit wireguard testen.
Alles in allem ein klein wenig anderer Use Case als den du beschrieben hast Jens aber ich fand das Thema durchaus spannend und es ergeben sich dadurch gleich ein paar neue Anwendungsfälle :D
-
@m0nji Ist doch schön wenn es auch für was anderes gut ist :)
-
Hallo @m0nji, hallo @JeGr
ich verfolge gerade euren Ansatz für eine private cloud auf den Hetzner Cloud Servern mit pfsense.
Ich komme allerdings nicht weiter und wollte fragen, ob Ihr mir da ggf. in irgendeiner Form helfen könntet. Ich habe es nach den Schritten wie von euch beschrieben konfiguriert. Allerdings kommt der Client PC (Windows 10) nicht ins pfSense Netzwerk. Und in pfsense unter DHCP Releases wird dieser auch nicht angezeigt.
Der Windows Client erhält trotz Änderung des Standardgateways auf 10.38.0.1 (Hetzner Gateway für das vNetzwerk) und DNS Server 10.38.10.1 nach wie vor seine Public Hetzner IPv4 Adresse. Wenn ich DHCP auf dem Win 10 Client ausschalte und manuell in der Range 10.38.10.5 bspw vergebe, dann gibt es ebenfalls keinen Ping zwischen pfSense und Client.
Das Ziel ist es, dass am Ende mehrere Clients nur noch über die pfSense ins Internet kommen und über die pfSense dann der Zugang via VPN Konfigurationen und Firewall Rules bereitgestellt wird.Hier nochmal zur Übersicht mein bisheriger Aufbau
-
2 Hetzner Cloud Instanzen, davon 1 pfSense fertig eingerichtet für Zugriff von außen durch ge-whitelistete IP und 1 Windows 10 Instanz,
-
Netzwerk in Hetzner Cloud wie folgt (nach Vorlage von @m0nji)
10.38.0.0/16 Netz mit 10.38.0.0/24 Subnetz worin die beiden Instanzen pfSense (10.38.0.2) und Windows 10 (10.38.0.3) eingebunden sind, -
Route in Cloud Console erstellt 0.0.0.0/0 via 10.38.10.2 (pfSense)
-
DCHP für die Public IP auf dem Win10 Client ist noch aktiviert.
Das default gateway ist eingerichtet via 10.38.0.1 (Hetzner Gateway für das virtuelle Netzwerk), der DNS Server ist eingestellt als 10.38.10.1 (pfSense), -
in pfSense Outbound NAT angelegt, wie folgt:
-
DNS Resolver Access für das 10.38.10.0 Netz wie folgt:
-
Standard LAN to ANY Firewall Rule geändet von LAN Net auf Network 10.38.10.0, wie folgt:
Hätte jemand einen Ansatz der mir helfen würde?
-
-
@exuded
Naja ganz meine Vorlage hast du nicht genutzt ;)Ich versteh anhand deiner Beschreibung nicht ganz, warum deine pfsense Instanz 10.38.0.2, 10.38.10.1 und 10.38.10.2 hat?! Sie bekommt nur eine Adresse aus dem 10.38.10er Netz. Nicht zwei oder gar drei.
Du verbindest in der Cloud Console beide Instanzen mit dem 10er Netz, nicht mit dem 0er.
Die pfSense bekommt dadurch zusätzlich zur WAN IP auch noch eine LAN IP aus dem 10.38.10er Netz, dessen Gateway ebenfalls per DHCP gesetzt wird und die 10.38.0.1 (Hetzner Network Gateway) ist.Sieht in der pfSense dann so aus:
Dadurch, dass deine Instanzen immer auch eine Hetzner Public IP bekommen, musst du natürlich die default Route auf dem Client umbiegen und das Public IP Interface abschalten. So hatte ich das auch weiter oben geschrieben.
Outbound NAT ist i.O.
LAN to ANY Rule ist aber nicht korrekt. Du willst damit den LAN Clients (10.38.10.1-254) ermöglichen ins Internet zu kommen.
Daher muss die Rule lauten Source: 10.38.10.0/24 --> Destination: any. Warum nicht "LAN Net" verwenden anstatt des Subnets anzugeben, habe ich oben geschrieben: "Standard LAN to ANY Firewall Rule geändert von LAN Net auf Network 10.38.10.0, da LAN Net in diesem Fall nur bedeutet 10.38.10.1/32"@JeGr wie kann man eigentlich die Images verkleinern, so dass man drauf klickt und die Originalgröße erst dann sieht?! ;) Ich dächte das ging mal.
-
@m0nji Danke für deine ausführliche Erläuterung!
Ich habe meine Konfiguration entsprechend berichtigt.
Was ich jedoch noch nicht so ganz verstehe:
Wenn nun auch das LAN Interface in der pfSense auf DHCP läuft, wie kann ich dann Regeln für die Clients definieren? Im Heimnetz würde man ja eigentlich die Clients an die LAN Schnittstelle bringen, dort dann entsprechend von der Sense den DHCP Server laufen lassen und den Clients über das LAN Interface die Firewall Regeln vorschreiben. Nun ist das mit dem DHCP Server der Sense in der Hetzner Umgebung natürlich nicht gegeben, aufgrund der Hetzner Netzwerk-Struktur der Cloud Instanzen.Wenn ich nun jedoch dem Windows Client wie folgt das Gateway und den DNS Server vorgebe, dann kann dieser noch immer weder direkte IP Adressen noch domains singen bzw. erst garnicht auflösen.
EDIT: Ich habe das Problem gefunden. Ich vermutete ein Problem beim NAT Mapping und dem war auch so. Das Mapping war ausgegraut mit einem X davor. Als ich dann die Regel anwählte und nochmal auf "Hybrid Outbound NAT rule generation." stellte, ging es nach einem Klick auf save :) D.h. der Client ist nun online mit deaktiviertem public IP Interface unter dem Gateway 10.38.0.1
Nur bleibt die Frage nach der Regeldefinition in der pfSense. Bleibt es dann bei der "bekannten Logik", dass ich Firewall Regeln für das LAN Interface definiere, welche dann für alle Clients in dem Subnetz 10.38.10.0/24 gelten? :) -
wenn DNS nicht funktioniert, hast du vielleicht die Access List Einstellungen vergessen?!
Funktioniert eine Auflösung direkt über die pfSense unter Diagnostic --> DNS Lookup? -
@exuded said in Kleine "private" Cloud mit pfSense als Firewall:
Nur bleibt die Frage nach der Regeldefinition in der pfSense. Bleibt es dann bei der "bekannten Logik", dass ich Firewall Regeln für das LAN Interface definiere, welche dann für alle Clients in dem Subnetz 10.38.10.0/24 gelten? :)
Was möchtest du denn noch machen? Sobald die Clients das richtige Gateway nutzen, bleibt es natürlich dabei, dass die pfSense für die Regeln zuständig ist.
-
@m0nji
Der Anwendungsfall wäre:
Mehrere Clients hinter dem pfSense Gateway sollen mit verschiedenen OpenVPN Zugängen erreichbar gemacht werden. Jedoch nur auf bestimmten Ports. Zugleich soll der Nutzer mit einem OpenVPN Zugang für Client 1, nicht den Client 2 sehen können. -
Ja du kannst dann per Remote via OpenVPN zur pfsense connecten und über das OpenVPN Interface dann die Regeln setzen um in das LAN Netz zu springen (deine Clients). Ich mache das aktuell zwar nicht via OpenVPN sondern mit IPsec aber regeltechnisch das gleiche.
-
@m0nji Danke für den Hinweis :)
Gibt es dann in der Regelsetzung des OpenVPN Interfaces auch die Möglichkeit "OpenVPN Nutzer 1" nur auf Client 1 zuzulassen sowie "OpenVPN Nutzer 2" nur auf Client 2? Ein Sprung ins komplette LAN Netz wäre dann m.E. nicht so gut -
Kann Hetzner denn den Zugriff der Server untereinander blocken?
Denn sonst bringt die das nicht so viel.Dann verbindet sich halt Server A mit Server B direkt und richtet Unheil an.
-
Das stimmt. Sowas wäre natürlich unschön.
Ohne bei Hetzner nachgefragt zu haben gehe ich mal davon aus, dass Hetners Lösung dafür in den verschiedenen Subnetze besteht.
Nur kann ich in der pfSense weitere LAN Interfaces anlegen, sodass je Subnetz ein LAN Interface in der pfSense besteht? -
@exuded said in Kleine "private" Cloud mit pfSense als Firewall:
@m0nji Danke für den Hinweis :)
Gibt es dann in der Regelsetzung des OpenVPN Interfaces auch die Möglichkeit "OpenVPN Nutzer 1" nur auf Client 1 zuzulassen sowie "OpenVPN Nutzer 2" nur auf Client 2? Ein Sprung ins komplette LAN Netz wäre dann m.E. nicht so gutJein....so lange du bei OpenVPN ebenfalls auf DHCP setzt, wird das schwierig. Du müsstest sicherstellen, dass die Clients eben immer wieder die gleiche IP aus dem OpenVPN Netz bekommen. Ein kurzes googlen brachte das Ergebnis: https://wpcomputersolutions.com/pfsense-set-static-ip-specific-openvpn-client/
@nocling said in Kleine "private" Cloud mit pfSense als Firewall:
Kann Hetzner denn den Zugriff der Server untereinander blocken?
Denn sonst bringt die das nicht so viel.Dann verbindet sich halt Server A mit Server B direkt und richtet Unheil an.
Hetzner bietet zusätzlich eine Firewall an allerdings noch im Beta Status. Hier wird auch geschrieben, dass es noch nicht für die privaten Netze funktioniert: https://docs.hetzner.com/de/cloud/firewalls/faq/
Also ja, spätestens wenn du dich per RDP auf Client 1 verbunden hast, steht dir theoretisch der Weg zu Client 2 frei. Könnte man umgehen, wenn man die Subnetze kleiner macht und die Clients dann in unterschiedliche Subnetze packt.EDIT: man muss die Subnetze noch nicht mal kleiner machen. Man hat ja noch 253 weitere freie 24er Netz im 10.38.er Netz.
Wenn also Windows Client 1 im 10.38.20.0/24 ist und Windows Client 2 im 10.38.30.0/24 Netz ist, kannst du wiederum über die pfsense die Regeln setzen. Somit umgehst du auch gleich, dass du von den Windows Clients auch auf die pfSense kommst. 50 Clients möchte ich so aber nicht verwalten, da dies auch 50 zusätzliche Interfaces in der pfsense heißen würden. Aber das hat hier nichts mehr mit Hetzner zu tun. Innerhalb eines Subnetzes greift nie eine Firewall ein... -
@m0nji said in Kleine "private" Cloud mit pfSense als Firewall:
Könnte man umgehen, wenn man die Subnetze kleiner macht und die Clients dann in unterschiedliche Subnetze packt.
Wenn ich dann jeweils ein /32 Subnetz pro Client bei Hetzner anlegen würde, wie könnte ich dann jedes einzelne Subnetz als LAN Interface in die pfSense einbinden? Ich brauche maximal 4, wahrscheinlich aber nur 2 Clients bzw. 2 Subnetze mit jeweils 1 Client
-
@exuded
Noch mal zum Verständnis. Warum müssen die Windows Clients überhaupt voneinander isoliert werden? Der OpenVPN User hat doch sicher nur RDP Account für einen der 4 Server? -
@m0nji
Also eigentlich wird nichtmal der RDP Zugang benötigt, sondern nur der Zugang zu einem bestimmten Port um Daten via Python Script auf dem Rechner des Users herunterzuladen.
Der RDP Zugang natürlich nur für mich als Admin, aber das kann ich ja dann sicherstellen, indem ich den RDP Zugang nicht weitergebe.
