Die GUI erreichst du also noch nicht. @Mansaylon said in Console / Installation Auflösung: Dazu kommt noch, dass in der Shell das US-Keyboard gültig ist und ich eine Schweizer Tastatur habe (obwohl ich bei der Installation die richtige Tastatur angegeben hatte). Das Problem kenne ich. Ich würde es aber dennoch damit versuchen. Ein passendes US Tasturlayout sollte im Netz zu finden sein. Dann weißt du, welche Taste du benötigst. Im Grunde geht es ja nur um die beiden Zeichen ">" und "", die anderen Tasten zugeordnet sind, jedenfalls entgegen dem deutschen Layout. VI wäre da wohl auch keine große Hilfe, denn die einzige Zeile im File steht AFAIK auch ganz unten. @Mansaylon said in Console / Installation Auflösung: Versuchte auch mal über das Bios den Boot-Vorgang über UEFI auszuschalten... bootete dann einfach nicht mehr. Soweit ich weiß, erfordert das eine Neuinstallation. Das könnte aber auch die Lösung für das Anzeigeproblem sein.

@Klaus2314 said in Prozesse bei 99% Memory usage beenden: Man kann also sagen, dass wenn eine laufende pfsense mit pfblocker bei 50% RAM liegt, dann bloß nicht rebooten? Nein weil nicht nur pfblocker im RAM läuft. Zudem holt sich das OS selbst auch RAM für FS Caching und Co wenn was zu holen ist. Man kann da nicht pauschal urteilen.

@unique24 said in Loggen von allen Zugriffen von außen: Es soll also nur er Initial Request (oder wie man das bezeichnet) protokolliert werden. Dann ist "Dauer" quatsch. Wenn nur der Syn / Handshake geloggt wird, wie willst du dann die Dauer messen? Wenn das sowieso nur um Ports/Traffic geht, der eh zugelassen ist und damit Statistik, dann mach ne Auswertung über Softflows. Softflowd draufmachen, Interface auswählen, Flows an Collector schicken, Profit :) Alternativ alles auf der Sense mit ntopng ggf. auslesen/basteln

@Bob-Dig said in Internen Traffic über NAT zurück ins LAN leiten: Kann ha proxy eigentlich auch funktionieren, wenn SNI verschlüsselt ist und kein offloading genutzt wird? Wenn SNI WIE verschlüsselt ist? Momentan gibt es AFAIK nur eine Variante SNI zu verschlüsseln und das ist ESNI. Wenn die Komponenten ordentlich ESNI sprechen, alle Komponenten APIs aufgerüstet sind und SplitMode ESNI läuft, sollten auch LBs gehen.

Moin, so, einstimmiger Beschluss: Kein Debugging, eventuell stelle ich das Szenario später nochmal nach. Jetzt wird eine pfSense hinter die Fritte gehängt weil der VPN Tunnel nur für ein Gerät nötig ist und das dann auch noch vom dortigen LAN abgetrennt werden soll. Warum man sich nicht gleich ausködelt... -teddy

Hi Ja zugegeben - das ist schon eine heftige Auslastung so - dennoch bin ich eigentlich (warum auch immer) davon ausgegangen dass die APU Dinger zumindest 400Mbit schaufeln können ohne dass es zu einbußen auf den anderen Ports kommt. ich habe heute noch ein wenig gegoogelt und das ganze scheint sich auf die 4C4 zu verdichten - hier ist laut einem Thread ein spezieller INTEL Chipset verbaut der in Verbindung mit BSD probleme macht und nur begrenzt Leistung liefert (offenbar nicht unter linux) Jedenfalls hat sich mein Bild von den APU´s jetzt gerade etwas verrückt - und nein - ich will nix geschenkt - dennoch machten die bisher einen wirklich guten Job - so langsam erklärt sich aber auch das ein oder andere bisher nicht erklärliche Verhalten das ich beobachtet habe ...

Ja kann sein. Ich lass es jetzt erst mal so. Ist eh der einzige Port den ich an der FB nutze und es gibt 3 weitere. Won't fix it if it ain't broken.

Late reply, aber ja es waren RAM Issues - Dual Channel Mode hat mit den verwendeten RAM Riegeln nicht sauber funktioniert..

