Messages

What is the approximate timeline for when ISC DHCP is going to be removed from OPNsense?


1 quarter?  1 year?  5 years?

I tried to follow this whole thread but found it a bit confusing.


For anyone who happens to be running PCengines APU2-series boards, all 3 of my APU2-based opnsense boxes, running ZFS,  applied the 24.7.2 update without any problems.  No kernel panics or other weirdness.

Update process was smooth on (3) different bare-metal PCengines APU2-series boxes.  Two APU2E4s and 1 APU2C4. (4GB RAM in each device.) All upgrading from 24.1.10.

Interestingly, upgrade time varied from as short as 5 minutes to as long as 16 minutes.

All settings appear to have been preserved. Multiple site-to-site wireguard VPN tunnels came back up without any tweaking.

I'm not sure what I think of the new dashboard yet. Widgets all seem broken but I'm sure this will get worked out eventually. Dashboard + widgets are cosmetic, not required.

Why did you go with 23.x and not 24.x?

... Because 23.x was what was current as of the date of that post, circa July 2023...


I don't use Suricata, Crowdsec, or Suricata..

If I had to publish a read-only status page for a router or other security-senstive device on a LAN, I would not expose any part of the actual device's web interface to end users.

I'd write a script running on a bastion host or similarly-purposed separate device to collect the router's status info using curl or perhaps even an API call to the router, & then reformat & republish the collected info on a separate web server. (Not hosted on the router itself.)

To the best of my knowledge, all Wireguard settings, tunnels, keys, etc. are preserved in the main config.xml file which is the "master configuration" for an OPNsense instance. No special or separate backup of WG settings should be required in a normal backup / restore scenario.

Interesting. I tried adding all those tunables (via the GUI) to my OPNsense instance, then re-testing using the physical 1Gb ethernet setup I described earlier and same iperf3 options. No discernable difference at all, still tops out at about 600 Mbps.

Before you do much else I would contact the ISP, 2nd tier tech support or higher, and confirm their policy on customer-provided equipment. If they're blocking you, not a lot of sense tearing your hair out to try to figure out what's wrong on your side.

Sorry for the excess posts, I just noticed also that OP is running a PPPoE WAN connection.

Multiple articles & forum threads on APU2-series over the past several years indicates that PPPoE WAN tends to severely limit throughput because, as I understand it, by nature PPPoE only allows a single network connection at a time.

In my single TCP connection testing with APU2, the max throughput I saw under best-case LAN conditions was just 137 Mbit / second. The only way I could achieve 600Mbit per second described in earlier posts was by running multiple connections at once.

I will add further --

Several years ago, circa ~2018 to 2020 or so, there were posts and articles floating around demonstrating how to achieve true 1Gbps (actually ~950Mb/sec) throughput with an APU2-series device + pfSense (and possibly OPNsense), but this was under earlier versions of FreeBSD.

From what I gather, core aspects of the network stack have been changed in some ways in more recent versions of FreeBSD that "break" those older optimizations, perhaps making it no longer possible to achieve that ~1Gbps throughput.

If that is the case, probably at least part of what is going on is that the APU2-series boxes use a CPU that is now fully 1 decade old, and there is no longer much interest in trying to squeeze performance out of it.

Probably if one wants to route 1Gbps-and-more under recent or current versions of OPNsense, the simpler approach would be to upgrade to much more recent hardware with more basic CPU power. (And good Intel™ NICs, not Realtek or other derivatives.)

In my case, my WAN ISP connection is only ~95 Mbps and I have no need for anything beyond 500 Mbps on the LAN side, so I'll continue to use my trusty APU2E4 for the time being.

A lot of reading I've done of many older threads on this topic seems to suggest that with OPNsense running on a PCEngines APU2E4 the max achievable throughput on a single NIC may be ~600 Mbit second under ideal conditions.

I have an APU2E4  (which has the Intel 210AT NICs, i.e. "the good ones,") and have been doing some iPerf3 testing recently to see "where things are" with max theoretical performance.

In the following hardware setup:

MacBook Pro 16" M1 laptop --> Belkin 1GB USB-Ethernet converter --> new 7' long "Cable Matters™" Cat6e patch cable --> APU2E4 igb2 port, configured as a simple no-vlan static IP subnet.

