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

  • Ersteller Gelöschtes Mitglied 63700
  • Erstellt am
Einen Webserver wie Nginx oder Apache kann ich ähnlich sicher konfigureiren wie den Reverse Proxy, Zumindest wenn ich den nicht über den Container einfach in die Wildbahn werfe.
Ob ein Nginx oder HA-Proxy Sicherer ist, als die Appliaktion dahinter ist eine Frage was dahinter läuft bzw. welche Security Featurres auf dem Proxy konfiguriert sind. Vor Fehlern in der Applialkton hilft der Proxy wenig, genauso wie druch seine blose Anwesenheit.

TLS Terminierung auf dem Proxy kaufe ich, das ist Komfort.
Fail2Ban auf Reverse Proxy ist die Frage woher die Events kommen bei denen gesperrt werden soll. Die Events landen ja in der Regel hinter dem Proxy oder nicht? Ja kann man machen, ist aber glaube nicht ganz Trivial.
Crowdsec kannte ich nicht. Sieht für mich nach IDS/IPS aus, richtig? Sollte die Sense auch ohne Proxy bieten können
Welche Kontrolle ermöglich ein Reverse Proxy mehr als die Sense selbst? Mir Fällt da nur vorgelagerte Authentifizierung ein bzw. das ich zentral Pflegen kann wer rein kommt.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also ich habe alles per VLANs getrennt.

Access-Points, Cameras, Management, Smarthone, IP Telefone.......


Ist ja eigentlich schnell gemacht.

Zum Beispiel dürfen die APs nur mit dem Management Controller reden und die Radius Server anfragen.

Sonst dürfen die nichts.

Bei den Kameras genau das gleiche.
Kein Internet bis auf SMTP auf den Strato DNS Eintrag.

Sonst nur intern auf die Aufnahmegeräte.

Genauso das Smart Home Zeugs....
Darf nur HTTP, HTTPS in Internet und finden sich untereinander nicht, weil isolierte SSID.

Also man kann schon sehr viel machen.

Alles natürlich mit Blocklisten und GeoIP Einschränkungen.
 
Tatsächlich hauptsächlich wegen der TLS-Terminierung, damit ich dahinter mit selbstsignierten Zertifikaten arbeiten kann, die *etwas* länger haltbar sind, als die LetsEncrypt-Zertifikate.
Danach für Zugriffe auf Services auf verschiedenen internen VMs via Subdomains unter HTTPS.
Außerdem wird so nicht der nachgelagerte Host selbst exponiert, sondern nur der RP.
Ein Angreifer sieht also zunächst mal nur den RP als Endpunkt, kann also nicht so leicht auf vorhandene Sicherheitslücken auf den nachgelagerten Servern schließen.

Ja, RP fluppt leider nur mit Webservern, dafür aber ziemlich zuverlässig.

Und zuletzt, Verfügbarkeit und Lastausgleich (jaja, im Home =) -> Luxx).

Wenn ich wüsste, wie, würde ich den gesamten Mailverkehr auch über den Proxy jagen, damit die Mailkuh nicht mehr direkt am Netz hängen muss...
Das ist derzeit meine einzige offene Baustelle...
 
Danke für die Erklärung. Das mit den SSL Zertifkaten ist auf jeden Fall ein Vorteil. Wobei ich dahinter Teilweise auch nur HTTP nutze, aus Faulheit bzw. unwissenheit wie ich die selbst signmierten Zertifkate korrekt hinterlege.
Die Applikation ist trotzdem exponiert und kann angegriffen werden. Unterscheidet sich in meinen Augen nicht viel on einem einfachen Port Forwarding zur Applikation, ausser dass man den Server Fingerprint der Applikatin nicht sehen kann.
Was nutzt du als Reverse Proxy?

Nginx kann auch TCP und UDP Streams als Proxy bedienen, wie das geht weiß ich nicht.
Die Nginx Doku für nen Reverse Mail Proxy sieht gar nich so schwer aus. Ob das mit der Sense geht weiß ich nicht. Oder Alternativ das Proxmox Mail Gateway
 
