Die Feeds sind vom pfBlockerNG Autor gepflegte "one-click" Lösungen, damit man fürs erste Aufsetzen schnell ein paar brauchbare Listen zusammen hat. Du kannst in dieser Ansicht nicht selbst irgendwas hinzufügen oder löschen. Wie gesagt, sind das lediglich Templates. Was du in deinen eigenen Listen aktiviert hast ist das Einzige was für die Installation bzw. den Service relevant ist. :)

OK, ist das ein Business Anschluß von UM? Und ist der umgestellt auf echtes Routing? Soweit das bei unseren Kunden in BW der Fall ist, war nach Umstellung über das Kundencenter der eigene Adressraum als /28 oder /29 Netz definiert mit einem Gateway und den anderen IPs als freie Vergabe. Wenn das der Fall ist, kann hier sauber CARP eingerichtet werden (1 IP pro Firewall und eine dritte als HA IP + alle übrigen IPs als Alias der HA IP). VG Jens

Danke für Deine Antwort. Entschuldige meine späte Rückmeldung, aber es hat doch länger gedauert als vermutet, bis ich mir ein genaueres Bild von der aktuellen Situation machen konnte. Leider dauert es noch etwas länger bis zur Umsetzung. Ich melde mich daher später ggf. nochmal an dieser Stelle zurück. Bisher sind zu viele Variablen ungeklärt, sodass die Spekulationen vermutlich nicht zielführend sind. Also erstmal: Danke und bis später! ;)

@vigeland said in auf einer Seite Kable IPv6, Site2Site möglich?: Nicht sehr freundlich. Thema ist "IPv6, Site2Site möglich" und genau um das Thema geht meine Frage und darum das keine Packete auf der einen Seite beim Aufbau ankommen. Nein er hat dich korrekt darauf hingewiesen, dass Thread-Hijacking - also das Reingrätschen in andere Themen mit dem eigenen Problem - nicht freundlich und OK ist. Zudem hat er vollkommen recht, egal was im Thema steht, im Thema des OP steht ganz klar, dass er hier mit OVPN arbeitet. Dann kann ich nicht mit einer vollkommen anderen Konstellation, die ganz andere Komponenten benötigt zwischenrein grätschen und verlangen, dass ich jetzt gerne mein Problem gelöst haben möchte. Das ist wirklich nicht die feine Art und jede Netiquette weist da gern drauf hin. Zumal @Rico im Wording absolut korrekt und freundlich war mit Bitte und Danke. Neues Thema ist da der richtige Weg und jeder der kann wird dann auch gern dort helfen. @pixel24 noch als Zusatz: Wenn die Seite der Freudin DSlite hat mit v6 würde ich tatsächlich eher mal versuchen, den Tunnel selbst schon mit IPv6 zu bauen - sofern dein Glasfaseranschluß v6 bietet. Denn wir haben da u.a. auch bei Kunden und Kollegen bei VPN dann gern das Problem, dass die MTU durch das DSlite so vermurkst wird, dass der Zugriff ziemlich ätzend wird. Wenn man das direkt via OVPN und IPv6 als S2S aufbaut, kann man aber trotzdem intern IPv4 mit IPv4 verbinden - egal wie sich Server und Client gefunden haben. Damit hat man dann keinen MTU Salat und intern trotzdem eine v4 an v4 Site2Site Kopplung :)

@reventix-GmbH said in [2.4.5] Kann keine User mehr anlegen: Benutzer der Gruppe "admin" konnten das nicht. Das war wohl ebenfalls ein Problem mit der Konfiguration, normal ist das nicht - nur sollte das angenommen worden sein.

Intel Core i7-7700 pfSense 2.4.5-RELEASE AES-256-GCM 519 Mbit/s AES-128-GCM 522 Mbit/s AES-256-CBC 477 Mbit/s AES-128-CBC 479 Mbit/s -Rico

Hab inzwischen auch mehrere (Sub-)Netze und heute alles ein wenig umgestellt. [image: 1586517147494-gfdsgfd.png] PS: Jetzt wo ich mir so meinen post angucke, fehlt mir noch eine IPv6 Regel für die VPNer. PPS: Weiter drüber nachgedacht und ist doch nicht nötig, da ich den betreffenden Hosts eh IPv6 entzogen habe, weil es anders nicht zuverlässig geht in meinem Setup. Hier, vermute ich, limitiert einfach pfSense, was das Management von IPv6 angeht.

pfBNG Habe ich entfernt - bringt leider nix. Es scheint wirklich nur für .intra-Domains zu geben...

OK das Problem hat sich wohl selbst gelöst, warum kann ich nicht nachvollziehen denn hab nichts geändert

dumdidum Fehler gefunden . Zählweise der Ports ist bei den Karten entgegengesetzt, weil eine Karte auf dem Kopf eingebaut ist. VG gabylein

