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

  • Ersteller Gelöschtes Mitglied 63700
  • Erstellt am
Wozu neu installieren?
Hab ich beim TrueNAS auch so gemacht, habe ne PCIe-Karte mit zwei mSATA-Slots.
Die Karte einfach in das neue Gehäuse gesteckt, eingeschaltet, lief.
Hat sogar die Pools wieder gefunden, obwohl die jetzt an nem HBA und ner Backplane hängen, statt an den MoBo-Slots.

*sense ist doch auch BSD-basiert.
Von daher seh ich keinen großen Stress.
Die Interfaces einfach neu zuweisen (sofern die Netzwerkkarte nicht eh mit umgezogen ist) und gut.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Beim jetzigen Fujitsu-PC habe ich eine alte Intel SATA2-SSD verbaut.
Theoretisch könnte ich diese in die neue „TopTon-Box“ übernehmen – oder ich verbaue dort eine neue M2.-SSD.

Deshalb die Fragen rund um die Neuinstallation.
 
Partitionen clonen und probieren.
Ansonsten vorher Config backuppen (mit alles) und nach der Neuinstallation wieder einspielen.
Das dauert bei den *sensen auch nicht die Welt.
 
Partitionen clonen und probieren.
Wofür Clonezilla auspacken, wenn ne Neuinstallation mit Konfig einspielen viel schneller geht :eek:

Theoretisch kannst du die Config auch direkt vom Installer aus einspielen, zumindest bei pfsense. Wenn das Update mal nicht funktioniert hat, kann man mit der Config von der Platte direkt ne Neuinstallation durchführen.
 
Wobei die NIC Treiber passen sollten. Ich hab so viele Interface (über 20), dass ich mit dem "Assistenten" nie gut gefahren bin. Editiere daher lieber die Config der pfSense im Vorhinein.
Aber erst mal muss das Teil ja auch bei @hs_warez ankommen.
Beitrag automatisch zusammengeführt:

Mal zwei Fragen an die OPNsense-Gemeinde, ob dort folgendes zu Privacy-VPNs besser gelöst ist.
  1. Bei mehreren OVPN-Tunneln kommt es immer wieder vor, dass Tunnel die selbe IP (und das selbe Gateway) vom Anbieter zugeordnet bekommen. Die pfSense interessiert das nicht, trotz Gateway Monitoring. Letzteres signalisiert, dass alles ok sein, geroutet wird aber immer nur zu einem Tunnel, der andere kann nicht genutzt werden und muss erst händisch neugestartet werden.
  2. Einige Anbieter geben bei Wireguard von vorne herein nur noch eine einzige Tunnel-IP aus, Problem wie bei 1. Gibt es da einen möglichen Lösungsansatz? Einer wäre wohl VRF, dieses wird von pfSense aber nicht unterstützt.
Gibt es hier nennenswerte Unterschiede?
VRF ist für pfSense nicht geplant und auch sonst gibt es da wohl keine einfache Lösung. Ich könnte mir aber ein paar OpenWRT-VMs machen, für jeden Tunnel eine. :unsure:
 
VRF ist für pfSense nicht geplant und auch sonst gibt es da wohl keine einfache Lösung. Ich könnte mir aber ein paar OpenWRT-VMs machen, für jeden Tunnel eine. :unsure:
Die Frage ist eher, braucht man 2 Tunnel zum selben Ziel ?
VRF will man nicht, zumindest nicht mit non-professional HW. Weder BSD noch Linux können das ordentlich.
 
Wofür Clonezilla auspacken, wenn ne Neuinstallation mit Konfig einspielen viel schneller geht :eek:

Theoretisch kannst du die Config auch direkt vom Installer aus einspielen, zumindest bei pfsense. Wenn das Update mal nicht funktioniert hat, kann man mit der Config von der Platte direkt ne Neuinstallation durchführen.
Idealerweise steckt er nur die Platten um.
Die Anforderung "andere SSD" kam erst später. =)
Da ist neu insten und Config einspielen dann, je nach Größe, fixer.
Meine TrueNAS SSDs sind je 16 GB, die sind notfalls fix geclont...
Wobei es eher weniger 16 GB kleine m.2-SSDs gibt. :fresse:
 
Die Frage ist eher, braucht man 2 Tunnel zum selben Ziel ?
Wieso selbes Ziel? Es geht um Privacy-VPNs, da sollte jeder Tunnel ein eigenes "Ziel" haben. Hier wurde das Ganze mit MikroTiks RouterOS gemacht.
 
Wieso selbes Ziel? Es geht um Privacy-VPNs, da sollte jeder Tunnel ein eigenes "Ziel" haben. Hier wurde das Ganze mit MikroTiks RouterOS gemacht.
Und wozu brauch ich dazu VRFs ? Das kann ich mit pfSense indem ich mein Gateway auf den Tunnel umbiege. Ob ich nun das Interface dauernd in ein anderes VRF stecke oder eine FW-Rule ändere kommt doch aufs Gleiche raus ?!
 
