Pfsense - Subnet ganze IP´s routen
-
Hallo
erstmal vielen dank für deinen Post - zu den Punkten:
1: Du gibst diese VM in ein eigenes virtuelles Netz mit eigenem Interface auf der pfSense und brückst dieses mit dem WAN. So kannst du der internen VM direkt die öffentliche IP geben. Der Traffic lässt sich dennoch auf der pfSense filtern.
Du verwendest NAT 1:1. So werden sämtliche Anfragen an die externe IP an die spezielle interne weitergeleitet und Verbindung dieser VM nach außen bekommen die externe IP.Mir geht es halt darum dass ich (egal welche der beiden Varianten ich wähle) - dass ich per Default alles per Firewall eingehend sperren kann und dann einzelne Ports/Dienste dann wieder frei gebe.
Zum 1. genannten - mache ich dann je IP ein eigenes Internes Netz ?
Dann kommen wir gleich zu der V-Switch Thematik - hier gebe ich dir recht - ich habe die volle Kontrolle über V-Switches - das heisst am sichersten wäre es jedem Client einen eigenen V-Switch zuzuweisen - entsprechend mit einem eigenen Interface für.
Welche der beiden Varianten würdest du bevorzugen ? (die VM´s müssen untereinander nicht kommunizieren - internes Netz)
-
Hi,
mein vorschreibt hat recht. Um das zu erreichen, musst du für jeden VM einen eigenen vswtich oder switch erstellen. Dort verbindest du die Netzwerkkarte der VM und eine weitere Netzwerkkarte der pfSense mit.
Mit VLANs wäre dies auch möglich mit einem Switch. Das funktioniert aber mit einem vSwtich (vmware) so da hier vlans als Port-Gruppen abgebildet werden. Ist eine VM mit der Portgruppe verbunden so hat die das Netzwerk (vlan - untagged). Du kannnst aber nicht dern Port der pfSense an den Switch konnektieren und er sieht mehrere VLANs. Dann bist du auch hier wieder bei einem Interface pro VLAN und dann kann man gleich auf die VLANs verzichten und mit eigenen switchen arbeiten.
Was das 1:1 NAT angeht so kannst du so direkt eine externe IP einer INTERNEN IP zuordnen. Die VM bekommt also nicht direkt die externe IP zugewiesen. Wenn du sowas machen willst musst du das mit einer Bridge auf pfSense lösen. Hier handelst du dir aber neue Komplikationen ein. Ich würde auch mit dem 1:1 NAT arbeiten falls du zuviele Portweiterleitungen hast.
Bitte auch darauf das wenn du kein 1:1 NAT machst du Portweiterltungen einrichten musst + OUTBOUNT NAT rules. In der du festlegst das die interne IP auf folgende externe IP genattet wird. Dann geht jede VM mit einer festgelegten IP raus ins Internet. Tust du das nicht wird immer die IP des WAN Interfaces benutzt.
-
- Server im RZ mit Virtualisierung (Hyper-V oder VMWARE)
VM´s untereinandere zu isolieren - also dass ein etwaiger Angreifer der VM1 "erfolgreich infiltriert hat" nicht über das Netzwerk auf VM2 VM3 usw kommt)
Braucht ein Angreifer gar nicht mehr. Dafür gibt's ja Spectre und Meltdown, neuerdings auch Spectre-NG (mit 8 zusätzlichen Angriffsvektoren)…
https://heise.de/-4039134
https://heise.de/-4039302 -
Hi,
Hallo
erstmal vielen dank für deinen Post - zu den Punkten:
1: Du gibst diese VM in ein eigenes virtuelles Netz mit eigenem Interface auf der pfSense und brückst dieses mit dem WAN. So kannst du der internen VM direkt die öffentliche IP geben. Der Traffic lässt sich dennoch auf der pfSense filtern.
Du verwendest NAT 1:1. So werden sämtliche Anfragen an die externe IP an die spezielle interne weitergeleitet und Verbindung dieser VM nach außen bekommen die externe IP.Mir geht es halt darum dass ich (egal welche der beiden Varianten ich wähle) - dass ich per Default alles per Firewall eingehend sperren kann und dann einzelne Ports/Dienste dann wieder frei gebe.
Zum 1. genannten - mache ich dann je IP ein eigenes Internes Netz ?
Dann kommen wir gleich zu der V-Switch Thematik - hier gebe ich dir recht - ich habe die volle Kontrolle über V-Switches - das heisst am sichersten wäre es jedem Client einen eigenen V-Switch zuzuweisen - entsprechend mit einem eigenen Interface für.
Welche der beiden Varianten würdest du bevorzugen ? (die VM´s müssen untereinander nicht kommunizieren - internes Netz)
Ich würde dir empfehlen pro VM einen eigenen v-switch mit einer portgroup. Dann eine Netzwerkkarte der pfsense und der vm mit der portgroup verbinden.
Dann machst du ein 1:1 NAT. (Ja jede VM bekommt dann ein eigenes internes Netz. Hier kannst du aber z.B. ein /30 Netz nehmen. aka 192.168.2.1/30) oder fall es mal mehr als eine VM werden wird vielleicht lieber gleich ein /28 Netz.Bei 1:1 NAT kannst du immer noch auf dem WAN Interface für jede externe IP filtern. Kommt der Traffic dort nicht rein, wird er auch nicht per NAT weitergeleitet.
-
Hi,
mag man nicht außer acht lassen, aber mit das ist hier nicht die Frage. Und es einem Eindring so schwer wie möglich zu machen oder einfach unterschiedliche Mandanten voneinander zu separieren sollte man immer tun!.
@jahonix:- Server im RZ mit Virtualisierung (Hyper-V oder VMWARE)
VM´s untereinandere zu isolieren - also dass ein etwaiger Angreifer der VM1 "erfolgreich infiltriert hat" nicht über das Netzwerk auf VM2 VM3 usw kommt)
Braucht ein Angreifer gar nicht mehr. Dafür gibt's ja Spectre und Meltdown, neuerdings auch Spectre-NG (mit 8 zusätzlichen Angriffsvektoren)…
https://heise.de/-4039134
https://heise.de/-4039302Ansonsten ein trolling mit Links. ;)
-
Mir geht es halt darum dass ich (egal welche der beiden Varianten ich wähle) - dass ich per Default alles per Firewall eingehend sperren kann und dann einzelne Ports/Dienste dann wieder frei gebe.
Das funktioniert mit beiden Varianten.
Die Bridging würde ich aber nur einsetzen, wenn die virtuelle Maschine bzw. die darauf laufenden Diensten unbedingt die externe IP benötigen. Doch die allermeisten Services klappen mit NAT ebenso gut.Zum 1. genannten - mache ich dann je IP ein eigenes Internes Netz ?
Ja.
Dann kommen wir gleich zu der V-Switch Thematik - hier gebe ich dir recht - ich habe die volle Kontrolle über V-Switches - das heisst am sichersten wäre es jedem Client einen eigenen V-Switch zuzuweisen - entsprechend mit einem eigenen Interface für.
Welche der beiden Varianten würdest du bevorzugen ? (die VM´s müssen untereinander nicht kommunizieren - internes Netz)
Ein eigenes Netz je VM.
Die VLAN-Variante wäre nur für den Fall interessant, wenn die den Host nicht kontrollieren könntest. -
Ansonsten ein trolling mit Links. ;)
Trolling ist IMHO was anderes. Zumal Chris Dead-On recht hat: das ist genau zu 100% ein Anwendungsfall, wo einem Spectre und Meltdown in welcher Variante auch immer den Hals ordentlich brechen können. Auf einer Einzel-Appliance mit einer Software drauf (bspw. pfSense) auf die nur die Admins Zugriff haben? Low Risk. Aber hier auf dem Hypervisor oder auf einem Cloud Host ist genau das Angriffsszenario, was den maximalen Schaden bringt. Da muss man nur 2 Kunden haben die sich innbrünstig hassen und dann kommt raus, dass die beim gleichen Hoster sind und sogar auf der gleichen Hardware laufen… autsch.
Davon abgesehen:
Ja ein Isolieren (wenn wir annehmen, dass die HV/HW Schicht bis zur VM "sicher" ist) der VMs ist am besten in eigenen (V)LANs. Ob man das alles auf mehrere vSwitche packt oder VLANs bastelt und die als Trunk zur pfSense VM bringt bleibt sich da gleich. Ich bin ja Freund davon, sowas ordentlich quasi inline zu dokumentieren und würde daher für die VMs einzelne /24 Netze im 10er Bereich intern nehmen und die VLAN ID an Hand der Netze vergeben. So im Stil: 10.5.1.0/24, VLAN ID: 501, Sense IP: 10.5.1.1 ; 10.5.2.0/24, VLAN ID: 502 ; 10.9.11.0/24, VLAN ID: 911 -> damit kann man an zweiter Stelle auch wunderbar zwischen bspw. produktiven Sachen (bspw. 5) und test/int/infra/mgmt (bspw. 9) unterscheiden. Und man hat den Luxus, sollte ein Projekt mehrere VMs umspannen - die vielleicht nicht direkt von außen erreichbar sein sollen (wie DBs bspw.) - man die im gleichen Subnetz parken kann.
Gruß
-
Hallo Zusammen
erstmal sehr cool dass ihr euch die Zeit genommen habt auf meine Frage einzugehen.
Ich Tendiere zu Vswitches
Würde mich dann nochmals melden sobald ich eine TEST Umgebung aufgesetzt habe wie das in Pfsense zu machen ist.
Bezüglich der Spectre/Meltdown Thematik - ja - ist mir bekannt - ich habe jetzt mal soweit die von MS bereitgestellten Patches eingespielt und aktiviert zudem ist das Bios und damit der Microcode zumindest für die V1 auf allen Maschinen online.
Was nun NG anbetrifft so gibt es m.E. hier noch nix tja … -
Moin,
Das Thema meldown und specture muss vor allem auch auf den esxi Hosts gepatcht werden. Da gibt es auch ein paar update von VMware für CPU microcode. Sollte man einspielen.
Was das Thema angeht mit den IP Kreisen so bin ich auch für selbst dokumentatieren. Andererseits gibt es auch das Thema vlan hopping. Da du dir den Luxus von einem eigenen vswitch pro Kunde mit einer porrgroup (was ja ein vlan darstellt) leisten kannst, würde ich hier für jeden Kunden das machen. Sollte später der Kunde mehr vlan wollen kann er sie ja haben. Solange du die ganzen Switche nicht an das physikalische Netz im RZ anschließen musst ist das ja kein Thema.
Gruß blex
-
Hallo
erstmal nochmals danke für die Unterstützung.
In diesem Zusammenhang möchte ich nun ein konkretes Beispiel probieren:
Ausgangssituation:
3 zusätzliche Öffentliche IP´s - als Alias Registriert
3 VM´s im gleichen Subnet (192.168.3.x) - die VM´s sind nicht isoliert sondern hängen am gleichen V-Switch
PFsense hängt ebenfalls mit LAN an diesem V-SwitchZiel routing:
Je eine der öffentlichen IP´s soll an eine VM im internen Netz von außen nach innen geroutet werden
Jede VM soll nur über seine Externe IP nach "außen" gehen.Ziel Firewall:
Grundsätzlich alles Blocken eingehend
Grundsätzlich alles "auf" ausgehend
Freigabe einzelner Ports je nach externer IPWenn ich eure Posts vorher richtig interpretiert habe ist hier 1:1 die richtige Wahl ?!?
Evtl könnte mir hier jemand Starthilfe geben.
-
Hallo,
Ziel routing:
Je eine der öffentlichen IP´s soll an eine VM im internen Netz von außen nach innen geroutet werdensinnlos, wenn…
@gtrdriver:Ziel Firewall:
Grundsätzlich alles Blocken eingehendAber, das hast du vielleicht nicht ganz so eng gemeint. :)
Wenn ich eure Posts vorher richtig interpretiert habe ist hier 1:1 die richtige Wahl ?!?
Das 1:1 NAT erspart dir einige Konfigurationsschritte, wenn der Verkehr in beide Richtungen gehen soll.
Wenn du, wie geschrieben, nur ausgehenden Traffic erlaubst, kannst du für jede VM auch eine Regel in NAT > Outbound einrichten, die die interne IP in ausgehenden Paketen durch die externe IP ersetzt. 1:1 geht eben gleich für beide Richtungen, womit aber noch kein Traffic erlaubt ist. Das muss gesondert in Firewall-Regeln gemacht werden.Vielleicht die bessere Antwort: Ja, dein Vorhaben ist mit 1:1 machbar.
Einfach für jede externe IP eine Regel am WAN Interface erstellen und bei internal IP "single host" und die interne IP eintragen und als Maske /32 setzen.Über kleinere Maske lässt sich 1:1 auch gleich für ein ganzes Subnetz einrichten. Dafür müssen allerdings externe und interne IPs in durchgehender Reihenfolge vorliegen.
-
Du kannnst aber nicht dern Port der pfSense an den Switch konnektieren und er sieht mehrere VLANs. Dann bist du auch hier wieder bei einem Interface pro VLAN und dann kann man gleich auf die VLANs verzichten und mit eigenen switchen arbeiten.
Kleiner Hinweis hierzu:
Eine Protgruppe mit VLAN 4095 ist vergleichbar mit einem Trunk Port.
Ich habe so eine pfSense VM laufen, die das Routing zwischen mehreren VLANs mit nur einem Interface übernimmt.
KB Artikel: https://kb.vmware.com/s/article/1004252 -
Hallo
erstmal danke für eure Tips - hat alles geklappt !