Moinsen inciter, Danke für deine Antwort. Nein, ich nehme dir das nicht übel, warum sollte ich? Du hast doch konstruktiv auf meine Frage geantwortet, alles gut!! Ich werde (entgegen deiner Empfehlung) jetzt zunächst alles so belassen. Die seltenen temporären Ausfälle haben nochmal deutlich nachgelassen (seit 24 Stunden keine Ausfälle mehr) und die Konfig fand ich eigentlich so ganz sinnig. Bevor ich unbound auf dem Raspi installiert habe lief es genauso so (aber mit stubby) problemlos seit ca. 1, 5 Jahren. DHCP macht pfsense, im General Setup ist die IP des Raspi als DNS Ansprechpartner hinterlegt. Jetzt, da alles wieder rund läuft (musste sich vermutlich erst alles setzten), habe ich keinen Grund alles umzustoßen... Für deinen Input bedanke ich mich trotzdem und an alle: passt weiter gut auf euch auf und bleibt gesund! Grüßle theother

Hallo! @achim55 said in Pfsense nur als VPN nutzen: wo schon der DHCP über einen Alcatel Router läuft. Der VPN Server sollte auf dem Router laufen, ansonsten wird es kompliziert. Grundsätzlich möglich ist es aber. @achim55 said in Pfsense nur als VPN nutzen: Die Pfsense würde ich mit dem WAN und LAN Port ins Lokale Netzt hängen Aber nicht so! Niemals mehrere Interfaces in ein Netz hängen, abgesehen von LAGG oder Bridge. Wofür auch? Reicht doch, wenn ein das LAN im Netz hängt. Abgesehen vom Vorschlag von @Rico fallen mir noch weitere Lösungen ein: die komplizierte: Hat @Rico schon angedeutet. Die pfSense hängt im LAN, VPN-Port ist dahin geroutet. Du setzt auf jedem Gerät, das du via VPN erreichen möchtest eine Route für das Access-Server Tunnelnetz. Die Route könntest du auch per DHCP verteilen, allerdings denke ich nicht, dass der Alcatel dazu fähig ist. die perfekte: Voraussetzung ist, der Router kann mehrere interne Netze routen. So kannst du zwischen Router und pfSense ein Transitnetz einrichten, routest die VPN zur pfSense und setzt nur auf dem Router eine statische Route für das Tunnelsubnetz des VPN-Servers zur pfSense. die schmutzige und auch einfache: Die pfSense hängt im LAN, VPN-Port ist dahin geroutet. Du konfigurierst das Outbound NAT so, dass die Quell-IP in Paketen die von der VPN kommen und ins LAN gehen auf die pfSense LAN-IP umgesetzt wird. Damit kommen die Response-Paket ganz von selbst wieder zur pfSense zurück. Nachteil: Für die Zielgeräte im LAN sieht es aus, als würden alle Pakete von der pfSense kommen, einem LAN-Gerät, dem sie vertrauen. Daher würde ich das nur umsetzen, wenn ich jedem VPN-Client absolut vertraue. Üblicherweise trifft das nur auf mich selbst zu. Also wenn die VPN nur für mich ist. Grüße

Dann hält die FB, durch ständige "Anfragen" die Ports offen.

Danke, danke. :) Tip von @Rico brachte die Lösung Verify that the defined WAN gateway is actually the default (Diagnostics > Routes) Some other source such as a VPN may have changed the default gateway Es war kein Standardgateway gesetzt. Das wars, voll der Anfängerfehler. Problem behoben, danke an Alle.

@kawaklx650 said in PfS Verständnis Allgemein: Dabei ist auch wichtig zu beachten, dass die Antworten ebenfalls erlaubt sind. Wenn LAN4 zwar auf LAN1 zugreifen darf, LAN1 aber jeglichen Traffic zu LAN4 zu blockieren hat, wird sich das beißen. Das ist Unsinn! Die Filterregeln der pfSense erlauben immer das Initiieren einer Verbindung. Für Antwortpakete ist der Weg dann automatisch offen. Also es ist durchaus möglich, von LAN1 jeglichen Traffic, alle Zugriffe auf LAN4 zu erlauben, von LAN4 nach LAN1 aber alles zu blockieren. Ansonsten wäre das eine schlechte Firewall. Was allerdings auf der Synology die Funktion "mehrere Gateway´s benutzen" macht, weiß ich nicht. Dass es damit funktioniert, würde für mich auf asymmetrisches Routing hindeuten. Um das zu untersuchen bräuchte es aber mehr Informationen. Grüße

Wenn du die default Regel nutzt und da den Limiter aktivierst gilt das natürlich für alle. Korrekt wäre eine Regel mit Limiter und den betreffenden IP Adressen (als Source) ÜBER der default Regel zu erstellen. -Rico

Jup, manchmal ist es einfacher als befürchtet. -Rico