Messages

Some people reported performance related issues with our DEC4200 series, which after investigation turned out to be a bios related issue.

A new bios has been released which addresses these concerns.

To download the latest version of the bios, please visit https://docs.opnsense.org/hardware/bios.html#dec4200-series
Installation instructions can be found in the same document as well.

Stay safe,

Your OPNsense team

Hi,

We just uploaded a new bios version, which can be downloaded from https://docs.opnsense.org/hardware/bios.html#dec4200-series and should resolve the throughput issues we have seen.


Best regards,

Ad

@l1lz can you drop me an email? there is a chance this is bios related, in which case I can offer something to test/validate on your end.

@DEC4280Problem, @User65192 it might be better to contact us directly if you purchased a machine and having difficulties with your setup. Creating new accounts (yes, I checked) every week reporting the same challenges usually isn't very helpful.

We have a test setup over here available and do run these tests quite often showing the expected results, when needed we also offer excellent commercial support to debug your setup.

Best regards,

Ad

@l1lz just to be sure, you are testing with the firewall in between iperf3 machines and with our default config. running iperf3 on your firewall is a common testing issue as it influences your measurements (a lot).

our default test setup (which reaches reaches the advertised speeds), is setup like:

[client] --> [firewall] --> [server]


The client uses an iperf3 command like:

Code Select Expand

iperf3 -c <other-host> -P 8 -Z -t 5 -M 1500


Somethings to consider when numbers don't match:

* ice needs firmware loaded, which is in our default config, the tunable is called "ice_ddp_load"
* make sure to disable the default reply-to rule (Firewall: Settings: Advanced), when a gateway is accidentally configured it may send you packets in the wrong direction.

For regular routing in my experience rss doesn't really help much as most network cards already distribute the load properly over different cores. When results are less than expected, always check `top -CHIPS` as it helps figuring out if flows are distributed as one would expect.

Best regards,

Ad

Hi,

Either the machine is not very capable or your config.xml file is very large (or a combination), although all new code doesn't need to serialize the file to an array (as legacy code is doing), some of the actions still depend on older code.

When there are one or two hotspots and you have identified them, it might make sense opening an issue (https://github.com/opnsense/core/issues).

In some cases rewriting the parts to direct usage of the Config instance isn't a lot of work.

Best regards,

Ad

Hi,

We have thought about macro expansions at one time, but haven't managed to come up with something functional yet.
The flexibility of OPNsense also makes it difficult to come up with a pattern that "just works", but you never know, maybe in a future release.

The issue around the central API key not sticking around does sound like a bug from our end, an omission caused by the major redesign of the user manager. If you drop us an email at support@opnsense.com and refer this post, I'll see if I can send you a version to test before a new minor release is out.

Best regards,

Ad

I haven't seen issues earlier to be honest, when suspecting a bug you can always open a ticket on GitHub.

My community support time is too limited to try to reproduce this on my end at the moment.
When hooks are triggered, I believe a log entry is triggered as well.

Best regards,

Ad

Hi Ulf,

That might depend on configured settings, these events are triggered when connected properly to the child instead of a static id:

https://github.com/opnsense/core/blob/3c2ad5d6b3c53f27d747bbde7b6ff81dc4bb7e5f/src/opnsense/mvc/app/models/OPNsense/IPsec/Swanctl.php#L246


Best regards,

Ad

Hi,

When using both legacy and new at the same time, overlaps may happen as mentioned https://docs.opnsense.org/manual/vpnet.html#combining-legacy-tunnels-and-connections

You can either lock the reqid's on the new connections too or force the numbering to start with an offset.

The latter should be possible by adding a file /usr/local/etc/strongswan.opnsense.d/reqid-base.conf containing

Code Select Expand

charon {
    reqid_base = 8192
}

Given we recently refactored the charon configuration to new mvc code, I also don't mind adding the option in the ui, just open a ticket requesting the feature here https://github.com/opnsense/core/issues

Best regards,

Ad

Hi Patrick,

I think I found the culprit, can you paste the following in a text file on the OPNcentral node:

Code Select Expand

diff --git a/deciso/OPNcentral/src/opnsense/mvc/app/models/Deciso/OPNcentral/Central.php b/deciso/OPNcentral/src/opnsense/mvc/app/models/Deciso/OPNcentral/Central.php
index 02c77910d..1e80df3bb 100644
--- /usr/local/opnsense/mvc/app/models/Deciso/OPNcentral/Central.php
+++ /usr/local/opnsense/mvc/app/models/Deciso/OPNcentral/Central.php
@@ -63,7 +63,7 @@ class Central extends BaseModel
                    $auth_groups[] = (string)$groupNode->gid;
                } else {
                    foreach ($groupNode->children() as $itemKey => $node) {
-                        if ($itemKey == 'member' && (string)$node != "" && (string)$node == $this_uid) {
+                        if ($itemKey == 'member' && in_array($this_uid, explode(',', (string)$node))) {
                            $auth_groups[] = (string)$groupNode->gid;
                        }
                    }


assuming the file is called /tmp/opncentral.patch, next run :

Code Select Expand

patch -p0 < /tmp/opncentral.patch

If this fixes your issue, we'll schedule a minor upgrade as soon as possible.

Best regards,

Ad

Hi Patrick,

Which user is logged in at the central node? are there any host groups configured? if not, does the browser console show any errors?

Best regards,

Ad

I expect nat reflection is enabled (Firewall: Settings: Advanced) in which case https://github.com/opnsense/core/commit/25b2716325951a7cbd93bc42ca21179f46519c10 is likely the culrpit.

To install use the following:

Code Select Expand

opnsense-patch 25b2716325


We currently don't offer the option indeed (https://github.com/search?q=repo%3Aopnsense%2Fcore%20tls-crypt-v2&type=code)

Best check which process is busy first, from the (ssh) console, you can use the following command:

Code Select Expand

ps -axfu