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

JeGr

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

chrisi51

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 vmbr1

meine 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 eth0

Jemand eine Idee, wo das Problem liegt?

Grüße
Chris

firewall-1zu1-nat.jpg_thumb

firewall-rules.jpg_thumb

chrisi51

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

JeGr

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

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!