Messages

What happens when CARP is not applied to the WAN interface (only)? I learned that I can get 2 (dynamic, well, rather "pseudo-static") IPv4 from my cable-modem in bridge mode (DHCP client), but not a third. What happens, when I don't config CARP on the WAN side, but on every other interface (physical (LAN, DMZ), virtual, VLANs, WG-VPN) of the opnsense device? Would such a setup still work? What would not work? The main idea here is to have a decent "fall-back" after an update of OPNsense on one of the opnengines. Has anyone tried this already?

The fun part maybe lies in the Multi-WAN setup: igc0 is for the cable WAN, igc1 for the LTE WAN (which also delivers 2 dynamic/pseudo-static IP, in fact, I might be able to get 3 on the LTE WAN side, maybe even non-DHCP). This fail-over (and fail-back) indeed works seamlessly and is very convenient (the cable dies more often than I had expected). However, I do (have to) accept some reduced functionality on incoming traffic (LTE is NATed, cable "bridged"), but outgoing is all fine (0.05 vs 2.5 GBit/s downstream, though).

Most probably I didn't get the whole picture of CARP yet, although I tried hard to work myself through docs and tutorials (opnsense, krenn and others)...

Could anybody share some experience or recommendations with such or a similar setup, please?

I have upgraded to 24.7.1 about 2 days ago and monitor opnsense with zabbix since 24.1 (and earlier).

Besides some problems with zabbix by SNMP (not all values report like before), the RAM consumption has more than doubled since the upgrade: from around 2GB now to 5GB, while nothing has changed really in the network except the upgrade of opnsense.

Is this normal/common? Just the "zabbix reading" wrong? Has anybody experienced similar behavior (and mitigated, how?) or not at all? My opnsense box has 16G so it shouldn't run into sever problems soon, but I still find this remarkable. Any reasons known for this?

Haven't looked at your capture, do you just NAT and firewall, i,e. No other Service(s) running? My 4-core AMD 1GHz jaguar (APU) maxed out at around 480 Mbit/s with nothing else running using OPNSense 18.xy. Adding IDP/IDS brought it down to less than 140. Now I am using a 4-core Xeon 3.2 GHz (E3-1220v3) that went up to 540 (including IDS/IDP) running OPNSense up to 20.1. After upgrading to 20.7. it went down below 340. Always on the very same 600/60 line with same modem and same NICs (Intel). For the time being I reverted back to 20.1.9.

I've read about even more substantial perfomance degradation somehow related to 20.7. Why don't you give it a try with 20.1.9?

It was added to 20.7.
https://github.com/opnsense/changelog/blob/master/doc/20.7/20.7.r1#L47

Thanks for clarification and pointing this out (again). Despite my disappointment about the 25% performance decrease on the WAN side in my environment that 20.7. brought for me, and my urge to go back to 20.1., I should have read the doc more thoroughfully.

Maybe this would be another type of ,,backup", however,

A restore of config only restores config, it doesnt install plugins for you. There is an approach which would try to so this also but I'm unsure about its current state

I would like to see an automated procedure that requests installation of plugins for which configuration data can be found in a backup, and then configures those plugins accordingly. I am hoping the approach you mention will make it into a final release soon.

I just did the move back from 20.7 to 20.1 although it was more than just messy. The "config backup" function lost very much on first sight. After having installed all (most?) "lost plugins", many of the "lost plugins's settings" were back. Weird experience, not at all what I expected with a "backup". However, download speed is back! I am tempted to second the opinion there might be a problem with ethernet/network drivers since FreeBSD 11.

I am just a bit fed up with this because I dropped my APU (PC Engines 4-core jaguar 1GHZ AMD) in favor of a new XEON platforn (4-core 3.2GHZ Intel) a few OPNSense releases ago (17?), and now, with that multiplied power, I am kind of facing similar performance drawbacks again. Is this really how it should be in the realm of "open source"?

Bis jetzt fand ich OPNSense die genialste Sache der Welt, aber nach diesem "Glitch"? bin ich mir nicht mehr so sicher...

