@jegr Danke, ich hatte das Problem inzwischen im englischen Bereich klären können. Ich hatte noch eine aktiven portforward für die Ports drinnen, den ich längst vergessen hatte. Seinerzeit hatte ich nur die Firewall Regel deaktiviert, nicht aber das NAT. Und so war dann auch die Fehleranalyse erschwert, weil pfSense die Ports noch an einen Host durchgeleitet hat und ich entsprechend auf dem WAN dann keine für mich eindeutigen Ergebnisse hatte. Soll mir eine Lehre sein. Die Notwenigkeit eines OVPN auf TCP 443 ist aber auch nicht mehr gegeben.

@do3lk said in Feste IP Proxmox: @viragomann Das Problem habe ich mit der statischen ip auch bei meinem Rechner. Das spricht eher nach einem Problem mit deinem Setup auf der LAN Seite als dass es auf ein Problem mit der pfSense hindeutet. Sobald ich die IP Selber fest zuweise, habe ich kein Internet. Auch ein Zugriff auf die Pfsense ist dann nicht möglich. Dann vermute ich wie oben gesagt, dass deine Zuweisung falsch ist. Schreibfehler, falsche Netzmaske, irgendwas derartiges. Da du leider keinerlei Infos zu deinem Netz, deiner Konfig oder sonstwas gepostet hast, ist das aber Stochern im Nebel, da wir es so nicht erahnen können. @do3lk said in Feste IP Proxmox: Kann das sein das Pfsense bei Statischer IP die im bereich des DHCP Servers liegt den zugriff verweigert? Wie gesagt mit der Fritzbox als DHCP server gibt es keine Probleme. Nein, pfSense macht sowas im Normalfall nicht. Sonderfälle wie Captive Portal oder sonstige MAC Spielerei mal ausgenommen, ist es völlig egal welche IP dein Client hat. Sofern das Netzsegment korrekt konfiguriert ist und es Firewall Regeln gibt, die den Zugriff erlauben, lässt der Paketfilter auch rein was er rein lassen soll. Wenn du damit DHCP Probleme erzeugen würdest, gäbe das entsprechende Rückmeldung bspw. im System Log der Sense. Sowas wie "duplicate IP detected" o.ä. wird dann auffallen. Ich würde mir mal meine IP per DHCP am Rechner vergeben lassen, schauen ob ich dann auf die Sense UI komme und dann mal nachschauen, welche Werte mir die Sense vergeben hat im Gegensatz zu dem was du dir selbst vergibst. Und mal deine Regeln auf dem LAN checken - wenn es überhaupt das LAN ist und entsprechend Regeln dafür existieren? Cheers \jens

@viragomann Oh ja, pfSense WAN ist natürlich 192.168.178.2, weil es direkt von der Fitzbox kommt. Danke für den VLAN Link ! Das werde ich mir einmal in Ruhe durchlesen. Im Switch habe ich die Optionen gesehen und versucht zu verstehen, aber da fehlte mir doch das Verständnis, wie man eines korrekt anlegt und ein Gerät in so ein VLAN einbindet, das dann trotzdem wieder bei der pfSense / Fritzbox "rauskommt". Mein Sohn hatte AD und Benutzerverwaltung vor kurzem in der Berufsschule, das wollte ich Ihn dann einfach mal live ausprobieren lassen und natürlich mitwirken. Auf jeden Fall viel viel spanneder live am PC als nur auf dem Papier. :) Klar schießen wir hier gerade übers Ziel hinaus. Ich hatte mir das mit dem AP so gedacht, das ich Ihn einrichte (IP und WLAN Netz) und dann an den Switch oder die Fritzbox packe. Eben so, das das "interne" Netz (PC, TV, Konsole) nicht sichtbar ist. Der AP ist nur leider mit der passenden IP nicht "als WLAN" sichtbar am Switch. Konfigurieren kann ich ihn aber. Gateway und DNS sind eingetragen...aber ja, er soll ja nicht in "unser" Heimnetz hienein. Daher erstmal die Idee mit "direkt an die Fritzbox", da ich VLANs noch nicht einrichten kann. Danke für die Geduld und Denkanstöße. :)

