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

  • Ersteller Gelöschtes Mitglied 63700
  • Erstellt am
Wir hatten in

https://www.hardwareluxx.de/communi...uting-appliance.1285668/page-58#post-30441533

diskutiert, ob man in der OPNsense an verschiedenen Adapter das selbe VLAN anlegen kann. Habe ein physisches Interface und ein VLAN gebridged, aber das führt nicht wirklich zum Erfolg. Wenn ich an der Schnittstelle und im VLAN den selben Adressbereich angebe, spuckt die Sense auch einen Fehler aus.

Sprich ich muss da eh InterVLAN Routing machen. Ist aber nicht so schlimm, beregle ich halt alles mehrfach und lasse die Bridge weg. Glaube, das tangiert nicht gross mit meinen Anwendungen und Hosts.

Mag sein, dass es irgendwie doch gehen würde. Wäre zumindest schmerzfreier gewesen mit einem Switch.

Die VLANs am Server und die physischen Netzwerke sind jetzt mal eingerichtet, beregelt und durch gepingt. War ein bisschen tricky, dass da die VLANs nicht untereinander reden dürfen, aber trotzem raus können. Für einen Anfänger recht verwirrend.

Mal sehen, vielleicht hole ich mir mit dem neuen Provider ein /29 Subnet. Brauchen könnte ich das sehr gut, weil im Moment muss ich zum Teil für meine Sims auf den eigenen Server per VPN verbinden und noch andere Handstände machen. Das ist aber leider richtig teuer (CHF 60.-/Monat). Weiss noch nicht, ob ich das so durch kriege.

Speed an der ollen E3 Haswell Hardware ist ganz gut. Habe bemerkt, dass mein Provider einen VW Prüfstand hat. Wenn man den 10 Gbit Port eine Weile nicht benutzt hat habe ich super Werte im Speedtest. Läuft die Firewall ein paar Tage, macht die Leitung im Upstream bei 2 Gbit/s zu. Aber wird ja eh noch mal der Provider gewechselt, der garantiert die 10/10 an einem AON Anschluss.



PS.JPG
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ahh prima! Wie klappt es bei euch mit der Performance?
Ich hab die Erfahrung gemacht, dass bei FreeBSD also opsense unter Proxmox die VirtIO NICs nicht so toll performen. Via iperf3 von VM zu OPNsense VM komme ich auf 2Gbps, auf andere Linux VMs jedoch auf 40Gbps.
 
@Knogle Ich hab mit der pfSense unter Hyper-V maximal 3,8Gbit/s gesehen, leider...
Behelfe mir inzwischen damit, dass ich kurzzeitig mittels Powershell ohne pfSense switche, statt mit der pfSense zu routen... :oops:
Damit erreiche ich 10 Gbit/s.
 
Zuletzt bearbeitet:
Unter Proxmox hatte ich mit einer E3-1281 v3 mit opnsense ca. 3/3. Mit der Sophos 8/2, der Upstream wurde aber vom Provider beschnitten. Jetzt baremetal opnsense bin ich sehr zufrieden. Denke der Provider gibt nicht mehr her. Unter ESXi hatte ich leicht bessere Performance als unter proxmox.

Baremetal mit IDS:

PS.JPG


Unter ESXi mit IDS:


Speedtest.JPG
 
Zuletzt bearbeitet:
Danke euch schon mal! Das ist echt super schade :/ OpenWrt habe ich lange genutzt, hat im Grunde auch >30Gbps auf der Bridge geliefert, aber OPNsense mag ich halt mehr.
 
Die Frage ist braucht man die Leistung wirklich?
Wenn man so eine Datenmenge hätte, sollte das doch eher auf dem Switch gemanaged werden.
 
Ja, wir sind im Luxx.

ich nutz das Stueck Blech auch dazu um Inter-Vlan-Routing mit 20gbps zu betreiben :d
 
Habe mir nun doch mal die "Arbeit" gemacht und die OPNsense neu mit ZFS aufgesetzt. Backup rein, fertig. Die Geschichte mit den Snapshots ist schon ne feine Sache. :drool:
 
Ich habe jetzt von baremetal auf VM auf Proxmox umgestellt, soweit läuft alles ohne Probleme, bis auf Backups bzw. Reboots der VM.
Damit ich saubere Snapshots machen kann und auch der Shutdown sauber abläuft, habe ich den "Qemu Agent" aktiviert und das Plugin installiert und aktiviert.
Des Weiteren nutze ich PCIe passthrough und reiche einen NIC (I225-V) von zweien durch. Unter Memory ist "Ballooning Device" deaktiviert, da dies bei PCIe passthrough nicht empfohlen wird.

