[ESXi] Nichts geht, bin verzweifelt ._.
-
Mal was anderes, wie hast du das WAN Interface konfiguriert ? IP adresse ist klar, aber Gateway Subnet und co. auch alles gesetzt ?
Woher hast du die Infos welches Gateway du nutzen sollst ?Gateway ist die IP meines Servers mit einer .1 im letzten Block. Im pfSense habe ich die IP-Adressen (Option 2) manuell dem WAN zugewiesen, mit 24er netmask.
Sowas muss ein DC/RZ vorgeben, ansonsten verursachst du unnötig Traffic bzw. belastest das Netzwerk unnötig.
Kannst du das Gateway pingen ?Ja, bin mittlerweile tatsächlich einen Schritt voran gekommen! :)
pfSense ist mittlerweile online und die erste Windows-VM auch. Die VM hat die LAN IP laut ipconfig aber nach außen hin die des IP-Netzes. =)Aber fragt mich ehrlich gesagt nicht, was ich dieses mal anders gemacht hab - hab nur alles wieder auf Standard zurückgesetzt, nachdem ich es letztens durch rumprobieren verhunzt hatte. >.
Komme noch nicht per RDP auf die WinVM aber es geht vorwärts!Darf ich noch eine Frage zu den Ports stellen?
Muss ich den RDP-Port separat im pfSense freigeben oder reicht es das durch das 1:1 mapping autom durch?
-
Muss ich den RDP-Port separat im pfSense freigeben oder reicht es das durch das 1:1 mapping autom durch?
Hi,
1:1 NAT reicht alle Ports durch, aber per Regel musst du den Traffic schon zusätzlich erlauben, sonst könnte man ja die Kiste gleich ins Web hängen. -
Genau wie viragomann das sagt: bei reinem Portmapping gibt die pfSense als letzten Punkt die Möglichkeit, eine verknüpfte Filterregel zu erstellen (gilt aber nur für Ports oder Portranges), bei 1:1 Zuweisung wird aber nur die IP umgeschrieben und sonst alles weitergeschickt (also quasi Ports 1:65535 weitergeleitet). Da NAT aber VOR den Filter Regeln greift, müssen deine Filterregeln definiert sein in dieser Art:
Quelle: IP, Alias oder any
Ziel: interne IP der WindowsVM (nicht externe, die im NAT Mapping vergeben wurde)Dann sollte das auch klappen. Tipp: Wenn du ein IP Alias definierst mit einer URL bzw. Hostnamen, dann wird dieser Alias zyklisch aufgelöst in eine IP und das Alias aktualisiert.
Sprich: Definierst du ein Alias und trägst als "IP" quasi den Hostnamen ein ("meinname.dyndnsanbieter.tld"), kannst du diesen Alias als Quelle oder Ziel IP angeben (Single Host or Alias). Sehr nützlich wenn man sich - zusätzlich zu VPN auf der pfSense - noch eine "Hintertür" einbauen möchte, um notfalls auch direkt auf die pfSense von extern draufzukommen oder auch um Portfreigaben zu testen, ohne die gleich für die ganze Welt zu öffnen ;) -
Sorry, ich missbrauch nun diesen Thread mal für eigene Zwecke.
JeGr:
Da NAT aber VOR den Filter Regeln greift, müssen deine Filterregeln definiert sein in dieser Art:
Quelle: IP, Alias oder any
Ziel: interne IP der WindowsVM (nicht externe, die im NAT Mapping vergeben wurde)Ich definiere die Filter bei Port Forwarding auch in dieser Art. Wäre es besser, die externe IP als Ziel anzugeben, oder ist es gleich?
-
ist zwar Offtopic…
aber bevor ich RDP veröffentliche, nutze ich doch liebe die von PFsense gegebene Funktion und erstelle ein VPN ;)PS: backup der Config bzw. Backup via snapshot bietet sich an jetzt an wo es Funktioniert :P
grüße
-
Quelle: IP, Alias oder any
Ziel: interne IP der WindowsVM (nicht externe, die im NAT Mapping vergeben wurde)
Dann sollte das auch klappen. Tipp: Wenn du ein IP Alias definierst mit einer URL bzw. Hostnamen, dann wird dieser Alias zyklisch aufgelöst in eine IP und das Alias aktualisiert.
Sprich: Definierst du ein Alias und trägst als "IP" quasi den Hostnamen ein ("meinname.dyndnsanbieter.tld"), kannst du diesen Alias als Quelle oder Ziel IP angeben (Single Host or Alias). Sehr nützlich wenn man sich - zusätzlich zu VPN auf der pfSense - noch eine "Hintertür" einbauen möchte, um notfalls auch direkt auf die pfSense von extern draufzukommen oder auch um Portfreigaben zu testen, ohne die gleich für die ganze Welt zu öffnen ;)Das funktioniert aktuell leider noch nicht.
Komme generell nicht von außen an meine VM, weder per Ping oder RDP.
aber bevor ich RDP veröffentliche, nutze ich doch liebe die von PFsense gegebene Funktion und erstelle ein VPN
Ja, wird auch alles noch schön gemacht. Aber wie unsicher ist RDP denn noch, wenn der Standardport geändert und es ein ausreichend starkes PW gibt :) das Restrisiko ists mir aktuell wert, normal auf der Maschine arbeiten zu können.
Mit VPN etc in pfSense hab ich mich noch nicht beschäftigt. Will erstmal alles zum laufen kriegen, danach (dachte ich) bau ich den VPN drumrum.
PS: backup der Config bzw. Backup via snapshot bietet sich an jetzt an wo es Funktioniert
Jup, kommt auch noch :)
-
aber bevor ich RDP veröffentliche, nutze ich doch liebe die von PFsense gegebene Funktion und erstelle ein VPN
Ja, wird auch alles noch schön gemacht. Aber wie unsicher ist RDP denn noch, wenn der Standardport geändert und es ein ausreichend starkes PW gibt :) das Restrisiko ists mir aktuell wert, normal auf der Maschine arbeiten zu können.
Den Port zu ändern ist keine Sicherheitsmaßnahme, mit nem Portscanner ist es eine Sache von Sekunden den Port herauszufinden.
Die Exploits um RDP direkt anzugreifen bzw. um durch RDP schaden anzurichten halten sich in grenzen (mir ist zumindest die letzten Jahre nix davon zu Ohren gekommen)
Ein ausreichend sicheres Passwort ist selbstverständlich !Ich persöhnlich würde jedoch nie einen Dienst zur Fernwartung ohne ReverseProxy (mit logging) oder ähnliches veröffentlichen, solche Dienste können leicht per DDOS angegriffen werden und versuchen immer Last. Zudem ist es schwierig nachzuverfolgen wenn jemand mal auf der Windows Kiste ist und dich aussperrt von wo der Angriff kam.
Auch bin mir gerade nicht ganz sicher ab welchem Zeitpunkt die Usercals ausbucht, ob dies erst bei erfolgreicher Anmeldung passiert oder erst wenn du wirklich auf dem Desktop bist, ergo könnte es dir passieren das jemand ein paar "dummyconnections" aufbaut und du dann selbst nicht mehr per RDP drauf kommst weil die Cals aufgebraucht sind. (wie gesagt da bin ich mir aktuell nicht ganz sicher)Dazu aber hier genug, kannst dich per PN melden oder einen anderen Thread aufmachen. Weiß nicht wie man soetwas hier macht.
grüße
grüße
-
aber bevor ich RDP veröffentliche, nutze ich doch liebe die von PFsense gegebene Funktion und erstelle ein VPN
Ja, wird auch alles noch schön gemacht. Aber wie unsicher ist RDP denn noch, wenn der Standardport geändert und es ein ausreichend starkes PW gibt :) das Restrisiko ists mir aktuell wert, normal auf der Maschine arbeiten zu können.
Den Port zu ändern ist keine Sicherheitsmaßnahme, mit nem Portscanner ist es eine Sache von Sekunden den Port herauszufinden.
Die Exploits um RDP direkt anzugreifen bzw. um durch RDP schaden anzurichten halten sich in grenzen (mir ist zumindest die letzten Jahre nix davon zu Ohren gekommen)
Ein ausreichend sicheres Passwort ist selbstverständlich !Ich persöhnlich würde jedoch nie einen Dienst zur Fernwartung ohne ReverseProxy (mit logging) oder ähnliches veröffentlichen, solche Dienste können leicht per DDOS angegriffen werden und versuchen immer Last. Zudem ist es schwierig nachzuverfolgen wenn jemand mal auf der Windows Kiste ist und dich aussperrt von wo der Angriff kam.
Auch bin mir gerade nicht ganz sicher ab welchem Zeitpunkt die Usercals ausbucht, ob dies erst bei erfolgreicher Anmeldung passiert oder erst wenn du wirklich auf dem Desktop bist, ergo könnte es dir passieren das jemand ein paar "dummyconnections" aufbaut und du dann selbst nicht mehr per RDP drauf kommst weil die Cals aufgebraucht sind. (wie gesagt da bin ich mir aktuell nicht ganz sicher)Dazu aber hier genug, kannst dich per PN melden oder einen anderen Thread aufmachen. Weiß nicht wie man soetwas hier macht.
grüße
grüße
Ja, ich weiß aber das Verwalten der ganzen Geschichte über die langsame Konsole vom ESXi, ist stark nervig. Per RDP kann man dann wenigstens halbwegs flüssig arbeiten :)
Aber wie gesagt, aktuell ist ja von außen eh nicht viel machbar, also auch keine Angriffe :D
Hab verschiedene Versionen für die Firewall-Rule angelegt aber er will einfach nicht… -.-'
Heut abend nochmal in Ruhe anschauen, grad auf arbeit
-
@robby1337: Empfehlung ist definitiv, das später nur auf spezifische QuellIP freizugeben (siehe Tipp mit Dyndns Alias in Firewall Rules) oder besser per VPN. Den Alias kann man immer noch als Fallback nutzen.
Jede Portverschieberei ist absolut nutzlos. Vergesst es darauf zu vertrauen. Nur zum Vergleich: mit ZMap ist es mittlerweile möglich das GESAMTE Internet für einen Port (bspw. 5900 für VNC) unter einer Stunde abzugrasen. Wenn mir da noch jemand kommt mit "ich nehm aber keinen Standard Port" - gut gelacht ;) ZMap drüber, Fingerprint an, BING Port gefunden. Ne ne. Nix da.
Ansonsten poste doch mal kurze Shots von deinem vswitch wie die VM da drin hängt, von deinem NAT und deinen Firewall Regeln (ggf. ausschwärzen), dann sieht man vielleicht besser was noch klemmt.
@viragomann: Nein die Filter müssen auf die interne IP gehen, weil der Filter die externe gar nicht mehr sieht. Da gehts nicht um besser oder schlechter, es geht nur so :) NAT greift bei PF vor den Filtern, also sehen die Paketfilter nur noch Pakete umgeschrieben an die interne IP und die würden ohne Regel blocken oder bouncen/rejecten.
-
@JeGr
Danke. Meine Frage hat sich ja auf den Fall von Port Forwarding bezogen, wo ich auch immer die Regeln auf die interne IP setzte. Hab das nie anders gemacht.
Dass es beim Bridging kein intern/extern gibt ist mir soweit klar. ;) -
@robby1337: Empfehlung ist definitiv, das später nur auf spezifische QuellIP freizugeben (siehe Tipp mit Dyndns Alias in Firewall Rules) oder besser per VPN. Den Alias kann man immer noch als Fallback nutzen.
Jede Portverschieberei ist absolut nutzlos. Vergesst es darauf zu vertrauen. Nur zum Vergleich: mit ZMap ist es mittlerweile möglich das GESAMTE Internet für einen Port (bspw. 5900 für VNC) unter einer Stunde abzugrasen. Wenn mir da noch jemand kommt mit "ich nehm aber keinen Standard Port" - gut gelacht ;) ZMap drüber, Fingerprint an, BING Port gefunden. Ne ne. Nix da.
Okay, sobald die erste VM gescheit läuft, versuch ich das umzubauen. :)
Ansonsten poste doch mal kurze Shots von deinem vswitch wie die VM da drin hängt,
Hier weiß ich leider nicht genau, was du genau meinst ^^
Ich dachte eigentlich, das ist die Ansicht die ich im Screen auf Seite 1 des Threads gepostet habe? (ohne die vmnic1 bei vSwitch1 :))von deinem NAT und deinen Firewall Regeln (ggf. ausschwärzen), dann sieht man vielleicht besser was noch klemmt.
Jau, siehe Anhang!
@viragomann: Nein die Filter müssen auf die interne IP gehen, weil der Filter die externe gar nicht mehr sieht. Da gehts nicht um besser oder schlechter, es geht nur so :) NAT greift bei PF vor den Filtern, also sehen die Paketfilter nur noch Pakete umgeschrieben an die interne IP und die würden ohne Regel blocken oder bouncen/rejecten.
Danke, die Beschreibung hilft mir tatsächlich auch beim verstehen :P!
Danke für die Rückmeldungen und Geduld! ^^
edit Achja! VIPs hab ich nicht separat definiert
edit2 Dank deinem Tipp & https://doc.pfsense.org/index.php/Aliases hab ich es geschafft, das die VM von außen erreichbar ist über die nötigen Ports! der Rest müsste mit der angelegten Regel meines Screenshots ja weggeblockt werden :o ?
edit3 haha, anscheinend doch nicht..das was ich testete, funktionierte aufgrund eines Logins, der wahrscheinlich von Intern funktioniert hat. Der Dienst der aber darauf zugreifen will, kommt von außen nicht drauf.
-
Quelle: IP, Alias oder any
Ziel: interne IP der WindowsVM (nicht externe, die im NAT Mapping vergeben wurde)Hab FW Rule mit any
und Destination 192.168.1.101Tut nit :(
-
Sorry das ich mich hier mit einklinke. Ein weiterer Thread wäre überflüssig.
Da ich das selbe Problem habe.
Ich kann von meinen VMs raus gehen, also wenn ich per ESXi dann über die Konsole drauf gehe alles super die VMs kommen ins Netz aber ich kann sie nicht anpingen oder bei Unix per SSH drauf.
Auch habe ich in der Firewall wie bei Robby das eingestellt.
Kurz Technische Info: Ich habe den Root bei Hetzner.
Eine IP für VMWare und eine für pfSense mit MAC und eine 6er Subnet auf dem die VMs sollen.
Hoffe das ihr da eine Lösung zu habt.
MFG Maggi
 -
boah ich komm echt nicht mehr weiter. Weder mit Logik, noch mit probieren jeder erdenklichen config :P
Im Anhang nochmal Screens meiner aktuellen konfiguration. Ich komm mit der Maschine "Media" fein nach außen, von außen aber nicht an sie ran.
Hilfe :/
-
@robby: Aber kommst du bspw. von extern auf die pfSense (sollte nicht, es sei denn du hast den Port auf WAN geöffnet)? Bzw. siehst du einen fehlgeschlagenen Portzugriff auf 80/443 auf die pfSense WAN IP wenn du drauf zugreifst?
Ich versuche nur auszuschließen, dass da überhaupt was ankommt ;) da aber das NAT ja läuft von innen nach außen gehe ich mal sicher davon aus.
Die andere Frage wäre, ob du in den FW Logs was siehst. Also bspw. mal testen bei "wieistmeineip" o.ä. wie deine aktuelle IP ist und schauen, ob die im FW Log auftaucht beim Zugriff auf die media-Maschine.@csamaggi: Dein Setup sieht irgendwie verbogen aus. Die vmWare Einstellungen sollten schon wie bei robby aussehen, wenn deine VM nicht im LAN, sondern direkt "neben" der pfSense auf dem WAN Interface hängt, wird das nie funktionieren, da Hetzner einen MAC Blocker auf dem Port hat und die VMs dann nicht raus können. Deshalb muss man ja den Spaß mit Routing VM machen :)
Grüße
Jens