Muss ich mir mal ansehen, falls ich mal wieder Zeit dazu finde, der Mailserver muss halt funktionieren, da er inzwischen ganz gut in unser Leben integriert ist (Aliase für alle möglichen Shops, offizielle Kommunikation mit Kiga, Steuer, etc.).

Nutze nginx auf der OPNsense.

Mit der größte Vorteil ist, dass man mit dem RP auf Portnummern verzichten kann und alle HTTP/S-Zugriffe über URLs oder Subdomains steuern kann.
Somit muss man bei mehreren Webdiensten nicht mehrere Ports aufmachen, auf 443 kann ja normal nur ein Dienst weiter geleitet werden.
Wenn ich jetzt Nextcloud, SoGo (Mail WebUI), Wiki, Grafana und Gitlab auf verschiedenen Ports raustelefonieren lassen müsste, würde ich ja nur sinnlos neue Löcher in die Firewall bohren.
Das ist der - für mich - erhöhte Sicherheitsgewinn.

Selbstsignierte Zertifikate erstelle ich auch auf der OPNsense und exportiere dann Zertifikate und Schlüssel von da.
Da liegt dann auch die CRL.
Also nix mit händisch openssl bedienen und so.

Umbenennen in cert.pem und privkey.pem, dann in die VMs in /etc/ssl/ kopieren (nutze Debian), Rechte setzen und dann fluppt meistens schon viel automagisch.
In Webmin kann mans auswählen, im nginx (hier als Webserver) einfach die certificate-optionen ändern (hab dafür nen snippet, das einfach in die virtuellen Webserver inkludiert werden kann).
ESXi ist stressiger, da muss man den Kram in rui.crt und rui.key irgendwo per SCP rauf kopieren, dann klappt das aber auch da.
Bei TruNAS einfach den Inhalt der .pems in die entsprechenden Fenster kopieren und zack, gehts auch da.
Hab ich was exotisches vergessen? =)

Einzig für Mail braucht man den Kram samt der CA in der richtigen Reihenfolge in der cert.pem, sonst zicken manche Mailserver rum...
Browser zicken manchmal auch rum, aber denen kann man das selbstsignierte CA-Zertifiakt auch als vertrauensvoll unterschieben, dann hat man auch wieder sein grünes Schloss. =)

In 2022 gibts keinen Grund mehr, auf TLS zu verzichten. =)
 
Jetzt habt ihr mich komplett abgehängt 🙃 So wirklich weiter bin ich jetzt noch nicht, da ich vllt 25% nur von dem verstanden hab von was ihr gesprochen habt.
Das mit nginx auf der OPNsense verstehe ich so halbwegs, müsste mich dann halt mit der Umsetzung beschäftigen.
Macht nun ein RP VLANs obsolet, oder ist das eine zusätzliche (notwendige) weitere Sicherheitsstufe? Wie hoch ist der tatsächliche Aufwand, wenn es einmal eingerichtet ist und wie hoch ist die Fehlerquote? Frauen mögen nicht, wenn das Internet nicht mehr funktioniert 🙃

@Hipiman
Genauso das Smart Home Zeugs....
Darf nur HTTP, HTTPS in Internet und finden sich untereinander nicht, weil isolierte SSID.
Wie meinst du das mit finden sich untereinander nicht, weil isolierte SSID? Es bekommt doch nicht jedes Smart Home Gerät eine eigene SSID, die sind doch z.B. unter IoT vereint und könnten sich dann theoretisch untereinander sehen?
 
Komplementär.

1. Mach auf jeden Fall VLANs für
- Gäste
- IoT
- Mediengeräte (TV)
2. Wenn Du keine Dienste ins Internet stellst, brauchst Du keinen RP.
3. VPN dürfte sicherer sein als RP, wenn nur Du + Frau zugreifen müsst.
4. Also: erstmal VLANs machen und keine Ports öffnen.
 
Dienst nach draußen wäre im Moment glaub nur Nextcloud.
Haussteuerung von außen über VPN, müssen ja, wie du richtig gesagt hast, nur meine Frau und ich drauf zugreifen.
 
