Pfsense in einer VM (KVM) auf Hetzner Root-Server

chrisi51

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.

firewall.jpg_thumb

firewall2.jpg_thumb

JeGr

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 :)

chrisi51

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 loopback

allow-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 0

auto vmbr1
iface vmbr1 inet static
address [private IP]
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0


So 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>

chrisi51

niemand mehr? :(

chrisi51

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?

rules.jpg_thumb

viragomann

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.

viragomann

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.

chrisi51

@JeGr:

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 0

Auf 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]

JeGr

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?

chrisi51

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. :(

chrisi51

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 :'(

JeGr

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

chrisi51

Sooooooo … ich habs ... bzw. es wurde mir jetzt im Hetzner-Forum zugetragen. Da ich es selbst immer hasse, wenn Fragen offen bleiben, also auch hier die Auflösung:

https://doc.pfsense.org/index.php/VirtIO_Driver_Support#Disable_Hardware_Checksum_Offloading

Man muss offenbar bei aktuellen VirIO-Treibern das Hardware Checksum Offloading explizit deaktivieren in den Advanced Settings der pfSense.

Dieses eine Häkchen hat mich jetzt Wochen gekostet … unglaublich :)

PS: Das Routing an und für sich war also grundsätzlich in Ordnung die ganze Zeit. :)

viragomann

Danke für die Antwort.
War ja eine harte Nuss, die Sache.

Ich denke, für meine Testzwecke verzichte ich weiterhin auf virtIO und bleibe bei E1000 NICs. Aber im Produktiv-Einsatz wird es wohl einen Performancevorteil bringen.

JeGr

@Chrisi: Herzlichen Dank dass du uns hast teilhaben lassen an der Lösung, ich denke dass das vielen mit ähnlichen Problemen weiterhelfen kann, und sei es nur als Lösungsansatz!