[Sammelthread] pfSense & OPNsense (Firewall- und Routing-Appliance)

  • Ersteller Gelöschtes Mitglied 63700
  • Erstellt am
Ich habe gestern, mehr oder minder erfolgreich versucht opnsense in der neuesten Version auf meinem Dell Wyse in Betrieb zu nehmen. Nachdem ich dann den Treiber für den zusätzlichen Lananschluss aktivieren konnte lief das System.

Nun hab ich früher über die Fritzbox zwei Portfreigaben für 80 & 443 gehabt und das ganze über den Nginx Proxy Manager der in Proxmox als LXC lief abgefrühstückt. Die Domain liegt bei Netcup und ist dann aber bei Cloudflare hinterlegt.

Bei opnsense habe ich mich am Caddy Plugin versucht, nach der off. Anleitung - aber so richtig erfolgreich war es nicht. IP Aktualisierung in Cloudflare lief, aber die Weiterleitung an die LXC (Home Assistant & Vaultwarden) lief nicht (wobei ich nochmal verifizieren muss, ob es nicht vielleicht an Home Assistant selbst lag, denn als ich wieder auf die Fritzbox umgestellt hatte, lief erst auch nichts, erst als mir dann einfiel, dass ich in HA noch die Trusted Proxies anpassen muss :fresse: ).
In der Anleitung steht auch, das man die Client Headers auf Cf-Connecting-Ip setzen soll, damit konnte ich nichts anfangen.

Was nutzt ihr als Reverse Proxy?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Nutzt jemand von euch die Blocklisten von ipv64 ?
Die scheinen ja eine schöne Übersicht zu haben.

 
Fünf Monate alte Blocklisten, nein Danke. Q-Feeds ist schon sehr massiv, dann noch firehol level 1-4, GeoBlock und Suricata. Man kann das ewig so weitermachen, aber allzu viel bringt da eh nicht.
Besser selektiv erlauben, wenn möglich; nach Ländern, ISPs(ASN), DynDNS.
 
Zuletzt bearbeitet:
Sodele, ich hab jetzt eine gangbare Lösung für mein OPNsense-Neuaufbauen-Problem gefunden:
Workstation hängt nach wie vor an der Produktivumgebung, auf der Workstation ist eine VM in Virtmanager, an den ist eine Netzwerkkarte durchgereicht, die hat sieselbe IP wie der Host und hängt direkt am 10g port der neuen Firewall. Basic Setup ist durch, jetzt gehts an das neue Zeug, dem ich bisher ausgewichen bin (und was der Motivator für den Neuaufbau war...).
Gleich das erste Problem was neu ist: DHCP macht jetzt DNSmasq (mit dem ich mich noch gar nicht beschäftigt habe) und ich hab jetzt 4 Stellen an denen ich einen DNS-Server einstellen bzw. pflegen bzw. kontrollieren muss (dazu gleich mehr).
Was ich will:
  • Kein DNS Bleeding, alle meine Geräte nutzen NUR opnsense als DNS server -> Firewall
  • Kein IPv6
Die 4 Stellen:
  1. WAN settings
  2. DNSmasq Einstellungen
  3. Unbound einstellungen
  4. Firewall Einstellungen
Wie setz ich das denn jetzt am besten um?
 
DHCP macht jetzt DNSmasq (mit dem ich mich noch gar nicht beschäftigt habe)
Ich muss mal das Video raussuchen, das ich damals zur Konfiguration verwendet habe. Bin damals vom alten DHCP auf den DNSmasq umgestiegen. War gar nicht so schlimm, wenn man einige Dinge beachtet.

Ich hatte auch kein Bock mich damit zu beschäftigen, daher ist das bei mir komplett geblockt.

Hab mir extra einen DSL Anbieter mit echtem DualStack und ordentlichen Peering gesucht (O2) :fresse:
 
Gleich das erste Problem was neu ist: DHCP macht jetzt DNSmasq (mit dem ich mich noch gar nicht beschäftigt habe) und ich hab jetzt 4 Stellen an denen ich einen DNS-Server einstellen bzw. pflegen bzw. kontrollieren muss (dazu gleich mehr).