Wenn du eh schon nen VPN rein hast, musst du Nextcloud nicht auch exponieren sondern kannst es darüber laufen lassen.
Es sei denn, die Schwiegereltern müssen da auch drauf.

Der RP ist tatsächlich primär ein Komfortgewinn.
Sorry für die widersprüchliche Aussage von mir.

VLANs sind essentiell, aber dann auch drauf achten, dass zwischen den VLANs nur gewisse Ports kommunizieren dürfen (Firewall!).

Bei den Accesspoint-Einstellungen kann man (zumindest bei Mikrotik) einstellen, dass die Clients isoliert werden, so können sie sich untereinander nicht sehen.
Denke, das meint Hipiman.
Diese Einstellung greift pro SSID.
Habe ich beim Gäste- und IoT-WLAN auch an, beim normalen hingegen nicht.
 
Dann Nextcloud ins Gäste VLAN - clients können zugreifen, aber ein kompromittieres Nextcloud kann nicht deine PCs angreifen. (Vereinfacht gesagt!)
 
Warum sich einschränken?
Ein Service-VLAN, ein Gäste-VLAN und das normale VLAN.
Ins Service-VLAN alles, was an Services zur Verfügung steht.
Dann nur die Ports zw. den VLANs aufmachen, die tatsächlich benötigt werden (53 DNS (pihole), 443 HTTPS, der Port für die Wolke (sofern ned auf 443) etc.
Für Casting dann den ganzen IGMP-Kram zw. den VLANs zulassen.
Und Gäste haben in der Wolke nix zu suchen, die dürfen genau mit 53, 80, 443 und den paar Mailports ins WAN.
 
Wenn du nicht gerade FritzBox Repeater verwendest, kannst du einiges einstellen.

Zum Beispiel WPA2/3 Enterprise mit Radius Authentifizierung.

In der Opnsense kannst du dann mit Freeradius einiges limitieren.


Zusätzlich kann der Access-Point selber alle Anfragen nur an das Gateway weiterleiten (IP-Isolation) und zusätzlich verschiedene SSIDs (VLAN Isolation) für die einzelne Netze ausstrahlen.

Gibt einige Möglichkeiten.


Bei mir gibt's zum Beispiel:

Office, Privat, Gast/SmartHome, Camera....

Das ganze dann noch mit Site2Site VPNs und komplett segmentiert und limitiert.

Haproxy für Nextcloud mit Lets Encrypt einbindung....

Opnsense bietet echt ein starkes Gesamtpaket.
 
Bei den Accesspoint-Einstellungen kann man (zumindest bei Mikrotik) einstellen, dass die Clients isoliert werden, so können sie sich untereinander nicht sehen.
Denke, das meint Hipiman.
Diese Einstellung greift pro SSID.
Habe ich beim Gäste- und IoT-WLAN auch an, beim normalen hingegen nicht.

Ah ja, die Option. Stimmt.

Wenn du nicht gerade FritzBox Repeater verwendest, kannst du einiges einstellen.

Ich habe die Aruba AP22, da kann ich glaub schon einiges einstellen, hab mich bisher aber noch nicht damit beschäftigt. Ich werd mal schauen, wann ich genau dazu komm, das umzustellen, ohne dass mir jemand zuhause aufs Dach steigt, dass das Internet nicht geht. Dann meld ich mich nochmal, bzw. halte euch auf dem Laufenden mit meinem Setup, dann können wir über was handfestes disktuieren.
 
So, jetzt hab ich gestern mal meine OPNsense in Betrieb genommen und stoße schon auf erste, teils seltsame Probleme.
Mein Setup: i7-9700K, Fujitsu D3643-H, 16GB RAM, 128GB Gigabyte NVMe SSD, Intel X520-DA2 SFP+.

Ich habe zuerst OPNsense vom USB Stick gestartet, um zu sehen ob die Intel X520 erkannt wird, ich hatte dann drei Interfaces. emo0 und ix0 und ix1. Alles gut soweit. Habe dann mein Technicolor TC4400-EU bei Vodafone aktiviert. Das scheint auch zu funktionieren, wenn ich meinen Laptop direkt an LAN1 vom Modem einstopsel, bekomme ich eine IPv6, eine IPv4 (echter DS, soweit ich das beurteilen kann) und ich komm auf die minimalistische Oberfläche des Modems pers 192.168.0.1.

Da das alles funktioniert hat, habe ich OPNsense installiert, bei eingestecktem LAN-Kabel zum Modem auf em0 und bei eingestecktem DAC Kabel zum Aruba Instant On 1930 Switch. Das wird automatisch erkannt, ich bekomme auf WAN eine IPv4 und eine IPv6 per DHCP, und für mein LAN (ix0) weißt es mir eine IPv4 (192.168.1.1) und eine IPv6 (iwas, nicht wichtig) zu. Das Interface ix1 wird jedoch nicht mehr angezeigt, es steckt kein Kabel drin.

Der Switch und die APs bekommen IPs per DHCP zugewiesen (andere Geräte, wie den Batteriespeicher muss man nochmal separat nochmal trennen und neu einstecken, dass sie sich eine neue IP holen können, sonst haben sie noch ihre alte (192.168.10.xxx).

Jetzt wirds jedoch seltsam. Wenn ich auf der WebGUI den Installations Wizard durch mache, dann ist danach erstmal die IPv6 auf dem WAN Interface weg. Ich hab glaub schon alle Varianten der Config der IPv6 über DHCP durch, habe unterschiedliche Präfix Längen probiert und alle Optionen an/aus geschaltet, nie hatte ich eine IPv6 danach. Ich finde auch nirgends genau, welchen Präfix ich für Vodafone Cable angeben muss.

Was richtig seltsam ist, ist die Tatsache, dass wenn ich die IPv4 auf LAN ändere (z.B. in 10.0.0.1), dann bekommt der Switch und somit keine Geräte danach mehr eine IP zugewiesen. Neustart des Switches, Ein und Ausstecken des DAC Kabels, nichts hilft. Was hilft ist, dass ich das DAC Kabel in den anderen Port der X520 Karte stecke. Der wird dann plötzlich als ix0 erkannt. Selbiges bei einem Neustart der OPNsense. Jedes mal, wenn ich die neustarte, muss ich das DAC-Kabel in den jeweils anderen Port der X520 Karte stecken, damit mein Switch und meine Geräte wieder ihre IP-Adressen bekommen. Wie kann das denn sein? Wie kann überhaupt das Interface ix0 immer auf einer anderen Seite der Karte liegen? Das ist doch hart vorgegeben, oder? Das hat mich gestern ziemlich verwirrt, als ich das rausgefunden habe und das war mehr aus Verzweiflung, dass ich das Kabel in den anderen Port reingesteckt habe, weil warum sollte das funktionieren?

Bin jetzt ein bisschen ratlos, was ich tun soll, ich kann ja nicht bei jedem Neustart das Kabel umstecken.
 
Bist Du sicher, dass Du eine echte IPv6 von Vodafone bekommst und nicht nur eine lokale?

Das Kabel Deutschland Gebiet hat m.W. kein dual Stack (ich bekomme in Bayern und Bridge Mode jedenfalls kein ipv6).

Im ehem. Unitymedia Gebiet kann es anders sein.

Re Ports: als Notlösung die beiden Ports als Bridge oder LAGG anlegen, so dass auf beiden der DHCP Service läuft?
 
Bist Du sicher, dass Du eine echte IPv6 von Vodafone bekommst und nicht nur eine lokale?

Das Kabel Deutschland Gebiet hat m.W. kein dual Stack (ich bekomme in Bayern und Bridge Mode jedenfalls kein ipv6).

Im ehem. Unitymedia Gebiet kann es anders sein.

Re Ports: als Notlösung die beiden Ports als Bridge oder LAGG anlegen, so dass auf beiden der DHCP Service läuft?
Die IPv6 ist Vertragsbestandteil. Wurde mir auch vom Vodafone Support zugesichert, dass ich bei Benutzung des Technicolor TC4400 echten DS bekomme.
Eine lokale IPv6 fängt immer mit FE80:: an oder? Die IPv6 die ich aus dem Modem auslesen kann, sieht anders aus.

Benutzt du die Vodafone Station im Bridge Modus? Wenn ja, liegt das nicht an Vodafone, sondern an der Vodafone Station, die kann im Bridge Modus kein IPv6, deswegen bekommst du mit der nur eine IPv4.

Den zweiten Port möchte ich für mein NAS verwenden, das ist aber noch nicht fertig, weswegen ich es noch nicht an den Port hängen kann.
 
Das wechseln der Interfaces kommt mir von den Raspis bekannt vor.
Bei den Raspis gibts ne Option, damit die nach den PCIe-Regeln benannt werden (enpXsY).
Dann sind sie immer gleich, da physisch eben an dem PCIe-Port.

Kann passieren, wenn das Board beim booten die Hardware enummeriert.
Kannst du da eventuell im BIOS was umstellen?

Voodoofone in Bayern macht echten DS, zumindest beim Business, ich hab nen 2a02.810d.x /60er IPv6-Prefix in der Fritze.
Leider verteilt die Fritze nur /62er Prefixe oder so, so dass dahinter nix mehr nutzbar ist...
 
1644921324049.png

Die 6490 verteilt nur /61er, obwohl ich in OPNsense das /60 angebe (exposed Host) und nen Prefix Hint versende...

Mir ist aber noch unklar, wie ich das gesamte Netz dahinter verstecken oder die Subdomains von außen auf festen IPv6 zugänglich machen könnte / sollte.
 
Die IPv6 ist Vertragsbestandteil. Wurde mir auch vom Vodafone Support zugesichert, dass ich bei Benutzung des Technicolor TC4400 echten DS bekomme.
Berichte Mal, wie die Verbindungsqualität mit der Technicolor ist - meine Vodafone Station produziert leider viel Packet loss, wenn sie ein paar Tage gelaufen ist :-(
 
@asche77 Nächtlicher Reboot? Was ich damals vom Kabel-Provider hatte war auch Grütze, aber die Netzprobleme waren irgendwann so groß, da hat die Box den Kohl auch nicht mehr fett gemacht. 😉
Regelmäßige reboots helfen. Hänge demnächst eine Zeitschaltuhr dran dafür.

Netzprobleme macht Vodafone in der Tat oft - ist das Deiner Erfahrung nach besser bei Telekom VDSL oder m-net "Glasfaser"?
 
Berichte Mal, wie die Verbindungsqualität mit der Technicolor ist - meine Vodafone Station produziert leider viel Packet loss, wenn sie ein paar Tage gelaufen ist :-(
Mach ich gerne, wegen dem Package Loss hab ich mir das Technicolor überhaupt geholt. Wobei ich seit Dezember keine Probleme mehr hatte und die Station recht stabil ohne Reboot durchgelaufen ist mit minimalem Package Loss.
Der erste Vodafone Speedtest hatte aber mit dem Technicolor Modem zumindest mal wieder 1150MBit/s angezeigt, das hatte ich mit der Vodafone Station selbst nach dem Reboot nicht erreicht.
 
Die neue Version 2.6.0 wurde veröffentlicht.

Testkaninchen bitte vor und berichten! :sneaky:
 
Das Update über das Webinterface lief komplett unauffällig durch und auf den ersten Blick funktioniert alles perfekt!

Edit 1: Multi-WAN, Failover (with Gateway Groups), Traffic Shaping ... läuft alles wie gewohnt.

Edit 2: Der DNS Resolver hat ohne Neustart nicht auf allen Interfaces geantwortet.
 

Anhänge

  • gateways.png
    gateways.png
    18,6 KB · Aufrufe: 80
  • 70535681.png
    70535681.png
    8,7 KB · Aufrufe: 86
Zuletzt bearbeitet:
Irgendwie bin ich zu blöd für WireGuard:
Code:
iperf3 -c 192.168.6.1 -R
Connecting to host 10.0.0.1, port 5201
Reverse mode, remote host 10.0.0.1 is sending
[  5] local 192.168.20.10 port 59266 connected to 10.0.0.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  6.64 MBytes  55.7 Mbits/sec               
[  5]   1.00-2.00   sec  9.45 MBytes  79.3 Mbits/sec               
[  5]   2.00-3.00   sec  6.70 MBytes  56.2 Mbits/sec               
[  5]   3.00-4.00   sec  7.62 MBytes  63.9 Mbits/sec               
[  5]   4.00-5.00   sec  7.55 MBytes  63.3 Mbits/sec               
[  5]   5.00-6.00   sec  7.12 MBytes  59.7 Mbits/sec               
[  5]   6.00-7.00   sec  7.30 MBytes  61.3 Mbits/sec               
[  5]   7.00-8.00   sec  8.78 MBytes  73.7 Mbits/sec               
[  5]   8.00-9.00   sec  9.36 MBytes  78.5 Mbits/sec               
[  5]   9.00-10.00  sec  7.46 MBytes  62.6 Mbits/sec               
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.01  sec  78.3 MBytes  65.6 Mbits/sec   43             sender
[  5]   0.00-10.00  sec  78.0 MBytes  65.4 Mbits/sec                  receiver
Die CPU Auslastung ist auf Server und Client komplett unauffällig, MTU sollte auch stimmen, bin komplett ratlos ...
Der DNS Resolver hat ohne Neustart nicht auf allen Interfaces geantwortet.
Das Problem ist leider wiederkehrend. Irgendwie verschluckt sich Unbound auf allen außer dem ersten Network Interface.
 
Ist die Performance zu niedrig ?
Komisches verhalten über den VPN?

Dann könnte dir die MSS Einstellung bei jedem LAN Interface mit 1420 weiterhelfen.

(Nicht beim WAN und Wireguard Interface)

MTU sollte nicht angepasst werden. (Wireguard Konfig und alle Interface)

Damit hast du dann die volle Leistung.

War bei mir das Problem.

*Opnsense + wireguard in meinem Fall
 
Ist die Performance zu niedrig ?
Ja, mindestens um Faktor 4 - 5.
Komisches verhalten über den VPN?
Nein.
Dann könnte dir die MSS Einstellung bei jedem LAN Interface mit 1420 weiterhelfen.
Fehlt bei 1420 nicht der PPPoE Overhead? Ich hatte MSS zu Testzwecken sogar auf 1280, aber ohne Erfolg.
Testkaninchen bitte vor und berichten! :sneaky:
Ich bereue es mittlerweile, dass ich 2.6.0 installiert habe. Das Problem mit dem DNS Resolver ist wirklich abgefuckt. (n)

Edit 1: Bin zurück auf 2.4.5-RELEASE-p1 (natürlich nachdem ich mir massiv ins Knie geschossen hatte mit 2.4.5-p1 config und 2.4.5 install image) ... ich reih mich dann mal wieder hinten ein.

Edit 2: Die miese WireGuard Performance lag übrigens auch an pfSense ...
 
Zuletzt bearbeitet:
Ich muss ein wenig zurückrudern:
  • Die miese WireGuard Performance lag daran, dass ein Teil der Pakete, warum auch immer, an der Default Rule der Firewall kleben bleiben
  • Das Problem mit dem DNS Resolver existiert auch schon in 2.5.2
Ich gehe jetzt einfach mal davon aus, dass in beiden Fällen die Ursache bei einem Konfigurationsfehler zu suchen ist.
 
Ja, das ist es nicht. Ich werde berichtigen, wenn ich des Rätsels Lösung gefunden habe.

Die WireGuard Performance ist leider nach wie vor nicht der Knaller, aber immerhin bekomm ich jetzt 150 Mbit/s stabil hin.

Edit: Die miese WireGuard Performance lag offenbar auch Unzulänglichkeiten in der Konfiguration.
 
Zuletzt bearbeitet:
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