Aktuell habe ich den "Qemu Agent" deaktiviert und das Plugin auch deaktiviert und soweit läuft alles stabil und ich kann auch daily Backups Mode.: "Stop" durchführen.
Sobald aber der Qemu Agent aktiviert ist, bleibt die VM im BIOS, nachdem Backup hängen, auch beim Reboot über die Proxmoxoberfläche schafft sie keinen Shutdown und bleibt hängen.
Des Weiteren ist mir aufgefallen, dass der durchgereichte NIC nicht mehr vorhanden ist und den Proxmoxhost (Node) neustarten muss, damit dieser überhaupt für die VM zur Verfugung steht.
Hab eben paar Threads entdeckt wo welche Probleme mit dem Qemu Agent hatten und diesen nicht nutzen.

Habt ihr Tipps wo ich noch troubleshooting betreiben kann, warum der Qemu Agent die VM so instabil macht bzw. überhaupt nicht funktioniert?
Oder kann ich tz Backups per Snaphot machen ohne Qemu Agent?
 
Ich würde einfach die in Opnsense eingebauten FreeBSD/ZFS snapshots/boot environments nutzen. Dann gibt's auch keine Probleme mit pcie passthrough und das System kann auch jederzeit wieder auf baremetal umgezogen werden.
 
Ein laufends VM Backup + aktueller Config-Export reicht mMn vollkommen aus im Homelab.
So oft fummelst du an dem Ding sowieso nicht rum.

Keep it simple ist immer King.
Die Config kannst dir jederzeit ausm laufendem Betrieb ziehen. Das muss reichen. Dann hast auch kein Heck-Meck wie mit deinem Vorhaben
 
Ich würde einfach die in Opnsense eingebauten FreeBSD/ZFS snapshots/boot environments nutzen. Dann gibt's auch keine Probleme mit pcie passthrough und das System kann auch jederzeit wieder auf baremetal umgezogen werden.
Quasi ZFS auf ZFS macht für mich wenig Sinn, wenn ich eben alles per NFS Share wegsichere

Ein laufends VM Backup + aktueller Config-Export reicht mMn vollkommen aus im Homelab.
So oft fummelst du an dem Ding sowieso nicht rum.

Keep it simple ist immer King.
Die Config kannst dir jederzeit ausm laufendem Betrieb ziehen. Das muss reichen. Dann hast auch kein Heck-Meck wie mit deinem Vorhaben
Wie schon im anderen Thread geschrieben, geht mir das auch so.
Gutes Argument, was ich so eh schon habe, dann werde ich auf Snapshots umstellen. aber tz den Qemu Agent weglassen, damit die VM zumindest im Falle des Falles wieder sauber hochkommt
 
Ich habe meine OPNSense auch von baremetal zu Proxmox weggezogen, vor etwas über einem Jahr.

Der QEMU-Agent macht hier z.B. keine Probleme, noch nie.
VM ist wie folgt aufgebaut, und hat auch zwei NICs per PCIe-Passthrough:
1726479810465.png

- QEMU-Agent aus dem offiziellen OPNSense-Repo
- tägliche Config-Backups auf Nextcloud
- tägliche Sicherung per Snapshot

Bei Restores etc. gab es da auch noch keine Probleme. Vielleicht ist das so für dich ja auch ein denkbarer Weg.
 
VM ist wie folgt aufgebaut, und hat auch zwei N
- QEMU-Agent aus dem offiziellen OPNSense-Repo
- tägliche Config-Backups auf Nextcloud
- tägliche Sicherung per Snapshot

Bei Restores etc. gab es da auch noch keine Probleme. Vielleicht ist das so für dich ja auch ein denkbarer Weg.
Ich bekomme den Qemu Agent nicht zuverlässig zum Laufen. Jedesmal wenn die VM gestoppt wird, wird ab dem nächsten reboot das PCIe Pass THrough Device nicht mehr erkannt, solange der Host nicht neugestartet wird.
1726495008712.png
 
Und das passiert nicht, wenn der QEMU-Agent nicht installiert ist?

Ich habe das mit dem Backup über "Stop" eben auf meinem System nachgestellt - klappt einwandfrei. Ich vermute da klappt etwas mit dem ordnungsgemäßen Herunterfahren der VM nicht. Eventuell kommt es zu einem harten Kill, und dann wird die NIC nicht mehr korrekt an den Proxmox-Host zurückgegeben und ist somit blockiert. Was sagt denn das Backup-Log? Ausgabe von dmesg auf dem Host? Kannst du beim Herunterfahren mal auf der Console der VM mitschauen?