Hallo zusammen Danke für eure Bedenken und die gut gemeinten Ratschläge. Ich habe es jetzt komplett neu aufgezogen und habe das alte Netz also gekillt. Mir ging es in dem Thread ja nur um die Frage ob man das Schrittweise umstellen kann. Das ist ja nun beantwortet -> In meinem Fall: Nein (oder besser gesagt: es ist sauberer wenn ich von vorn beginne). Die UniFi schau ich mir mal an. Danke und freundliche Grüsse

Blockregel 2 mach in gewisser Weise schon Sinn. Ich Blocke hier für alle DMZ Netze die den Alias WAN address für alles, nachdem ich DNS, NTP erlaubt habe, mehr brauchen die nicht. Ansonsten könnten DMZ Netze, wie Gast die eine any !RFC1918 Regel am Ende haben auf die WAN IP der Firewall voll zugreifen. Soweit mir das bekannt ist arbeite die pfSense wie folgt. Floating -> Interface Groups -> Interface Quick besagt nur, das sobald hier ein match gefunden wird das Paket an der Stelle nicht weiter sucht. Ansonsten arbeiten Floatings nach dem any Match Prinzip und nicht nach dem fist match. Das macht diese Regel etwas eigen in der Anwendung, aber auch zu einem sehr mächtigem Tool wenn man damit umzugehen weiß.

Es funktioniert. Vielen Dank an @micneu und @viragomann

@tigger1975 Freut mich, dass das endlich klappt. Bei SSL/TLS ginge auch CSO für mehrere Clients, wenn du einen breiteren Tunnel einstellst. Allerdings, wie oben erwähnt, ich rate zu getrennten Servern mit jeweils 30er Tunnel. Das schließt schon im Vorfeld einige Probleme aus und alles ist sauber getrennt und gut konfigurierbar. UND es erfordert nicht mehr Systemressourcen, was offenbar manche befürchten, UND OpenVPN Server Settings kann man in aktuellen Versionen einfach kopieren. Grüße

Ich habe mal hier einen Link gefunden: https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html Dieser Teil hat mir geholfen :) Automatic Fix The Bypass firewall rules for traffic on the same interface option located under System > Advanced on the Firewall & NAT tab activates rules for traffic to/from the static route networks which are much more permissive when it comes to creating states for TCP traffic and allowing it to pass. The rules allow any TCP packets regardless of their flags to create a state, and also utilize “Sloppy” state tracking which performs a less strict state match.

Es sind dann aber auch alle States der internen VLAN Kommunikation mit weg. Kommt hier scheinbar aber nicht zum tragen, da flache LAN Struktur. In dem Fall sehe ich eher eine Cold Standby als Zielführend an.

@be1001 Was @viragomann sagt. Man kann durchaus ein Gerät als GW eintragen, die Actions disablen und das dann zum Monitoren nutzen. Warum und weshalb kommt eben drauf an. Dauerhaft würde ich das da auch nicht nutzen, aber wenn man mal über nen Zeitraum bspw. nen Graphen braucht, wann die Kiste weg war oder ob die manchmal keine Antwort gibt, dann kann das helfen.

@nocling Ich schaue mir das bei Gelegenheit nochmal an. Speziell in den Logs hatte ich blöderweise nicht geschaut. Momentan habe ich an diesem Anschluss einen GL.iNet GL-AR300M der per OpenVPN reinkommt. Wollte aber gerne direkt an der Fritzbox die VPN Verbindung, dass wirklich alle angeschlossenen Clients ohne "Gefummel" der Verbindung nutzen können.

Der Grund für die Last ist gefunden. Auf den drei VPNs gab es einen Trafficshaper. Wenn man den deaktiviert geht die Last weg. Da das vorher nicht war ist das aber nicht die Ursache.

Ne Fritz kann aktuell nur IKEv1 Aggro Mode, P1: AES256 SHA512 DH2 :P2 ESP AES256 SHA512 DH2 und das auch nur über IPv4.

@tomnick said in IPV6, Pfsense und Fritzbox Problem: Hilft das weiter? Man, IPV6 nicht so einfach.... Bei mir kriegt pfSense einen 60er und braucht danach leider einen Neustart.