And this OPNsense version:

root@myhost# uname-a
FreeBSD myhost.mydomain.com 13.2-RELEASE-p10 FreeBSD 13.2-RELEASE-p10 stable/24.1-n254984-f7b006edfa8 SMP amd64

And the following iPerf3 settings:
server (running on the APU2E4 Opnsense box):

Code Select Expand

iperf3 -s

client (running on the MacBook Pro 16" M1Pro):

Code Select Expand

iperf3 -c 192.168.7.1 -w 1MB  -P 8

the results look like this:

Code Select Expand

[SUM]   0.00-10.00  sec   724 MBytes   607 Mbits/sec                  sender
[SUM]   0.00-10.01  sec   710 MBytes   595 Mbits/sec                  receiver


So far, no settings of any kind within OPNsense GUI (Interface --> Settings, or System --> Settings --> Tunables) seem to make any impact at all. Neither does enabling / disabling the firewall, or enabling/disabling the 2 small /low bandwidth Wireguard tunnels I have configured.

Granted, it may be that this limit is due to trying to run iperf3 (in server mode) ON the OPNsense box itself. At present I only have 1 laptop to test with, no other devices. Perhaps if I get a second laptop + ethernet adaptor and try the iperf3 test between the two laptops, routed through the OPNsense box, I will see higher bandwidth because OPNsense / BSD kernel is not busy trying to run iperf itself during the test.

I know the parent doesn't need to be assigned, but then it's just sitting there in the little drop down where it could be assigned by accident.  That's why I assigned it a disabled interface.

I noticed this. When set up my VLANs I assigned a primary interface for each because I thought it was required.


Now I see there's no way to unassign them through the GUI. Is this an oversight in GUI design that could/should be fixed?

Replying further, as I found another relevant thread on this turbostat core-dump issue:

https://forum.opnsense.org/index.php?topic=30148.msg145554#msg145554

In my case, I think I did install the most-recent version of turbostat, but it's still crashing. Oh well, I guess no resolution at this time:

Code Select Expand

root@myopnsenserouter:~ #  file /usr/local/sbin/turbostat
/usr/local/sbin/turbostat: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.2, FreeBSD-style, stripped

root@myopnsenserouter:~ # uname -a
FreeBSD myopnsenserouter.mydomain.com 13.2-RELEASE-p10 FreeBSD 13.2-RELEASE-p10 stable/24.1-n254984-f7b006edfa8 SMP amd64

I don't think I'm necro'ing this thread since I'm using identical hardware (APU2E4,) just on a later version of OPNsense which may have broken something.

My system:

Code Select Expand

root@myopnsenserouter:~ # uname -a
FreeBSD myopnsenserouter.mydomain.com 13.2-RELEASE-p10 FreeBSD 13.2-RELEASE-p10 stable/24.1-n254984-f7b006edfa8 SMP amd64

I installed turbostat, and after successfully loading the kernel module:

Code Select Expand

kldload cpuctl


when running turbostat it executes and appears to start OK, but after 5 seconds it core-dumps:

Code Select Expand

root@myopnsenserouter:~ # turbostat
turbostat version 17.06.23 - Len Brown <lenb@kernel.org>
CPUID(0): AuthenticAMD 13 CPUID levels; family:model:stepping 0xf:30:1 (15:48:1)
CPUID(1): SSE3 MONITOR - - - TSC MSR - -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
NSFOD /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver
Floating exception (core dumped)



Here is the dmesg output:

Code Select Expand

pid 65735 (turbostat), jid 0, uid 0: exited on signal 8 (core dumped)

My intuition is that the device tree or device names have moved & turbostat is simply crashing because it can't find the device to sample?

Any further hints or comments as to how to fix this, or if turbostat's functionality is broken by changes in OPNsense over the past couple years?

....But here I can't see the point as the traffic is checked but not blocked without IPS anyway, so I can't see why this would cut the download performance that hard.

What is the make,  model, & specifications (RAM amount, CPU speed, # of CPU cores, etc.) of the hardware your OPNsense instance (router) is running on?

What is the bandwidth of your internet connection, in Mbps or Gbps per second?  Fiber? Cable? Which provider?