Dann such ich mir eben einen Anbieter aus, der pro gewünschten Ausgangsstandort eben eine eindeutige IP besitzt ?
Wie machen die denn sonst die Unterscheidung, in welchem Land man nachher landet, wenn es nur einen Endpunkt gibt ?
 
@sch4kal Dabei geht es um die Tunnelnetze und deren config, auf die man leider keinen Einfluss hat. :-)
 
@sch4kal Dabei geht es um die Tunnelnetze und deren config, auf die man leider keinen Einfluss hat. :-)
Code:
[Interface]
# Key for test
# VPN Accelerator = off
PrivateKey = xxx
Address = 10.2.0.2/32
DNS = 10.2.0.1

[Peer]
# NL-FREE#21
PublicKey = xxx
AllowedIPs = 0.0.0.0/0
Endpoint = 190.2.130.161:51820
Die Endpunkte stehen doch in den "Tunnelnetzen" drin ?
 
Die Endpunkte stehen doch in den "Tunnelnetzen" drin ?
Es geht immer um die Tunnelnetze, nie um die Endpunkte. Die Tunnelnetze sind durch die allermeisten Privacy-VPN-Provider vorgegeben (IP/Gateway) und hier kommt es öfters (bei WG teilweise immer, je nach Anbieter) zu Doppelungen. Und damit kann halt *Sense nichts anfangen.

Ein Beispiel:
Screenshot 2022-09-06 180026.jpg

Das soll's dann aber auch zum Thema gewesen sein, OpenWRT ist die Lösung. 😉 Ganz Lustige betreiben virtuelle OpenWRT-VMs mittels bhyve inside pfSense.
 
Das soll's dann aber auch zum Thema gewesen sein, OpenWRT ist die Lösung.
Hab es jetzt tatsächlich so gemacht, 5 VMs mit OpenWRT (aber nicht in pfSense), darin jeweils einen WG-Tunnel zum Privacy-VPN-Provider.
Diese dann als Gateways mittels VLAN an die pfSense geführt.
Keine überlappenden Tunnel mehr... 😅
 
Update für Opnsense: neue Version 22.7.4


This update addresses more issues with the somewhat unfortunate phpseclib 3 migration. WAN IPv6 SLAAC mode now works more reliably and TLS 1.3 web GUI configurations will enforce the expectations by software clients regarding interoperability.

Last but not least the "assign VLAN parent and enable" migration note from 22.1 is no longer required as the boot will attempt to configure all existing hardware devices once with the selected defaults.
 
Uhm was hat dieser thread mit openWRT zu tun? Ich bin verwirrt...
 
Hallo!

Hab mich schon einige Zeit gewundert, warum meine "TrueNAS - cloud sync task uploads" so langsam sind.
Hab heute mal ein paar bekannte (Geschwindigkeit) Dinge (FTP-Upload, ...) probiert - überall das gleiche Problem.

Hab dann einen RTR-Netztest laufen lassen und es stellte sich heraus, dass mein Upload im Ar... ist.
Screenshot 2022-09-08 175525.jpg


Wollte dann schon verzweifelt Fehlersuche betreiben, bis ich entschied, einfach mal OPNSense + Modem aus/einschalten und dann mal sehen ...
Screenshot 2022-09-08 180038.jpg


Tja, war plötzlich wieder wie gewohnt.


Bin seit 2016 bei meinem Kabelbetreiber; habe anfangs kurz das Kabelmodem genutzt und dann eine Fritzbox => hatte nie Probleme.
Seit April nutze ich OPNSense statt der Fritzbox - Zufall, oder sind solche Probleme bekannt!?


Danke!

LG
 
Kabelmodem bei Vodafone im Bridge Mode macht nach einiger Zeit Probleme (packet loss), daher starte ich täglich neu (Zeitschaltuhr).
 
Läuft hier super.
Uhm was hat dieser thread mit openWRT zu tun? Ich bin verwirrt...
Ist doch Wurscht, ein Leserartikel gibt es hier auch nicht mehr... könnte man daher auch zum "freien" x86-Router-Thread machen, ich hätte nichts (mehr) dagegen.
Der Ressourcenverbrauch ist schon arg gering: 8-)

Screenshot 2022-09-08 210941.png


Kabelmodem bei Vodafone im Bridge Mode macht nach einiger Zeit Probleme (packet loss), daher starte ich täglich neu (Zeitschaltuhr).
Habe ich damals mit Kabel auch so gemacht, bis auch das nicht mehr half.
 
Zuletzt bearbeitet:
Kabelmodem bei Vodafone im Bridge Mode macht nach einiger Zeit Probleme (packet loss), daher starte ich täglich neu (Zeitschaltuhr).

Hm, ok - mal sehen, ob sich das Problem in nächster Zeit wieder einmal wiederholt!?
 