@njord said in PFSense auf Hyper-V: Und ja ich habe Erfahrungen mit Netzwerk und Virtualisierungen Dann kannst du uns ja verraten, wie das in HyperV technisch angebunden ist. So wie in deinem Netzplan dargestellt - ich nehme an, der HyperV läuft auf dem PC, müssten beide ja mit einem Switch oder einer Bridge verbunden sein. Dann müsste auch ein Zugriff vom PC möglich sein. Haben die virtuellen Netzwerkkarten auch ein MAC Adresse? Also verrät HyperV diese auch? Wenn ja, überprüfe mal, ob du das LAN am richtigen Interface konfiguriert hast, falls noch nicht gemacht. Mit dem arp Befehl kannst du auf der pfSense die MAC abfragen, wird aber, glaube ich jetzt, auch beim Zuweisen der NICs im Setup angezeigt. Hatte gestern auch von Sophos die XG Home Edition aufm Hyper-V hochgezogen Ich würde die Testkandidaten zum Vergleichen nebeneinander installieren, aber getrennt starten, und alle auf dieselben vSwitche hängen. Wenn alles okay ist, versuch doch einfach eine Neuinstallation. Beim Zugriff aufs LAN darf es eigentlich keine Probleme geben, wenn die Netzwerkkonfiguration in Ordnung ist.

Reboot tut gut.

@exordium Ne kein Problem, du weißt auch mein Augenzwinkern zwischen den Zeilen zu lesen Ich sage auch nicht, dass die 3.1-devel nicht noch an einigen Ecken ziemlich "rough" rüberkommt. Klar. Und dass es bspw. im CARP Betrieb eher suboptimal läuft. Auch da bin ich sofort dabei, weswegen ich schauen möchte, dass wir spätestens ab Januar für Anthony ne Testumgebung haben, auf der er selbst auch rumspielen kann um das besser zu machen. Sicher ist auch die Integration DNS Blocking, interner Resolver, etc. je nach Einstellung ruppig. Python mode hat da gerade was RAM Verbrauch und Integration angeht viel gebracht. Ich nutze es selbst minimal bis gar nicht, da tatsächlich oftmals DNS meist außerhalb der pfSense schon behandelt wird (bspw. AdGuard oder PiHole Installation schon vorhanden). Was wir aber vielfach nutzen und am Start haben ist die IP Blocklist Komponente und die läuft eigentlich auch ganz fein. Gerade - und das ist ein guter Punkt - wenn man wie du den default-auto-Regel-Block-Krimskrams abschaltet und statt dessen die Listen auf Alias Deny (oder Permit wenns ne Positivliste ist) schaltet und sich selbst Regeln baut. Einziger Punkt wo man stolpern kann was mir noch einfiel: Wenn man Regeln selbst erstellt, gibt es einen Hinweis, der gerne untergeht, weil der wirklich nur als Randnotiz irgendwo in den IP Lists in der Hilfe steht: When manually creating 'Alias' type firewall rules; Prefix the Firewall rule Description with pfb_ This will ensure that that Dashboard widget reports those statistics correctly. Do not prefix with (pfB_) as those Rules will be auto-removed by package when 'Auto' rules are defined. Quintessenz: als Beschreibung bitte was mit pfb_ reinschreiben, aber NICHT mit pfB_ sonst werden die ggf. rausgeworfen. Das könnte ggf. ein Grund sein, warum deine Regeln vllt. aufgeräumt wurden ;) Allerdings: inzwischen scheint mir der Hinweis eh nicht mehr zu stimmen, denn ich habe bei mir auf der Testkiste 2 Regeln drin ohne Description ohne irgendwas - einfach nur das Alias verwendet - und das wird im Widget inzwischen problemlos erkannt und angezeigt. Daher vllt. "Altlast" Cheers

@slu said in OpenVPN | net30 / subnet | Inter-client communication: It would be great if we could try that out in your lab. Tomorrow? Können wir gern heut abend durchspielen. VMs sind da, VPN ist schnell aufgesetzt und die Config schnell verteilt :)