Code:
INFO: Starting Backup of VM 9999 (qemu)
INFO: Backup started at 2024-09-17 00:44:02
INFO: status = running
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: VM Name: firewall
INFO: include disk 'scsi0' 'vg0-nvme:vm-9999-disk-2' 32G
INFO: include disk 'efidisk0' 'vg0-nvme:vm-9999-disk-0' 4M
INFO: include disk 'tpmstate0' 'vg0-nvme:vm-9999-disk-1' 4M
INFO: stopping virtual guest
INFO: creating vzdump archive '/mnt/pve/office-nvme-r5/dump/vzdump-qemu-9999-2024_09_17-00_44_02.vma.zst'
INFO: starting kvm to execute backup task
swtpm_setup: Not overwriting existing state file.
INFO: attaching TPM drive to QEMU for backup
INFO: started backup task '22fd1f89-2ecc-4967-86e2-291b7916af25'
INFO: resuming VM again after 47 seconds
INFO:  28% (9.2 GiB of 32.0 GiB) in 3s, read: 3.1 GiB/s, write: 317.2 MiB/s
INFO:  36% (11.7 GiB of 32.0 GiB) in 6s, read: 847.0 MiB/s, write: 846.7 MiB/s
INFO:  42% (13.8 GiB of 32.0 GiB) in 9s, read: 711.7 MiB/s, write: 711.5 MiB/s
INFO:  49% (16.0 GiB of 32.0 GiB) in 12s, read: 764.9 MiB/s, write: 764.1 MiB/s
INFO:  56% (18.2 GiB of 32.0 GiB) in 15s, read: 748.0 MiB/s, write: 747.5 MiB/s
INFO:  63% (20.4 GiB of 32.0 GiB) in 18s, read: 767.3 MiB/s, write: 767.3 MiB/s
INFO:  70% (22.5 GiB of 32.0 GiB) in 21s, read: 699.6 MiB/s, write: 699.3 MiB/s
INFO:  77% (24.6 GiB of 32.0 GiB) in 24s, read: 738.3 MiB/s, write: 738.2 MiB/s
INFO:  83% (26.8 GiB of 32.0 GiB) in 27s, read: 722.6 MiB/s, write: 722.0 MiB/s
INFO:  90% (29.1 GiB of 32.0 GiB) in 30s, read: 793.4 MiB/s, write: 792.7 MiB/s
INFO:  97% (31.2 GiB of 32.0 GiB) in 33s, read: 735.1 MiB/s, write: 735.0 MiB/s
INFO: 100% (32.0 GiB of 32.0 GiB) in 34s, read: 778.3 MiB/s, write: 531.7 MiB/s
INFO: backup is sparse: 8.51 GiB (26%) total zero data
INFO: transferred 32.00 GiB in 34 seconds (963.9 MiB/s)
INFO: archive file size: 15.24GB
INFO: adding notes to backup
INFO: Finished Backup of VM 9999 (00:01:24)
INFO: Backup finished at 2024-09-17 00:45:26
INFO: Backup job finished successfully
TASK OK
 
Hi

Nur mal so eine Idee: kann ich zwei mal die selbe eingehende NAT Regel erstellen, die auf zwei verschiedene interne IPs zeigen? Und dann in den Firewallregeln per geoip sagen, wer wo hin geleitet wird? Also eingehend zwei NAT Regeln an der selben IP/selber Portrange?

Oder gibt es noch eine andere Lösung für das Problem? Auf den Client habe ich leider keinen Einfluss.
 
Ohne es tatsächlich mal probiert zu haben.... Leg eine Port Forwarding Regel an, Source dein GeoIP Alias und Destination -> Server 1.
Dann klone die Regel und ändere den Source Alias auf den anderen und Destination -> Server 2.

Das müsste eigentlich funktionieren :unsure:
Mir fehlt der Anwendungsfall um das zu testen leider
 
Hmm, im Moment läuft alles noch über eine Zywall. Aber denke, wenn ich eine NAT Regel über der anderen habe, zählt nur die höherwertige.

Habe es getestet, und hatte tatsächlich auf beiden Servern Piloten online. Aber die waren glaube ich nur nicht raus geflogen, als ich die Reihenfolge der NAT Regeln geändert habe.

Zumindest mit der Zywall scheint es nicht zu gehen, obwohl man zwei gleiche Regeln erstellen kann. Aber die höherwertige überschreibt wohl die untere.

Bei der Zywall kann man leider bei Source von NAT keine Adressobjekte nutzen, nur bei den FW Regeln.

Ziel wäre, dass die Chinesen ihren eigenen Server haben, weil die nerven bisschen. Und gleich blocken möchte ich die auch nicht. Und der Rest der Welt fliegt auf dem Hauptserver.
 
Ziel wäre, dass die Chinesen ihren eigenen Server haben, weil die nerven bisschen. Und gleich blocken möchte ich die auch nicht. Und der Rest der Welt fliegt auf dem Hauptserver.
Das geht mit *Sense. Aber die Latenzen nach China werden dadurch auch nicht besser.
 
Zuletzt bearbeitet:
Das passt schon mit den Latenzen. Die Chinesen haben meist einen Ping von 120ms, die Amis so 60-80. Der Server hält nur die Verbindung und verteilt Patches, die Clients kommunizieren P2P per UDP. Läuft erstaunlich gut mit Piloten aus aller Welt. Früher sind wir sogar noch über VPN über meine popelige Coax Leitung geflogen. Ging auch, aber mit der Fiber um Welten besser.

Als der Sim noch offiziell betrieben wurde, war die Technik noch nicht so weit wie heute, hat auch funktioniert.
 
Jup, 1x onboard NIC und einmal PCIe 10GbE NIC, früher noch die 2x 25 GbE.
Auf einem anderen System auch noch eine Nvidia GPU.
 
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