Hallo, nach weiteren Updates in den letzen Tagen wird die Verbindung seit gestern wieder hergestellt und das ohne die kleinste Änderung an der Konfiguration. Der einzige kleine Schönheitsfehler der noch geblieben ist, ist das die beiden Tunnel im Status noch als nicht verbunden angezeigt werden. Vermutlich verschwindet dieser Anzeigefehler dann noch mit einem der nächsten Updates. Gruß Robert

@Rico Danke Rico! Ja Du hast Recht: [image: 1601460251085-bildschirmfoto-2020-09-30-um-12.03.41-resized.png] Ist da der Wurm drin oder ist das quasi normal? Danke nochmal! K.

@Michael9876 Bei pfSense gibt es ja öfters verschiedene Wege zum Ziel, schwierig das nun zu bewerten. Einige der Punkte, die Du ansprichst, kannst Du ja selbst testen, wie z.B. funktioniert dein VPN-Killswitch überhaupt, wie ist das Ergebnis, wenn Du einen DNS-Leaktest aus dem Web nutzt, etc. Ich kann für mich sagen, dass ich noch kein Outbound NAT nur für einen einzelnen Port machen musste und dass ich meinen VPN-Killswitch via tagging umgesetzt habe. Für DNS nutze ich DNS Query Forwarding mit SSL/TLS im Resolver, also mein ISP sieht da eh nichts, oder ich vergebe den DNS-Server direkt über DHCP, was dazu führt, dass der betreffende Host die Verbindung zum DNS-Server automatisch über die VPN-Verbindung herstellt. Die DNS-Server meines VPN-Providers nutze ich wiederum nirgends, weil mir zu lahm und letztlich überflüssig.

@JeGr said in APU2C4 und IPv6: Nach deiner Auflistung: Vielleicht liegts auch an deinem Windows 10 PC? Danke noch mal für deine Hilfe JeGr. Das Problem lag tatsächlich an Windows 10 PC. Habe jetzt ein Funktionsupdate drauf gespielt, seitdem läuft IPv6 ohne erkennbare Probleme.

@Bob-Dig Vielen Dank für die Info:) @viragomann Netz habe ich soeben geändert auf /8. Ich werde das nacher nochmal tracern und so versuchen. @JeGr Ops, mein fehler habe ich wohl das falsche Bild hochgeladen, hab den überblick verloren von den ganzen Printscreens xD.

Ich würde ggf. versuchen statt untagged/tagged zu mixen einfach nur tagged zu sprechen auf einem physischen Interface - da bin ich pingelig und mag es lieber ordentlich. Aber geht natürlich beides.

@Wireguard said in Teilweise falsche Zeitangaben: in Grunde waren alle Logs von der Zeit her falsch. Ich habe die pfSense mal neu gestartet, nun passen alle Zeiten wieder. Echt seltsam.... Wahrscheinlich umgestellt und danach nicht neu gestartet, dann werden Syslog Server etc. nicht neu durchgeladen und haben nicht die aktuelle Zeitzone drin. Wichtig auch drauf zu achten, dass DHCP in GMT gezeigt wird (Lease Time), das kann man im DHCP Server selbst aber umschalten (Checkbox für local time reinmachen).

Am besten mit einer Block-Regel. Ich nehme an, dass die betroffenen Geräte dennoch mit anderen internen Adressen kommunizieren können sollen. Dann dürfen diese Zugriffe nicht geblockt werden. Bewährt hat sich hier, einen Alias zu erstellen, der sämtliche RFC1918 Netze enthält (andere verwendest du intern hoffentlich nicht). Dann eine Block-Regel erstellen, mit Protocol = any, Source = <das gewünschte interne Subnetz>, Destination = "invert." angehaken und den RFC1918 Alias als Ziel eintragen. Diese Regel blockt dann alles außer RFC1918 Adressen und passt auch noch, wenn du an denen internen Netzen etwas änderst. Bedenke wie immer bei Firewall-Regel, dass Floating-Regeln oder welche auf Interface Gruppen Prio vor Regeln auf Interfaces haben.

@Fredd Gerne! Muss ja was gegen diese doofen Gerüchte tun, dass es immer heißt, hier wären alle so ernst, belehrend und unfreundlich ;)