Kleine "private" Cloud mit pfSense als Firewall
-
@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. -
@exuded
dann spar dir den Quatsch mit den Subnetzen und setze die Regeln in der Windows Firewall des jeweiligen Windows Clients. So das die Windows Clients untereinander nicht kommunizieren können.Im OpenVPN Server musst du halt nur sicherstellen, dass die VPN User immer wieder die gleiche IP aus dem OpenVPN Netz bekommen. In den pfSense Rules auf dem OpenVPN Interface gewährst du dann beispielsweise:
OpenVPN User 1 (192.168.10.10) Zugriff über Port 443 (Beispiel Port) zu Windows Client 1 (10.38.10.2) -
@m0nji
Das war nun auch der Plan.
Allerdings bekomme ich es in dem Hetzner Setup nicht hin, dass ein User via OpenVPN auf die Sense einhält und dann bspw. per RDP auf den anderen Windows Client hinter der Sense im Hetzner Netzwerk... Das OpenVPN Tunnel Netzwerk ist als 10.0.0.0/24 und das lokale Netz im VPN Server ist eingerichtet als 192.168.1.0/24. Ist hier vllt der Fehler? Muss das Netz übereinstimmen mit dem 10.38.10.0/24 Netz?
Ich kann, wenn per VPN verbunden als Nutzer nichts pingen, außer der 10.0.0.1.EDIT: Lösung lag in den Einstellungen des OpenVPN Servers. Für den LAN Access benötigte es unter "Advanced Configuration" des OpenVPN Servers den Eintrag "push "route 10.38.10.0 255.255.255.0"
Danach war die RDP Verbindung zum Windows Client unter 10.38.10.2 dann direkt möglich :) -
Hallo nochmal :) @m0nji @NOCling
Kann mir jemand erklären, weshalb der PC hinter der pfSense via VPN nun zwar über Remote Desktop erreichbar ist, jedoch ein Ping von einem User PC im VPN an den Windows Pc mit "request timeout" fehlschlägt?
Edit: hat sich erledigt. Es fehlte nur die korrekte windows 10 Firewall Einstellung. -
@JeGr @m0nji @exuded
Ahoi,
ich knüpfe hier noch einmal an die Thematik bei Hetzner mit dem /32 Netz pro Host an.
Ich habe eine pfSense. Ausgehender Traffic Richtung WAN und Traffic untereinander läuft auch über die Maschinen im privaten Netz.
Ich habe jedoch auch einen IPsec Tunnel zwischen pfSense und einer Sophos.
Traffic von den Hetzner Hostsin den Tunnel zur Sophos und alles dahinter ist kein Problem. Traffic von der Sophos bzw. den Maschinen hinter der Sophos in Richtung der Hetzner pfSense und den Hosts hinter der pfSense geht jedoch nicht durch.
Ich denke das Problem ist, dass ich ja kein /24 Netz habe in das ich den gesamten Traffic für die Hosts schicken kann. Die pfSense müsste wohl den Traffic der aus dem Tunnel kommt auch zum Hetzner GW 10.0.0.1 leiten. Da scheitert der ganze Spaß aber wohl aktuell.
Hat jemand ein solches Setup mal aufgebaut bzw. hat einen Tipp zu den nötigen Rules?Besten Dank euch
Grüße
mnt -
@mnt mehrere Fragen:
- Siehst du auf der pfSense den ankommenden Traffic via Diagnostics--> States oder via Firewall Logs?
- Hast du in den ipsec Rules auf der pfSense als Destination das Subnet manuell angegeben oder "LAN Net" ausgewählt? "LAN Net" funktioniert nicht.
- Hast du die Rück-Routen auf den Clients hinter der pfSense bedacht? Diese müssen manuell gesetzt werden solange du noch die Public IPs auf den Clients hinter der pfSense aktiv hast.
-
@exuded said in Kleine "private" Cloud mit pfSense als Firewall:
EDIT: Lösung lag in den Einstellungen des OpenVPN Servers. Für den LAN Access benötigte es unter "Advanced Configuration" des OpenVPN Servers den Eintrag "push "route 10.38.10.0 255.255.255.0"
Das braucht man nicht als Adv. Option. Ein oder mehrere Netze können problemlos bei "LAN networks" angegeben werden und werden auch gepusht. Das als extra Option zu setzen ist Quatsch :)
@mnt said in Kleine "private" Cloud mit pfSense als Firewall:
Traffic von den Hetzner Hostsin den Tunnel zur Sophos und alles dahinter ist kein Problem. Traffic von der Sophos bzw. den Maschinen hinter der Sophos in Richtung der Hetzner pfSense und den Hosts hinter der pfSense geht jedoch nicht durch.
Weil den Kisten die Route zu dem Netz der Sophos fehlt?
@mnt said in Kleine "private" Cloud mit pfSense als Firewall:
ich knüpfe hier noch einmal an die Thematik bei Hetzner mit dem /32 Netz pro Host an.
/32 ist doch quatsch. Bei Hetzner ein LAN zu definieren mit /32? Was soll damit erreicht werden, mit /32 ist ja nur EIN Host adressiert, nicht mehrere, kein Routing etc. Wie soll das konfiguriert sein?
-
Das private Hetzner Netz lautet 10.0.0.0/24, das Netz hinter der Sophos ist 192.168.0.0/24
Traffic von den Hosts im 10.0.0.0/24 läuft ohne Probleme in Richtung 192.168.0.0/24 Netz. Ping geht durch.
@m0nji Diese Richtung sehe ich dann auch in Diagnostics --> States.
Traffic von 192.168.0.0/24 (Sophos) nach 10.0.0.0/24 (pfSense) geht nicht durch.In den P2 Settings und Firewall Rules habe ich das Netz manuell mit 10.0.0.0/24 angegeben. Das "LAN Net" wäre ja nur 10.0.0.0/32 - soweit klar.
Die Clients hinter der pfSense haben keine Public IP. Die haben nur das private Netz und bekommen vom Hetzner DHCP beispielsweise 10.0.0.3/32 zugewiesen mit dem Hetzner Default Gateway 10.0.0.1. Von da läuft der Traffic auch problemlos Richtung Sophos:
Routenverfolgung zu .... [192.168.0.12] über maximal 30 Hops: 1 3 ms 2 ms 3 ms 10.0.0.1 2 1 ms <1 ms <1 ms 10.0.0.2 3 * * * Zeitüberschreitung der Anforderung. 4 15 ms 16 ms 15 ms ..... [192.168.0.12]@JeGr Das definierte Hetzner Netz ist ein /24. Die Cloud Server bekommen als Subnetzmaske vom Hetzner DHCP 255.255.255.255 also /32. Das kann ich ja nicht beeinflussen soweit ich weiß.
-
@mnt
Leider immer noch nicht ganz eindeutig.
Folgendes bitte prüfen:Hetzner Cloud Console:
Hetzner empfiehlt ein 16er Netz anzulegen und darin dann deine 24er Subnetze. Ob das wirklich eine Auswirkung hat, weiß ich bis heute auch nicht aber es ist die Empfehlung!
Meine Server sind im Subnetz 10.38.10.0/24
Die Hetzner pfSense hat die 10.38.10.1
Hetzner pfSense:
Wichtig bei dieser Regel, nicht LAN Net auszuwählen, da LAN Net eben nur eine 32er Maske hat. Damit ist erstmal pauschal gewährleistet, dass deine Server bei Hetzner überall hin kommen.
Die Phase2 hattest du ja augescheinlich korrekt angelegt.Sofern du keine Public IPs auf den Clients hinter der Hetzner pfSense hast, sollten dort auch keine weiteren Routen notwendig sein.
Auf Sophos Seite muss dann natürlich noch eine Firewall Regel vom IPsec Interface zu deinen Clients/Server hinter der Sophos
-
@m0nji Man muss bei dem ganzen Hetzner private Network Zeug dran denken, dass ALLES was von den Hosts/VMs kommt ERST zu Hetzners internem Gateway läuft und DANN ggf. zur pfSense. Deshalb auch der Routing-Tab. Deshalb bei einem /24er auch die /32er Maske bei den Hosts, damit diese nicht von Host zu Host selbst versuchen zu sprechen, sondern IMMER an Hetzners GW geroutet und von dort verteilt wird.
Das ist notwendig, da Hetzner die VM in jedem Standort erlaubt. Und wenn du ne VM in Finnland und eine in Deutschland hast und die beiden 10.20.30.11 und .12 hätte und ein /24er Netz konfigurieren würden, dann würden die beiden versuchen mit sich gegenseitig zu sprechen - was nicht geht weil nicht lokal.
Daher pusht Hetzner sein eigenes GW und die /32er Maske bei /16. Darum sollte man auch nichts auf .1 konfigurieren, da da eigentlich immer das Hetzner eigene GW sitzt.
Am Einfachsten hat das bei uns OOTB funktioniert wenn wir ein Netz definiert haben, dort die VMs einfach per Zuweisung im Interface mappen (auf ihre IPs) und die Hosts selbst auf DHCP schalten. Dann pusht Hetzner selbst die korrekten Settings über das Netzwerk Gateway das für die privaten Netze zuständig ist und alle Kisten können sich sehen. Nur auf der Sense muss man dann natürlich aufpassen, dass man nicht versehentlich die falschen Masken nutzt und daher das Routing falsch läuft. Korrekte statische Routen etc. sind da wichtig. :)
Cheers
