Messages

@defaultuserfoo, your experience may not be widely shared. For example, I clearly remember the advice and warnings in the documentation on 26.1, before I tested then fully migrated without issue. It follows that assaulting OPNsense and its documentation may not be the most fruitful path to assistance.

To your problem, it appears to me you are creating a global rule then trying to punch a hole in it. This may not be the best initial design. In a corresponding position, at the interface level I allow to any from my primary device, then in a subsequent rule use inversion to limit all others locally, with specific allows (NAT) then general blocks as desired for internet. No holes are punched in any prior rule. These migrated perfectly. I do also have a couple of floating rules covering DNS and NTP for everything. Again, no holes need be punched in that.

In general terms, my advice is first allow what you must, then block the rest. Design and review is a task prior to construction, like any systems design, so in my view your problem existed before your migration exposed it.

no more warning than to back up your configuration and/or to take a snapshot

If you are not taking a snapshot before any similar system modification then you are making a mistake with which I cannot otherwise help you.

Not so great when they are building your house.

I can give this piece of help: edit your first post and change the title to something like "Opnsense and Win 11 in VirtualBoxes - connection problem"

Be informative.

I have no deep background knowledge of IPfire. I have run it in test only, and donated a couple of times in hopes of the fabled v3 or whatever the relevant number is. I noted the "my view on how it must work" restrictions on basic operation of the available zones and the since largely recanted attack on Wireguard as an alternative to OpenVPN. I remain aware of IPfire but otherwise am very happy with OPNsense at the edge and Mikrotik behind.

@150d, when you describe what needs to talk to what, think also about which device initiates a conversation. Does it need to be either way? For example, my IoT net can reach the internet but no device on another LAN, yet this is no impediment to my private LAN devices being able to talk directly to the IoT devices to give commands or request information. Source for session initiation matters.

From what did you update? I notice you mentioned reboot, which does not happen in a 26.1.3 to 26.1.4 upgrade unless you do it yourself or have it set as an automatic action.

... whether an upgrade would noticeably improve protection

That is not something I am able to test specifically. Improved protection through increased frequency of update is something I have to assume without measurement of practical difference. However, I have found that the ability to look up IPs can be useful, including getting a site unblocked by qfeeds after some review. I subscribed to qfeeds Plus at an early stage, and have uninstalled crowdsec.

PPS is measured with 100B size, this is to measure the performance and include small sized packets. Basically to see how much MAX pps you can route/switch before you see a performance degradation.

Throughput does not have mentioned what packet size or tool was used for measurement. But I would guess they used default L3 MTU size (1500B).

Regards,
S.

I see it says different things in different brochures from different periods. This came from a DEC 700 Series brochure:

Maximum PPS is measured using 100 byte sized packages. All throughput numbers are based upon maximum packets per second multiplied by standard 1514byte frame size minus additional overhead where applicable

the clear implication being that they took the 100 byte rate and multiplied it by ~1500. I mentioned 500 bytes because that rather than 100 is in the DEC 600 Series brochure.

This is generally consistent with what is being reported here.

I had a look at the brochure. In the fine print it appears to me to say that packets per second are measured with 500 byte packets but this number is multiplied by 1500 [byte packets] to get throughput. Ergo, it cannot be achieved. Did I misread?

That depends on your security setup for Opnsense. HTTP or HTTPS access? From which [v]LANs? Quality of pass word or phrase? 2FA? SSH access? Password or passkey for that? Much of that is discussed here.

You can also run a security audit.

Reservations remain as you would expect.

Are your reservations outside your dynamic pools?

Did you miss an Apply somewhere along the line?

Do you mean an AP to attach to an interface on an existing Opnsense box?

At face value you are asking to run Opnsense on an ARM A53. How would you propose to do that with proven software?

There are no special considerations I have seen mentioned, use of ISC or Kea or DNSmasq being essentially independent from the upgrade. ISC changes to being a plugin but still transitions as expected, or so I read because I had switched to Kea prior. Use snapshots and upgrade stuff in the order that pleases you. If you are not already using ZFS then consider seriously a reinstallation to employ it, before other work.

I don't use everything in the menu, ... for example stuff like ... services->ISC DHCP ...
It would be great if it was possible to click a button to hide

Without detracting from your general point with which I agree, if you are on 26.1 and not using ISC DHCP then go to -->firmware-->plugins and bin it. The menu vanishes.

Migrated the main firewall and rules successfully, today. The new rules view is a structural improvement for me, making it easer to perceive and potentially change these configurations.