Nutze zwar Kea, aber wird mit DNSmasq ähnlich sein. Eigentlich trägt man im DHCP gar nichts bezüglich NS ein. Das hatte ich auch lange so gemacht. Hier auf der Labsense läuft jetzt unbound, und es wird nirgends mehr überhaupt irgend ein externer DNS eingetragen.
 
Ja hab den Fehler gefunden, die automatischen Regeln funktionierten nicht.
Habe das wieder auf Manuel gestellt und exakt die selbe Regel manuell auf dem WAN Interface gesetzt und es funktioniert sofort!

Anhang anzeigen 1216218

Ergo hat OpnSense recht, das man hier nicht die automatischen Regeln verwenden soll!
Nochmal zum Thema "automatische Regeln", diese scheinen allgemein auf dem WAN Interface nicht richtig zu funktionieren.

Hatte jetzt schon mehrmals den Fall, das die Blockregel von Crowdsec auf dem WAN Interface eine IP durchgelassen hat (welche auf der Blockliste steht), diese vom DNAT dann in die DMZ geleitet wurde, dort dann glücklicherweise von der automatischen Crowdsec Regel (mit der gleichen Blickliste) der DMZ geblockt wurde.
 
Eher unwahrscheinlich. Dafür müsste man sich die Regeln noch genauer ansehen. Wenn Crowdsec die OPNsense als Bouncer benutzt, dann dürfte es keinen Unterschied machen.
 
Tut's aber, werde später mal Screenshots anhängen
 
werde später mal Screenshots anhängen
Tu das. Wobei Du auch ein Problem mit einer automatischen, registered NAT Rule hattest. Hast Du deine Rules schon migriert? Vielleicht gibt es da noch ein Problem bei dir.
 
Zuletzt bearbeitet:
@BobbyD
Du hattest recht, das ganze läuft Schrittweise ab, sehr vewirrend:

1. Er lässt den Zugriff der bösen IP zu mit der NAT Regel auf dem WAN Interface
2. Er erkennt dann das es eine böse IP ist und blockiert dann danach auf dem WAN Interface.

Hier der Screenshot dazu (von unten zu lesen):
Bildschirmfoto 2026-07-10 um 20.52.48.png


Edit:
Ich habe eben echt den Livelogs für ne halbe Stunde zugeschaut, bis ich mal wieder so einen Fall hatte.
Crowdsec blockt bei mir gerade einfach alles weg 😅
 
OPNsense 26.7 released

26.7, nicknamed "Xenial Xenops", features interface assignments and gateway groups via MVC/API, firewall rules now defaulting to MVC/API, outbound NAT to source NAT migration assistant, captive portal IPv6 support, Kea DDNS/custom options/dynamic prefix delegation, FreeBSD 15.1, OpenVPN 2.7, PHP 8.5, Python 3.13, plus much more.

Migration notes, known issues and limitations:
  • The privileges "page-system-groupmanager" and "page-system-usermanager-addprivs" were merged into "page-system-groupmanager" and are no longer available separately. This was done to avoid the misconception that access to a user management page gives constrained rights to each page, but that is not the case. User management is a process involving all 3 pages.
  • The static PHP pages for firewall rule management have been moved to the "os-firewall-legacy" plugin which can be manually installed before or after the upgrade. All rules will continue to work regardless of the plugin being installed or not and are easily migrated using the given assistant.
  • Hyper-V guests may be producing panics on certain hosts with more than one virtual processor assigned. Make sure to snapshot beforehand and stay on 26.1.x until the situation is clear.
  • Since this is a major OS upgrade and OpenSSL changes from 3.0 to 3.5 third party repositories may interfere with your upgrade experience. Removing offending repositories and plugins may help; or wait for affirmation from the respective repository owners.

Screenshot 2026-07-15 125609.png

Läuft ;)
 
Zuletzt bearbeitet:
Läuft bislang alles gut - nur das gute, alte Mimugmail-Repo hat 26.7 noch verschlafen und klappt nicht.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh