Pfsense in einer VM (KVM) auf Hetzner Root-Server
-
Soo, die pfsense an sich läuft nun erstmal:
/etc/network/interfaces:
allow-vmbr0 eth0 iface eth0 inet manual pointopoint xxx.xxx.xxx.1 broadcast xxx.xxx.xxx.31 auto vmbr0 iface vmbr0 inet static address xxx.xxx.xxx.9 netmask 255.255.255.224 gateway xxx.xxx.xxx.1 bridge_ports eth0 bridge_stp off bridge_fd 0 auto vmbr1 iface vmbr1 inet static address 192.168.1.1 netmask 255.255.255.0 bridge_ports none bridge_stp off bridge_fd 0XML der VM:
<interface type="bridge"><mac address="xx:xx:xx:xx:xx:xx"><source bridge="vmbr0"> <target dev="vnet0"></target></mac></interface> <interface type="bridge"><mac address="xx:xx:xx:xx:xx:xx"><source bridge="vmbr1"> <target dev="vnet1"></target></mac></interface>Dann per VNC die pfsense installiert und die beiden Devices zugewiesen.
Als nächstes habe ich mir eine weitere VM erstellt:
<interface type="bridge"><mac address="xx:xx:xx:xx:xx:xx"><source bridge="vmbr1"> <target dev="vnet4"></target></mac></interface>Sie nutzt also das LAN-Device von pfsense. Als Image habe ich hier "TinyCore" gewählt … ein super schmales Linux mit Desktop.
Hier dann ebenfalls per VNC reingehüpft und DHCP aktiviert. Absofort war die VM bereits im Netz und ich konnte dann per 192.168.1.1 die pfsense webconfiguration aufrufen.
Nun die nächste Problematik:
Wie stell ich pfsense denn jetzt so ein, dass weitere VM dahinter Servertätigkeiten aufnehmen können, das heißt mit ihrer eigenen public ip erreichbar sind? Grundsätzlich erreicht ja nun jede VM von sich aus das Netz über die privaten IPs. Das macht sie ja aber längst nicht von aussen aufrufbar.Da mein Subnetz noch auf das Hostsystem geroutet ist und die VM somit noch an der Firewall vorbei geroutet werden, ist das erstmal eher theoretisch. Aber früher oder später soll die pfsense ja schließlich die Firewall für alle Router werden.
Ich muss gestehen, ich bin selbst kein großartiger Firewallprofi und hätte jetzt nur das übliche NAT im Kopf gehabt.
Muss ich jetzt jeden einzelnen Port, der auf einem der dahinter liegenden Server nutzbar sein muss per NAT mit der öffentlichen IP auf die private IP forwarden?
Wie meinst du das isolierte Netz? Im Prinzip doch so, wie ichs nun habe oder?
Mein Ziel (IPs fiktiv):
WAN : : : .----+----. WAN | Hetzner | '----+----' | Ethernet (eth0)| | .----+----. | KVMHOST | '----+----' vmbr0 (WAN) | .----+----. | pfSense | '----+----' | vmbr1 (LAN) | 192.168.1.0/24 | | +------------------+------ - - - -----+------------------+------------------+------------ | | | | | .-----+------. .-----+------. .-----+------. .-----+-----. .------+------. | Web-Server | | Web-Server | | Web-Server | | DB-Server | | Mail-Server | '------------' '------------' '------------' '-----------' '-------------' public 200.0.0.190 200.0.0.191 200.0.0.198 200.0.0.200 200.0.0.201 private 192.168.1.190 192.168.1.191 192.168.1.198 192.168.1.200 192.168.1.201Danke und viele Grüße
Chris -
Ich verwalte KVM über den grafischen Virtual Machine Manager. Dieser kann selbst virtuelle Netzwerke erstellen, dabei kann man wählen zwischen "isoliertem virtuellen Netzwerk" und "zum pfysischen Netzwerk weiterleiten". Ersteres ist eben vom Wirt-Netzwerk getrennt und letzteres kann mittels NAT oder geroutet angebunden werden.
Diese Netzwerke werden dann am Host mit ifconfig als vibr0, vibr1, usw. angezeigt.Du hast mit vmbr1 eine Bridge am Host erstellt. Sollte auch funktionieren, aber entferne die IP, ansonsten hängt ja der Wirt auch dran.
Hab grad gelesen, das hast du eh angemerkt.Die Firewall sollte dann über NAT die Dienste an die VMs routen.
Ich denke, du hast ein Öffentliches Subnetz, wie du es dargestellt hast ein /29. So musst du die pfSense WAN Schnittestelle auch so konfigurieren. Dann kansst du 1:1 NAT verwenden, um mit einem Schlag das ganze Subnetz weiter zu routen oder du legst für jede Public IP eine eigene Port Forward Regel an. Du kannst mit einer Regel auch gleich eine ganze IP Range weiterleiten ohne dabei eine Firewall-Regel zu aktivieren und in den gesonderten Firewall-Regeln dann definieren, was erlaubt ist.Grüße
-
Ich denke, du hast ein Öffentliches Subnetz, wie du es dargestellt hast ein /29. So musst du die pfSense WAN Schnittestelle auch so konfigurieren. Dann kansst du 1:1 NAT verwenden, um mit einem Schlag das ganze Subnetz weiter zu routen
Ja, das ist das, was ich machen wollte … allerdings scheitere ich offenbar an den Einstellungen, da ich absoluter pfsense Neuling bin und gar nicht erst rausbekomme, wo ich das konfiguriere :)
-
Ich hatte gehofft, dass darauf jemand anders antwortet, der damit Erfahrung hat. Ich kenne es auch nur aus der Theorie. Es gibt aber Anleitungen, z.B. https://doc.pfsense.org/index.php/1:1_NAT
Gute Hinweise gibt es auch direkt in der GUI.Ich verwende normales Port-Forwarding, weil es mehr Möglichkeiten bieten, ist aber aufwendiger zu konfigurieren.
Dazu legst du in Firewall > Virtual IPs für jede deiner Public-IPs mit Ausnahme der WAN-Adresse (die bereits dem Interface zugeordnet ist) eine virtuelle IP des Typs "IP Alias" an. Interface ist natürlich immer WAN, Adresse und Maske angeben und darunter eine Bezeichnung zuweisen. Diese VIPs hat man dann mit Namen in den NAT- und Firewall-Regeln in den Dropdowns zu Auswahl.
Bei einem /29er Netz sind das ja gerade mal 4 VIPs, die man anlegen muss. -
Hallo Chris,
wie du die IPs abgreifen kannst, liegt auch ein Stück weit daran, wie das Netz geroutet ist. Bei Hetzner wird ein Subnetz wie bspw. ein /29er meistens auf eine andere IP geroutet (jeder Server bekommt ja eine inklusive, dorthin wird meist das Netz geroutet). Wenn das bei dir ebenso ist und du die pfSense mit der Server IP betreibst, dann musst du bspw. nicht einmal ein IP Alias anlegen, da dir die IPs des /29er Netzes automatisch zugeworfen werden (durch das Routing). Du kannst dann in der pfSense einfach ein weiteres internes Netz aufspannen, der pfSense in diesem Netz ein Bein und eine IP geben und den Rest an die VMs an diesem internen Interface/Switch. Diese bekommen dann die pfSense als Gateway, die pfSense hat wieder ihr Hetzner Upstream Gateway und alles ist schön. Allerdings fallen dann potentiell 3 IPs flach: die eine, die du der pfSense geben musst zum Routen sowie die Boundary Adressen.
Eine geschicktere Idee (nicht besser im Sinne des Netzwerkers aber leider nötig da NAT seufz) wäre die IPs einfach per 1:1 NAT weiter zu reichen. Intern definierst du beliebige interne Switche (oder Bridges wie vmbr1 oben) und bindest diese an die pfSense an. So wie du das oben bereits beschrieben hast bspw. Dann kannst du im Reiter 1:1 NAT der pfSense eine externe IP des /29er Netzes angeben und dieses intern an eine 192.168.1.x vergeben. Dazu dann die Firewall Regel zum Erlauben der Verbindung nicht vergessen, bei 1:1 NAT wird keine automatische Regel erzeugt. Wichtig auch: bei NAT muss in der FW Regel IMMER die INTERNE Adresse als Ziel genannt sein (also von any nach 192.168.1.x), da NAT VOR den Regeln greift, das Paket dann bereits umgeschrieben wurde und dann gegen den Filter geprüft wird. Das ist der häufigste Fehler bei NAT/BINAT + FW Regeln. Anschließend müsste die VM dann von extern unter ihrer IP erreichbar sein.
Vorteil davon: Du kannst auch die Adresse verwenden, die du sonst der pfSense auf dem Routing Interface geben müsstest. Zusätzlich kannst du sogar (ein wenig dreckig) für ausgehende NAT bspw. (für VMs die nur nach draußen kommen sollen bspw. zu Updates, aber nicht erreichbar sein sollen) eine der Boundary IPs vergeben. Das ist zwar eigentlich nicht erlaubt, da du aber nicht routest und die IP nur abgehend verwendet wird, ist es in diesem Spezialfall egal :)
Grüße
-jens -
So ich bin nun endlich mal wieder dazu gekommen, diese Baustelle weiter abzuarbeiten :)
Ich hätte behauptet, ich müsste fertig sein, aber irgendwo scheint ein klicksel zu fehlen.
die Firewall-VM läuft, eine gesonderte VM dahinter (auf vmbr1 - LAN) mit minimals Linux zur Konfiguration der Firewall per VNC läuft, 2 weitere VM sind an der vmbr1 angeschlossen.
Alle VM können untereinander pingen. Alle VM können nach aussen - z.B. google.de - pingen.
Keine VM kann von aussen z.B. über http Daten laden. Ein wget http://www.google.de führt immer zum Connection timed out. In der VM zum konfigurieren der Firewall kann ich auch im Firefox nur das Backend der firewall aufrufen … alles andere geht nicht.
Die Server-VM sind auch von aussen nicht erreichbar ... auch nicht per Ping.Ich habe mal 2 Screenshots meiner Testeinstellungen an der Firewall angefügt.
das 1:1 NAT für die 2 ServerVM sowie eine Regel um den Traffic von aussen in mein 192.168.1.0 Netz zu erlauben (zumindest dachte ich, dass es so ok ist).Auf dem Hostsystem sind diese Routen:
root@kvm2 ~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 xxx.xxx.xxx.33 0.0.0.0 UG 0 0 0 vmbr0 xxx.xxx.xxx.32 0.0.0.0 255.255.255.224 U 0 0 0 vmbr0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 vmbr1meine Desktop-VM hat diese:
~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0Jemand eine Idee, wo das Problem liegt?
Grüße
Chris
-
kleiner Nachtrag:
auf meinem ersten Testsetup ging die Verbindung nach Aussen direkt auf Anhieb. Nachdem ich der Desktop-VM per DHCP die Daten abrufen ließ, konnte ich sofort problemlos im Browser surfen und Pakete nachinstallieren. Das geht bei meinem jetzigen Setup nicht.
Eigentlich sehe ich nur 2 Unterschiede:
1. beim 2. Setup hat Hetzner bereits das Subnetz auf die MAC-Adresse der Firewall-VM geroutet. Das stand beim ersten Setup noch aus, weil es eine Produktivumgebung war.
2. im 1. Setup läuft noch Ubuntu 10.04.4 LTS … im zweiten bereits Ubuntu 14.04.2 LTS.
Mittlerweile habe ich sogar die Firewall- und Desktop-VM vom ersten Setup auf das zweite kopiert um auszuschließen, dass ich nicht doch bereits irgendeine Regel im System definiert hatte, die mir jetzt nicht mehr einfällt aber auch damit habe ich das selbe Problem. :(
-
Hallo Chrisi,
die 1:1 Regeln sehen erstmal OK aus, die FirewallRegel ist gefährlich offen, aber seis drum. Wichtig wäre aber: mach bei der FW Regel mal den Haken bei Logging rein, dann versuche von außen auf eine VM hinter der 1:1 NAT zuzugreifen und schaue nach, ob ein Eintrag geloggt wurde. Bspw. von außen SSH auf die .25 machen und im Log dann nach Port 22 TCP filtern. Dann siehst du bspw. ob das NATting überhaupt zugeschlagen hat oder ob überhaupt nichts ankommt.
Das kann jetzt auch externes Routing o.ä. sein, als nicht nervös werden und erstmal alle Basics absichern. Firewall VM auf WAN geht von extern? Kommen die anderen IPs auch wirklich auf der VM an? (deshalb der Check mit der Regel oben)
Ansonsten mal tcpdumpen, ob du in der pfSense - und wenn dort nicht auf dem KVM Hostsystem - die IPs (.25 bspw.) überhaupt ankommen siehst.Viele Grüße
-
ich find das langsam echt schräg, siehe angehängte Datei.
Laut Log wird mein ssh request auf die 25 durchgelassen. Aber ich bekomm dennoch keine Verbindung, obwohl der ssh Dienst läuft. Das selbe quasie bei http. Ich schätze, der eingehende Traffic ist ok, aber der ausgehende zickt, wobei ich keine Erklärung dafür habe :(
Lasse ich einen Ping von aussen auf die 25 laufen, hört dieser auf zhu funktionieren, sobald ich die firewall rule deaktiviere. Aktiviere ich sie wieder, geht der Ping wieder direkt.
-
Also wenns eingehend grün ist, ist die Regel OK und der State sollte angelegt werden. Damit sollte die Verbindung auch klappen. Jetzt kann es nur noch daran liegen dass
- die Pakete nicht sauber zurückkommen (Rückrouting?)
- der Host die Pakete verwirft (Firewall, etc.)
- Ausgehend ein falscher Weg genommen wird
etc.
Was dir an der Stelle helfen könnte ist ein TPCDump auf der pfSense eingeschränkt auf den Host (84.132.162.215 bspw.) so dass du nur Pakete von dort loggst und schaust, wie die über die Firewall gehen. Und dann natürlich auch auf der .25 mal laufen lassen, ob die überhaupt antwortet, wohin sie antwortet und ob der Antwort Traffic da ankommt. Bei falschem Routing bspw. sieht man auf der pfSense nur die "S" Pakete (Syn) bzw. "S." und irgendwann ein "R" für Reset. Aber man sieht keine A oder SA Pakete fürs "Acknowledgen". Wenn du da mal loggst, wirst du es hoffentlich herausfinden, wo dein Problem liegt :)
-
ist genauso wie du es beschreibst.
auf der pfsense bei tcpdump host <meine ip=""> während dem versuch per ssh auf die .25 zu kommen, bekomme ich nur S/S. States im Log.
Auf der .25 ist es etwas kompliziert, da ich ja da kein Internet habe, eben wegen dem Problem. tcpdump nachinstallieren geht also nicht :(
Was ich dabei nicht verstehe: es ist ja wie bereits gesagt, das 2. Setup … dies mal produktiv ... im Test habe ich es ja absolut identisch gemacht ... ja sogar die pfsense vm am Ende kopiert aus der Testumgebung. In diesem Testsetup hat sich meine Desktop VM zur Steuerung der pfsense direkt nach "DHCP login" alle Daten geholt und war somit direkt im Internet unterwegs. Ganz ohne irgendeiner Regel.
Jetzt im Produktiv-Aufbau, geht ja nicht mal das ... also irgendwo sperrt die pfsense offenbar jeglichen Ausgang oder verweigert einfach nur den Zugriff aufs Internet.Das einzige was von meinem Rechner => VM geht ist ping. Und ping geht auch merkwürdiger Weise von der VM => z.B. google.de.
=> heißt für mich eigentlich: DNS geht, Internet geht, wichtige Ports sind zu oder?!
Mal ganz nebenbei: Vielen Dank, dass du dir die Zeit nimmst, mich zu unterstützen :)
edit: Jetzt meine ich zu wissen, wer oder was der Übeltäter ist, nur habe ich grad keine Idee, wie ich das behebe.
In meinem Testsetup hatte ich wohl damals die Single-IP direkt beim Server mitbestellt ... zumindest liegt die Single-IP und die IP des Servers im selben Netz - daher haben beide IP die selben Gateway-Einstellungen.
Beim Livesetup ist die Single-IP ja deutlich später aufgesetzt worden. Daher unterscheiden sich die Netze und somit die Gatewayeinstellungen./etc/network/interfaces:```
Hetzner Online AG - installimage
Loopback device:
auto lo
iface lo inet loopbackallow-vmbr0 eth0
iface eth0 inet manual
pointopoint [Gateway Hostsystem]
broadcast [Broadcast Hostsystem]auto vmbr0
iface vmbr0 inet static
address [IP Hostsystem]
netmask [Netmask Hostsystem]
gateway [Gateway Hostsystem]# address [IP SingleIP/pfsense]
# netmask [Netmask SingleIP/pfsense]
# gateway [Gateway SingleIP/pfsense]bridge_ports eth0
bridge_stp off
bridge_fd 0auto vmbr1
iface vmbr1 inet static
address [private IP]
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0So sieht es derzeit im Prinzip auf beiden Servern aus. Die auskommentierten Zeilen der Netzdaten der SingleIP war mal ein Test, jedoch ist dann weder das Hostsystem noch irgendeine VM dahinter erreichbar. Also Netz vom Hostsystem scheint hier durchaus richtig?! … Irgendwie beschleicht mich der Gedanke, dass ich hier ein Interface mehr brauche, welches dem Hostsystem die entsprechenden Netzdaten seiner IP gibt und vmbr0 müsste doch die Netzdaten der Single-IP für pfsense erhalten, Oder!? Ich weiß allerdings leider nicht, wie ich dieses Konstrukt in der Config abbilde. Wäre wer so nett, die entsprechenden Anpassungen oben vorzunehmen?</meine> -
niemand mehr? :(
-
ist denn meine Annahme, richtig, dass der angehängte Screenshot jeglichen Traffic durchlässt und somit die Firewall selbst nicht das Problem sein kann, sondern irgendein Routingproblem besteht?
-
Ja, wenn diese Regel am WAN Interface steht, wäre alles erlaubt. Das heißt aber noch nicht, dass die Pakete nicht in der pfSense hängen bleiben. Für das richtige Routing musst du dann noch im NAT sorgen.
Mit der Konfig der Hetzner Server kenne ich mich nicht aus. Ist ein Debian, oder?
Wo ich gewisse Zweifel habe ist, ob es möglich ist, die Host-IP auf die virtuelle Bridge zu legen und auf der selben Bridge VMs in einem anderen Subnetz zu betreiben. Getestet habe ich es aber noch nicht.
Aber ich würde mich mit diesem Problem ans Hetzner Forum wenden. Da wird es doch schon Leute geben, die ähnliches erreichen wollten. -
Also ich habe das nun einmal auf meinem OpenSUSE Host getestet. Auf diesem sind über wickedd 2 Bridges definiert, die je einem Netzwerkinterface zugeordnet sind und eine IP im LAN haben.
2 VMs habe ich eine IP in einem anderen Subnetz außerhalb des LAN gegeben und beide können miteinander kommunizieren, auch dann, wenn ich eine VM an die andere Bridge anschließe und der Traffic damit über den externen Switch läuft.
Also grundsätzlich funktioniert die Sache über die (wickedd) Bridge, sollte dann bei anderen Systemen doch auch funktionieren.Im Zweifelsfall verwende Packet Capture um genaueres von den Vorgängen an den Interfaces der pfSense zu erfahren.
-
Was dir an der Stelle helfen könnte ist ein TPCDump auf der pfSense eingeschränkt auf den Host (84.132.162.215 bspw.) so dass du nur Pakete von dort loggst und schaust, wie die über die Firewall gehen. Und dann natürlich auch auf der .25 mal laufen lassen, ob die überhaupt antwortet, wohin sie antwortet und ob der Antwort Traffic da ankommt. Bei falschem Routing bspw. sieht man auf der pfSense nur die "S" Pakete (Syn) bzw. "S." und irgendwann ein "R" für Reset. Aber man sieht keine A oder SA Pakete fürs "Acknowledgen". Wenn du da mal loggst, wirst du es hoffentlich herausfinden, wo dein Problem liegt :)
Wenn ich auf dem Hostsystem TCP-Dump laufen habe auf die IP der VM-1 und dann mit SSH von aussen komme, erhalte ich nur immer wieder:```
17:38:45.737639 IP [ME-IP].27998 > [VM-1-IP].22: Flags [s], seq 407395059, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 384934721 ecr 0,sackOK,eol], length 0
17:38:45.738377 IP [VM-1-IP].22 > [ME-IP].27998: Flags [S.], seq 1963013495, ack 407395060, win 28960, options [mss 1460,sackOK,TS val 2249125 ecr 384934721,nop,wscale 7], length 0Auf der pfSense sehe ich exakt das selbe.
Ebenso auf der VM-1 selbst ... allerdings ist hier die VM-1-IP durch die interne IP 192.168.1.x ersetzt.
Im Hetzner Forum hatte ich bisher auch noch nicht mehr Glück.[/s]
-
Sorry, war krank. Wenn du auf beiden Systemen die Antwort Pakete von innen nach außen siehst, ist es doch gut? Evtl. ein Problem mit SSH selbst (Cipher o.ä.)? Oder betrifft das auch andere Ports?
-
Ne das betrifft alle Ports.
Von innen kann ich zwar Domains und IPs pingen aber alles andere geht genauso wenig. Das heißt, wenn ich über meine Desktop-VM eine Webseite ansteuer lädt er sich tot und beendet dann. Ein wget auf den anderen VM führt zu unendlichen retrys.
Zwischendurch hatte ich auch mal ein Konstrukt, bei dem ich die VMs von aussen pingen konnte … mehr ging dabei dann aber auch nicht. :(
-
Also so langsam verlier ich die Lust an dem Projekt. Es kann doch nicht so ein Hexenwerk sein. Alles was ich probiere funktioniert einfach nicht.
Ich habe nun mittels nc -k -l 8888 auf der pfsense und nc 192.168.1.1 8888 auf meiner desktop vm zumindest nachvollziehen können, dass diese Maschinen uneingeschränkt miteinander reden können.
Spiele ich das Spiel mit dem Hostsystem, also nc -k -l 8888 auf dem Hostsystem und nc [HOST-IP] 8888 auf der Desktop VM, geht es hingegen nicht.Also offensichtlich routet die pfsense nicht einmal korrekt zum Hostsystem. Eigentlich sollte sie auch direkt an Hetzner routen und Hetzner dann zurück zum Hostsystem, aber da geht wohl genauso wie bei jeglichen anderen Verkehr nach draussen irgendwas schief.
Ich kann nach wie vor keine HTTP-Verbindung aus dem internen Netz nach draussen öffnen.
Hat denn niemand eine Idee was hier los sein könnte? Kann das überhaupt noch ein pfSense Problem sein oder muss es in den Netzwerkeigenschaften sitzen?
Ich habe echt sooo viel recherchiert mittlerweile und so langsam echt überhaupt keine Lust mehr :'(
-
Also offensichtlich routet die pfsense nicht einmal korrekt zum Hostsystem. Eigentlich sollte sie auch direkt an Hetzner routen und Hetzner dann zurück zum Hostsystem, aber da geht wohl genauso wie bei jeglichen anderen Verkehr nach draussen irgendwas schief.
Deine Annahme ist nicht korrekt. Das Problem ist hier nicht die pfSense, sondern die Kombination aus deinem Routing und Hetzner (leider). Durch deren - nennen wir es unschönes - Routing und MAC Beschränkung auf Ports ist es einfach ein totaler Graus sowas aufzubauen, wenn nicht jedes Schräubchen korrekt ist.
Da ich leider weder dein genaues Setup bei Hetzner kenne, noch die Hostkonfiguration (bevor die pfSense kommt) etc. ist es hier einfach verteufelt schwer, dir zu sagen, dass es an X liegt. Wir hatten da damals mit einem einzelnen ESXi auch unsere Probleme bis dann (bevors die schicken Dokus im Wiki gab) mal die Technik mit uns zusammen den Kram richtig gedreht hat, single HostIP auf den Server selbst, zweite IP auf die Routing VM zeigend, prüfen, läuft, dann zusätzliches /29er Netz auf die Routing VM routen von Hetzner aus, testen, auf falsche IP geroutet gewesen, umrouten lassen, testen, kommt an pfSense an, hintendran VM hochziehen, testen, läuft.
Du siehst, das ist schon ein etwas größeres Projekt mit diversen Problemstellen. Da muss man sich durchbeißen :/
Ich würde nochmal ganz von vorne durchtesten. Deine IP die die pfSense hat checken. Raus und rein. Das zusätzliche Netz schauen, obs überhaupt an der pfSense sauber aufliegt UND ob der Rücktraffic auch sauber geht. Also bspw. testweise auf der pfSense selbst die IP mal nutzen und versuchen ob sie geht. Dann kann man sie auch ins Netz dahinter sauber durchreichen.
Also offensichtlich routet die pfsense nicht einmal korrekt zum Hostsystem.
Taucht die Verbindung überhaupt auf der pfSense auf? Ist sie freigegeben? Wie kommunizieren Hostsystem und pfSense? Eigentlich sollten sich die doch gar nicht direkt sehen können?
Kann das überhaupt noch ein pfSense Problem
s.o. ich denke es ist ein Problem im Detail des Netzaufbaus, denn der Rest hat mit anderen Hypervisoren schon sauber funktioniert (hab ich 3 Jahre betrieben). Und KVM sollte kein Problem machen.
Grüße