Nachdem ich von Version 20.7. zurück auf 20.1. musste, weil 20.7 nach dem Update von 20.1. (FreeBSD11 auf FreeBSD12) über 25% der WAN Performance meiner "pure Intel" Firewall "gefressen hatte", habe ich nach einer "Neu-Installation" mit dem Image von 20.1 und mit Hilfe eines Config Backups von vor dem Upgrade auf 20.7. festgestellt, dass einige (viele) Settings nicht mit dem Restore wieder Instand gestellt worden sind. Unter anderen:
- Theme(s) - kein einziges
- Settings für IDS/IDP Suricata ausserhalb "global om/off" (kein einziges innerhalb der Settings)
- plugins: inklusive jeweils alle settings weg, also nicht geladen nach "Restore": Zabbix Agent, IDP ET Pro Telemtry, IDP Snort, OS net snmp, OS-ntopng (mit allen Anpassungen), os-nut, os-redis, und weitere...

Ich suche noch, und werde diese Nachricht anpassen, wenn ich weitere Auslassungen finde..

Damit ist aus meiner Sicht die "Backup/Restore" Funktion nicht das, was ich von einer "Config Management" Funktion erwarten würde. Vieles musste ich "von Hand" und aufgrund schriftlicher (Papier!) Aufzeichnungen wieder herstellen. Ist das mit OPNSense normal? Wie sieht die Community das?

Festgestellt habe ich das erst, weil ich wegen des katastrophalen Fehlverhaltens von vermutlich FreeBSD 12 zurück auf FreeBSD 11 Editions musste (der Backup kam wohl bemerkt von der letzten funktionierenden FreeBSD 11 basierten Installation), und anschliessend nichts mehr so war wie zuvor.

Hat jemand ähnliche Erfahrungen gemacht, oder habe ich alles nur falsch gemacht?

Is there any link to the procedure about why switching from FreeBSD 11 to 12 does not imply a major number of OPNSense, e.g. from 20.1 to 21.1 (instead of 20.7), if there is a chance of messed up network drivers coming with the new version of FreeBSD? Why is it so "hard" to move back from 20.7 (FreeBSD 12 based) to 20.1 (FreeBSD 11 based)? The OPNSense (update and download) mirrors use a completely different path for this. Having more trouble to revert back from 21 to 20 would at least be kind of more understandable for me (e.g. minor vs. major versions)...

Besides the WAN-side performance drop since the upgrade to 20.7., I can see a lower average CPU usage on the same box, in the very same environment, although power settings are set to maximum now. I monitored this using OPNSense system information as well as with the Zabbix agent - however, the Zabbix agent version changed with the upgrade as well.

CPU utilization: idle time rose from 85% to avg. 98%, and CPU load went from 0.3 (5 min avg. per core) down to about 0.04. Could anyone confirm something similar as well?

Similar problem here. Nothing changed except upgrade to 20.7.1. Download speeds down from ~530 MBit to ~340, upload about the same (about ~52 MBit/s) on a nominal 600/60 DOCSIS cable. Powerd set to "maximum" (different setting doesn't change anything). Switching off IDP (suricata) reverts to previous speeds. Switching IDP back on lowers speed again. Box is a Quad Xeon 1225v3 with way too much RAM, usually between ~20% to ~50% CPU (ntopng running with only a few other plugins on the same box).

Update: Network ports used are an internal Intel I217-LM and a quad-port 82571EB/82571GB PCI card.

Is there an "easy" way to completely revert the box to 20.1.9_1 or even the last 19 release ("opnsense-revert -r 20.1.9 opnsense" as root user only results in "Fetching opnsense.txz : .. failed")? Trying:

Code Select Expand

root@opnengine:/ # opnsense-update -usBP -m "https:\/\/opnsense-mirror.hiho.ch" -n "FreeBSD:11:amd64" -r "20.1"
root@opnengine:/ # opnsense-update -pf
Updating OPNsense repository catalogue...
pkg-static: https://opnsense-mirror.hiho.ch/FreeBSD:12:amd64/FreeBSD:11:amd64/meta.txz: Not Found
repository OPNsense has no meta file, using default settings
pkg-static: https://opnsense-mirror.hiho.ch/FreeBSD:12:amd64/FreeBSD:11:amd64/packagesite.txz: Not Found
Unable to update repository OPNsense
Error updating repositories!



seems to always inject FreeBSD:12:amd64. How could I avoid this so that to update points to a valid path?

Or is it mandatory to reinstall from scratch using a config backup?