@hs_warez
Ich hab damals extra meine Bestellung storniert, da sich ewig nichts getan hat. Nur als Info.
Hab dann so eine Box bei Amazon bestellt. War kaum teurer und falls mal etwas sein soll, dann schlag ich mich lieber mit dem großen A rum.

Hallo!

Kleines Update: Am MO bestellt und seit heute am Versandweg - mal sehen.

LG
 
Evtl. wollten die mich auch nicht beliefern :d
 
Evtl. wollten die mich auch nicht beliefern :d

Wird wohl doch nix - haben plötzlich eine UID-Nummer gebraucht und meinten dann, man könnte den Kauf auch außerhalb abschließen ...
Hm, hab jetzt mal storniert - Geld kam schon retour.
 
Moin,

hab da eine Frage zu HA, DHCP und WireGuard...

Erstmal mein Setup
Ich habe einen Glasfaseranschluss mit 5 öffentlichen IP Adressen
X.X.X.226
(X.X.X.227)
X.X:X228
X.X.X.299
X.X.X.230
dazu 2 OPNSense Maschinen, als HA Cluster konfiguriert und eingerichtet, eine nutzt die .226, eine die .230 als WAN Adresse.
Die .227 wird von einem externen Dienstleister mit einem eigenen Gerät genutzt und kann nicht verwendet werden.
Die .228/29 und .229/29 sind als CARP Adresse angelegt und das funktioniert soweit auch alles wie es soll, auch im Fehlerfall. Ich hab mich weitestgehend an diese Anleitung gehalten, falls das wichtig ist: https://www.thomas-krenn.com/en/wiki/OPNsense_HA_Cluster_configuration

Zu meinem Problem: ich hab auf OPNSense1 (das war die ursprüngliche einzelne Firewall bevor ich die HA Lösung implementiert habe) WireGuard am laufen, das funktioniert auch einwandfrei.
per XMLRPC wird das auch mit Endpoints, Clients etc an die Backupfirewall gesendet.
Eingehend wird in der aktuellen (funktionierenden) Config WireGuard auf der .226 angesprochen. Ich würde jetzt natürlich gern die .228 nehmen, da hochverfügbar. Ändere ich jetzt am Clientconfig die IP... passiert nichts, keine Daten fließen durch den Tunnel.
Die Firewall Regel ist prinzipiell auf destination WAN Address gesetzt, ich habe versuchsweise eine 2te auf die .228 Adresse direkt eingerichtet
1663248815872.png

Macht aber keinen Unterschied.
Was übersehe ich?

Zweites Thema, ich habe noch die Schnittstellen opt1-3, opt3 ist mein Gästenetzwerk mit dem Adressbereich 192.168.1.0/24
Aktuell ist es so: FW1 hat die IP 192.168.1.1 und stellt den DHCP Dienst im Range 192.168.1.5 - 192.168.1.250 bereit.
Plan ist es: FW1 kriegt die 192.168.1.252, FW2 die 192.168.1.253 und CARP auf dem opt3 Interface 192.168.1.1
Lege ich das so an, geht auch alles und das Interface wird korrekt angezeigt, lässt sich anpingen und Internet geht darüber auch.
DHCP ist so eingestellt, dass die .252 die FailoverIP .253 hat und umgekehrt. Aber: der DHCP Dienst vergibt keine IP Adressen mehr. Die Logs zeigen leider nichts an was für die Fehlersuche hilfreich ist. Wie gesagt: mit fixen Adressen funktioniert alles, auch an den Clients - ich kriege halt nur keine DHCP Leases...
Stelle ich alles auf Anfang (also nehme FW2 opt3 aus dem Netz und stelle FW1 auf das Ursprungssetup) geht DHCP wieder.
Wahrscheinlich ein Problem direkt vor meinen Augen :-D

Danke für die Hilfe
 
Proxy Server?

Irgendwie verstehe ich es nicht ganz!?

Derzeit läuft OPNSense mit unbound+Adguard - macht es Sinn, hier noch einen Proxy-Dients laufen zu lassen!?


Danke!

LG
 
Aber woran? Habe eigentlich nicht viel geändert, außer Blocklist und GeoIp und die aktualisieren sich nur 1x am Tag.

Kann es vielleicht sein, dass der Hänger an der verbauten SSD liegt?

Wie kann ich denn rausfinden was er da alle 1-2 Min. als Aktivität macht?
 

Anhänge

  • FW.jpg
    FW.jpg
    117,7 KB · Aufrufe: 84
Sehe gerade, dass pfSense mutiger wird was aktuelle Software angeht: Sprung von FreeBSD 12 direkt auf FreeBSD 14!


We are moving the version of PHP used by pfSense® software to PHP 8.1. We have also taken a decision to move the base operating system version of FreeBSD used by pfSense software from 12-STABLE to the current development “top of tree” version also known as “main”, or “HEAD”, and, at the time of writing, “14-CURRENT”.
 
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