[solved] Verbindungen über Netzwerkgrenzen hinweg

Bob.Dig

@viragomann Die "Clients" sind über ein anderes Interface (LAN) mit der Sense verbunden als der Host selbst. Und das ist ein Problem für den "Recording Service". Regeln erlauben natürlich die Verbindung.

Wenn ich hier bridgen will, wird es gefährlich, weil es halt auch LAN betrifft. Werd ich aber wohl machen, wenn keiner ne andere Idee hat.

viragomann

Okay, verstehe. Die pfSense kann also ganz normal mit dem Server kommunizieren.

Das Outound NAT der pfSense ist hier dein Freund. Es ersetzt die Quell-IP in Paketen, die zu dem Server von den Clients laufen, mit der Interface-IP der pfSense Schnittstelle.
Das Outbound NAT mus im manuellen oder hybriden Modus gestellet werden. Dann einfach eine Standard-Regel erstellen:
Quelle: das Netz, in dem die Clients beheimatet sind.
Ziel: der Host
Translation: Interface Adresse

Was in die Richtung darf, kontrollierst du mit Firewall-Regeln.

Bob.Dig

@viragomann Danke, es läuft.

Als Interface habe ich hier die Verbindung des Hosts zu pfSense ausgewählt.

viragomann

@Bob-Dig said in Verbindungen über Netzwerkgrenzen hinweg:

Als Interface habe ich hier die Verbindung des Hosts zu pfSense ausgewählt.

Ja, natürlich, das Interface, das hier auszuwählen ist, muss jenes sei, an dem die Pakete die pfSense Richtung Ziel verlassen.
Als Translation Address ist dann die Interface-IP naheliegend, kann aber auch eine andere virtuelle IP sein, die du dem Interface zuvor zugeordnet hast, aber eben eine aus demselben Subnetz.

Bob.Dig

@viragomann Habe jetzt aber Probleme mit einem anderen Rechner in LAN, der bekommt keine IP Adresse mehr... Vielleicht ist die Regel doch nicht korrekt?

viragomann

@Bob-Dig
Mit dieser Outbound NAT Regel kann das nichts zu tun haben. Die behandelt ausschließlich Pakete, die zum Host gehen.

JeGr

Können die Clients jetzt mit dem Server reden? Ist für den Server echt nur die Source IP ein Problem? Dann ist das ganz schön gruselige Software ;) Aber hey wenns so funktioniert, warum nicht :)

Bob.Dig

Etwas anderes ist viel gruseliger, meine pfSense ist gerade über den Jordan gegangen, ich habe nur noch Link-local IPv4 Adressen bekommen, nur der DNS-Server stimmte noch. So konnte ich auch nicht mehr auf die pfSense verbinden (bzw. hab es auf die Link-local IPv4 Adresse auch nicht versucht).
Ich hatte Gott sei Dank noch ein passenden Backup von gestern.

Könnte Ihr bitte noch mal drauf schauen, ob die NAT-Regel wirklich in Ordnung ist? Ich hatte sie zuerst auf LAN gesetzt, nachdem das nicht ging dann auf das andere Interface, weil Noob. Und die besagte Verbindung ging dann, aber die Sense hat sich irgendwie verabschiedet, Neustart der Sense und des ganzen Host brachte keine Verbesserung mehr.

Veeam hat mir in Punkto pfSense nun schon mehrfach den Arsch gerettet, danke Veeam.

viragomann

Findet sich nichts im System-Log zu dem Vorfall?

Bei der Regel kann nicht viel schief gehen. Sie hat ein Interface angegeben, auf dem sie angewandt wird, ein Quell-Netz und eine Ziel-IP und -Port und eben die Interface-IP, auf die die Quell-IPs der Pakete transferiert werden.

Die Regel bewirkt hinterher für die pfSense, dass der Zielhost sämtliche Antworten wieder an die pfSense-IP adressiert anstatt direkt auf die Clients (was aber auch über die pfSense laufen würde) und diese setzt dann wieder anhand ihrere States die Ziel-IP auf die ursprüngliche Quell-IP um. Also möglicherweise ein klein wenig mehr Speicherbedarf, aber das kann doch nicht das Problem sein.

Bob.Dig

@viragomann Danke. Was ich noch heute gemacht hatte, eine virtuelle IP angelegt, ohne es wirklich zu verstehen, aber dann auch nicht groß was damit gemacht.
Das Log hätte ich mir wie ansehen können, in der Console? Oder mittels SSH auf die Link-local IPv4 Adresse verbinden? Hab die vhdx-Datei noch hier, aber Windows kann damit nix anfangen und ich auch nicht.
Gut, werde die NAT-Regel noch mal versuchen, Backup ist ja offensichtlich gegeben.

Habe jetzt die Regel noch mal weiter präzisiert und die Ports auf alle mir bekannten Ports erweitert.

Mein subjektiver Eindruck ist, dass die Clients langsamer starten als vorher, was vielleicht bedeuten könnte, dass zwar der eingebaute Test erfolgreich verläuft, aber noch nicht alles rund läuft...

Bis jetzt keine Auffälligkeiten was die Sense betrifft.

JeGr

@Bob-Dig said in Verbindungen über Netzwerkgrenzen hinweg:

Link-local IPv4 Adresse

was für Link local bitte?

logs ansehen

mit: clog <logfile>

Bob.Dig

@JeGr said in Verbindungen über Netzwerkgrenzen hinweg:

was für Link local bitte?

Na so was:
169.254.0.0/16

JeGr

Das ist APIPA nicht link-local. Sprich DHCP gescheitert, automatisch ne private Adresse vergeben. Heißt also effektiv nur, dass deine Kiste DHCP wollte und keine bekommen hat. Fände ich jetzt im ersten Moment bei ner Firewall eher komisch weil die außer ggf aufm WAN eigentlich kein DHCP Client spricht :)

Ansonsten auf Konsole in /var/log sich das Log mit clog system.log bspw. anschauen.

Bob.Dig

@JeGr said in Verbindungen über Netzwerkgrenzen hinweg:

Das ist APIPA nicht link-local.

Dann muss jemand mal den Wikipedia Eintrag anpassen. Ich vermute einfach mal, beides ist korrekt.
Deswegen, die Sense ist hops gegangen oder mindestens der DHCP-Dienst. Aber Backup hat den Tag gerettet, mal wieder.