[ESXi] Nichts geht, bin verzweifelt ._.
-
Verstehe ich richtig, dass du:
1x IP für den ESXi selbst (ServerIP)
1x IP für die pfSense
und 1x /28er Netz geroutet auf die pfSense IPhast? So sieht es bspw. das Setup bei Hetzner vor, welches ich auch für ein zwei kleine Kunden betreut habe und das fluppt genau so sehr einfach.
Grüße
Sorry für die verspätete Rückmeldung, paar Tage AFK gewesen.
Jup, absolut korrekt.
.117 ESXi
.109 pfSense
.0 - .16 mein /28 :)Ich bin anscheinend absolut zu unfähig :D (-.-')
Schaffe es nichtmehr, dass mein pfSense on kommt. Ich hab das im ESXi wie auf dem Screenshot im Anhang konfiguriert ([vSphere Client] bei vSwitch1 sowohl mit als auch ohne vmnic1 probiert), im pfSense die Einstellungen wie auf [pfSense]-Screen. Über Konsole dann WAN auf em0, LAN auf em1.Das teil stellt sich Stur -.-
 -
Was ich in dem Bild nicht verstehe: der ESXi hat noch ein zweites Hardware Interface? vmnic1? Womit ist das denn verbunden?
Sicher, dass da nicht der Hoster die .109 auf vmnic1 und die .117 auf vmnic0 aufgelegt hat?Zudem ist es irgendwie kontraproduktiv, eine pfSense als Router einzubauen, wenn am gleichen Switch wie der LAN Port dann noch ein echtes HW Interface mit Verbindung zum Netz hängen würde ;) Da baut man sich dann die Schleife um die Firewall herum :)
Ich vermute eigentlich, dass das so aussehen sollte:
.117 -> geht auf den Hypervisor selbst (quasi management) und sollte ggf. später abgeklemmt werden
.109 -> sollte auf irgendeine NIC gehen (welche abklären) und dann in pfSense auf dem WAN als IP definiert werden inkl. aller sonstwelchen Einstellungen (Gateway etc.)/28er Netz sollte auf die MAC & IP .109 geroutet sein und somit ebenfalls auf dem WAN der pfSense ankommen.
LAN (pfSense VM) -> auf vSwitch1. Alle anderen VMs bekommen dann den vSwitch1 (bzw. dessen Netz) und die pfSense als Gateway. Wenn mans noch lustiger machen möchte, kann man anfangen, dann noch VLANs anzulegen auf dem vSwitch1 und die VMs separiert werden.
Zu prüfen:
- NIC Zuordnung zu IPs
- Routing (/28er auf die .109 geroutet?)
- hat die .109 spezielle Voraussetzungen? Muss ggf. eine definierte MAC Adresse benutzt oder bezogen werden?
Das würde ich ggf. auch beim Hoster nochmal nachfragen.
Grüße
-
Moin,
poste doch mal bitte die Konfiguration deines Netzwerk innerhalb des ESX. Zu finden unter "Konfiguration -> Netzwerk".
Habe die selbe Konfiguration (bis auf die kleinigkeit das ich Port Forwarding statt 1:1 nutze) bei mir und es funktioniert Problemlos.PS: das ganze klingt für mich nach einem bei einem hoster gemieteten Dedicated Server, richtig ?
Ich gehe davon aus das du die zweite IP extra dazu "gebucht" hast, ist diese entsprechend der vorgaben Konfiguriert ?
Der Hintergrund ist das ich bei meinem Hoster für extra hinzugebuchte IP´s eine Mac generieren muss und diese dann in meine VMS eintragen muss. Anders klappt das routing im Rechenzentrum nicht.grüße
//edit
gerade gesehen das ein Screenshot der Netzwerkkonfig ja bereits anhängt.
Das sieht soweit richtig aus. Würde darauf tippen das es wie oben bereits angesprochen am Routing liegt.
Nur nochmal zu verifizierung, wenn du per PFsense GUI "diagnostic->ping" und als host 8.8.8.8 (google) machst, kommst du NICHT raus ? -
Hallo,
vielen Dank für eure Rückmeldungen!
Was ich in dem Bild nicht verstehe: der ESXi hat noch ein zweites Hardware Interface? vmnic1? Womit ist das denn verbunden?
Sicher, dass da nicht der Hoster die .109 auf vmnic1 und die .117 auf vmnic0 aufgelegt hat?Zudem ist es irgendwie kontraproduktiv, eine pfSense als Router einzubauen, wenn am gleichen Switch wie der LAN Port dann noch ein echtes HW Interface mit Verbindung zum Netz hängen würde ;) Da baut man sich dann die Schleife um die Firewall herum :)
Ja, du hast recht, das mit der vmnic1 war falsch. Gerade ne Mail meines Providers bekommen, dass ich das bitte abstellen soll ^^
vmnic1 ist mein Amanda-Backup , worüber eigentlich gar kein Traffic laufen soll außer meiner Backups (welches sowieso noch nicht konfiguriert ist ^^).
Hab das vmnic1 also beim vSwitch1 wieder entfernt, so dass dort nun gar kein physischer Adapter hinterlegt ist.
Aber interessant ist dann (für mich zumindest), warum die VMs im vSwitch1 nach außen telefonieren (eben auf dieses Backup-Netz) obwohl Sie eigentlich gar nicht online waren..oder? -.-'
Ich vermute eigentlich, dass das so aussehen sollte:
.117 -> geht auf den Hypervisor selbst (quasi management) und sollte ggf. später abgeklemmt werden
.109 -> sollte auf irgendeine NIC gehen (welche abklären) und dann in pfSense auf dem WAN als IP definiert werden inkl. aller sonstwelchen Einstellungen (Gateway etc.)/28er Netz sollte auf die MAC & IP .109 geroutet sein und somit ebenfalls auf dem WAN der pfSense ankommen.
LAN (pfSense VM) -> auf vSwitch1. Alle anderen VMs bekommen dann den vSwitch1 (bzw. dessen Netz) und die pfSense als Gateway. Wenn mans noch lustiger machen möchte, kann man anfangen, dann noch VLANs anzulegen auf dem vSwitch1 und die VMs separiert werden.
Genau so soll es sein, ist es AFAIK auch konfiguriert (nachdem vmnic1 nun entfernt ist)
Zu prüfen:
- NIC Zuordnung zu IPs -> Check
- Routing (/28er auf die .109 geroutet?) -> Check
- hat die .109 spezielle Voraussetzungen? Muss ggf. eine definierte MAC Adresse benutzt oder bezogen werden? -> Nein aber s.u
Alles gecheckt ^^
PS: das ganze klingt für mich nach einem bei einem hoster gemieteten Dedicated Server, richtig ?
Ich gehe davon aus das du die zweite IP extra dazu "gebucht" hast, ist diese entsprechend der vorgaben Konfiguriert ?
Der Hintergrund ist das ich bei meinem Hoster für extra hinzugebuchte IP´s eine Mac generieren muss und diese dann in meine VMS eintragen muss. Anders klappt das routing im Rechenzentrum nicht.Genau, Server steht in DC meines Providers.
Eine MAC muss ich für diese nicht generieren, frage aber parallel sicherheitshalber nochmal ^^Nur nochmal zu verifizierung, wenn du per PFsense GUI "diagnostic->ping" und als host 8.8.8.8 (google) machst, kommst
du NICHT raus ?Genau, keine Chance :(
-
Moin,
PS: das ganze klingt für mich nach einem bei einem hoster gemieteten Dedicated Server, richtig ?
Ich gehe davon aus das du die zweite IP extra dazu "gebucht" hast, ist diese entsprechend der vorgaben Konfiguriert ?
Der Hintergrund ist das ich bei meinem Hoster für extra hinzugebuchte IP´s eine Mac generieren muss und diese dann in meine VMS eintragen muss. Anders klappt das routing im Rechenzentrum nicht.Genau, Server steht in DC meines Providers.
Eine MAC muss ich für diese nicht generieren, frage aber parallel sicherheitshalber nochmal ^^Ich glaube da sollten wir ansetzen ;)
Du schreibst "DC meines Providers", handelt es sich um einen Server den du in das Rechenzentrum gestellt hast, oder handelt es sich um einen gemieteten Server von einem Provider (OVH, HETZNER, Server4you und wie sie alle heißen) ?Falls das der Fall ist, ein gemieteter Server, würde ich mal in das Kontrolcenter des entsprechenden Providers gehen und mich dort etwas umsehen. (vielleicht sagst du uns einfach mal den Provider, ich kenne einige und einige bieten auch anleitungen für sowas)
Ich kenn das so das man dort eine MAC für seine zustzöich gebuchte IP generieren lassen muss. Diese MAC musst du dann deiner virtuellen Maschine geben. Entweder direkt in der virtuellen Hardware (dazu müsstest du aber PFsense neu installieren) oder du fakst die MAC adresse indem du diese unter "interface->wan interface" einträgst.Hintergrund der ganzen, doch etwas verirrenden, geschichte ist. Das der Rechenzentrums betreiber die MAC Adresse ja bei sich in diverse Geräten eintragen muss, damit das Routing auch gescheit funktioniert. Wenn du mit der von VMware generierten MAC adresse arbeitest, wird diese von den Switches und Routern im RZ natürlich ignoriert.
grüße
-
k0ssi hat an der Stelle recht, meine Kundenmaschine stand damals auch bei Hetzner, wo ich auf der WAN Seite der pfSense eine MAC Adresse vorgegeben bekam und diese eintragen musste, da Hetzner auf seinen Switches MAC Filter hat und Fremdtraffic blockt. Deshalb muss die MAC der VM stimmen oder pfsense muss sie eben überschreiben (ich hatte sicherheitshalber beides).
Ansonsten kann es noch andere Providerkniffe geben wie Pseudo-Host-Rounting direkt mit /32 Netzadressen oder ähnlichen Unfug um die Kunden zu geißeln ;)
-
Danke für eure Rückmeldung.
Server steht in Köln bei HostEurope.Hab grad mit dem Support gesprochen, ob für die zusätzliche IP noch eine Mac-Adresse benötigt und die noch irgendwo hinterlegt werden muss. Antwort: Nein muss nicht. :/
Bin grad noch mim Support dran und hoffe noch auf die ein oder andere gute Idee..ich update hier ^^
Das einzige was ich in dem Zusammenhang bei HE finde ist:
"Um die Netzwerksicherheit zu gewährleisten, sind unsere Switches so konfiguriert, dass diese nur eine bestimmte Anzahl MAC Adressen je Port zulassen. Werden Virtuelle Maschinen im Bridged Modus betrieben, kann dies somit zur automatischen Sperrung des Switchport führen, welcher erst nach 10 Minuten automatisch wieder entsperrt wird. Befolgen Sie daher bitte unbedingt unsere Konfigurationsanweisung, um eine Nichterreichbarkeit durch die Sperrung des Port zu verhindern."
http://faq.hosteurope.de/index.php?cpid=15523
-
Moin,
das mit der Anzahl der MAC´s sollte bei dir wohl kaum zutreffen.
Interessant das die offensichtlich keine MAC´s filtern, falls das wirklich so sein sollte naja.. gehen wir mal net in Details ;)
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 ?
Sowas muss ein DC/RZ vorgeben, ansonsten verursachst du unnötig Traffic bzw. belastest das Netzwerk unnötig.
Kannst du das Gateway pingen ?grüße
-
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 :(
