Messages

[Update:]

I'm now at kernel 5.10.0-20-amd64 and OPNsense 22.7.11, and everything is working flawlessly. You state that you are on OPNsense 22.7. Perhaps upgrading OPNsense helps? As I've written, for me, it only started working again with later versions of OPNsense (e. g. 22.7.7).

If that doesn't help, perhaps trying a newer kernel (e. g. 5.x) is also worth a try?

I'm also on latest OPNsense 22.7.11-amd64. The next downtime I can try a more recent Debian kernel version.

Have you experienced a change between 4.x and 5.x Debian kernel versions?
Beside updating Debian kernel and opnsense - have you changed any other settings?

Since I virtualize pfsense or opnsense I need to switch off tx checksumming on every opnsense interface on the host opnsense is running, so for instance if opnsense has several virtual interfaces every time I start opnsense I need to run

Code Select Expand

ethtool -K ${int} tx off on the host for every single opnsense interface. With this issue discussed here there is no difference if I disable tx checksumming or not, but that's one of the changes I need to keep in mind.

Update:
I updated my virtualization host to kernel version 5.10.0-20-amd64 as well and can confirm that there are no more issues regarding "reconfiguring interface due to feature change".

Since 22.7.7 (at least that is the version where I noticed the change), this issue seems to have disappeared. I have the standard Debian Bullseye kernel 5.10.0-19-amd64 installed on Dom0, and OPNsense is running normally, all interfaces are up. No special kernel is needed anymore. Fingers crossed. :-)

I can't confirm that at least for Debian kernel linux-image-4.19.0-20-amd64 although I am on current opnsense 22.7. The last working kernel version for me is linux-image-4.19.0-18-amd64.

dd, gzip and ssh are in the base system. What else does one need?

True - but you need to boot from a live system at least to restore the data. If you have zfs you can from within the production system create snapshots and revert back without the need to boot from a live system. After rollback just a reboot is needed.

I'Ve done that with zfs snapshots, please see https://github.com/opnsense/plugins/issues/2976#issuecomment-1179162143

Have the same issue.

Tried opnsense 22.1.7, 22.1.8 and 22.1.9, neither one is working with dom0 kernel 5.10.0-15-amd64 or even 4.19.0-20-amd64. Moved back to dom0 kernel 4.19.0-18-amd64.

Hi all

I am looking for a quick&dirty way to setup some php plugin and hook it to the newwanip signal (to send emails on wan ip address change). It really should be simple in a way that future opnsense updates won't become a hassle.

I've got an idea how to create that plugin but I couldn't find any php mail libraries or something to send emails.

Does anyone have an idea or suggestion how to get this done by using php and keep the installation of new libs or patching the existing environment to a minimum?

Hi all

I have a self signed CA with the following structure

Code Select Expand

root ca
|
+--- intermediate1 - server certificates
+--- intermediate3 - client certificates for wifi and app authentication
+--- intermediate4 - site2site OpenVPN certificates
+-+- intermediate5 - for historical reasons: OpenVPN client certificates for road warriors
  +--- Server Certificate for OpenVPN server: "gw_openvpn4clients"
  +--- OpenVPN user 1
  +--- ...
  +--- OpenVPN user n


The opnsense server config for the OpenVPN server looks like:

Code Select Expand


Server Mode                     Remote Access (SSL/TLS)
Peer Certificate Authority      intermediate5
Server Certificate              gw_openvpn4clients


Clients can connect to the OpenVPN server using their client certificates issued by intermediate5.

Despite the setting of "Certificate Depth" also clients with client certificates issued by intermediate3 can connect - which I didn't expect as I thought the setting "Peer Certificate Authority" would limit access to certificates from this intermediate CA only.

In the Trust/Authorities section only the root CA, intermediate1, intermediate4 and intermediate5 are imported.

How can I configure OpenVPN to only allow clients with certificates issued by intermediate5 to connect?

Edit: I found a workaround by adding "verify-hash xx:xx:xx...;" to "Advanced" in the OpenVPN server setings. But it says that this option will be removed in future, so there might be a need for something else...
xx:xx:xx... is the fingerprint of intermediate5 in my case.

Thanks in advance,
spi

I moved to a separate freeradius server installation for full EAP-TLS and EAP-TTLS support with dynamic vlan assignment.

Check out https://forum.opnsense.org/index.php?topic=18754.msg85807#msg85807

So I put OPNsense on a PC that has an Intel PRO/1000 4 port NIC and an i7 2600, and with a default install I get my 450 mibt/s. Once I put a firewall rule in to enable fq_codel, then it drops to 360-380 mbit/s. I don't believe that an i7 at 3.4 GHz with an Intel NIC cannot handle these rules at full speed. What is wrong/what can I look at/how can I help make this better?

You can check with some of the performance setting tips laid out here https://forum.opnsense.org/index.php?topic=9264.msg93315#msg93315

I am going to try this in a day or two. IPfire is my choice right now, unless someone has a different suggestion. I will probably come back to OPNsense either way as I like this community and the project.

Yeah, I like opnsense as well. That's why it is so painful that in my setup the throughput is so limited. I did the tests with Debian and iptables on one hand and with openwrt on the other as it s available for many platforms and pretty simple to install on bare metal and in virtual environments.

I am curious if I am seeing this kernel problem on my bare-metal install. I have a passively cooled mini PC with 4 Intel NICs and a J1900 CPU at 2.00GHz and 4 GB of RAM. I know this CPU is fairly old, but the hardware sizing guide says I should be able to do 350-750 Mbit/s throughput. When I have no firewall rules enabled and the default IPS settings I get about 370-380 Mbit/s of my 400 Mbit/s inbound speed. If I enable firewall rules to set up fq_codel, then it drops my throughput to 320-340 Mbit/s. In both of these scenarios I see my CPU going up to 90+% on one thread. I do understand that my throughput will go down with different options like IPS and firewall rules, but I would think that with no other options running this hardware should be able to do better than 380 Mbit/s tops.

I wonder what throughput you would receive with a Linux based fw just to see what the hardware is capable of. I made the experience with the current opnsense 21.1 release that it gives me only ~50% throughput after performance tuning in a virtualized environment. A quick test with virtualized openwrt gave me full gigabit wire speed without any optimization needed. I know that's comparing apples and oranges but it's difficult to say what a hardware platform is capable of if you don't try different things.

Has anyone rerun the tests with opnsense 21.1?

Start with e.g. these (from this thread):

net.inet6.ip6.redirect = 0
net.inet.ip.redirect = 0
hw.igb.rx_process_limit = -1 (these are hardware dependent and will probably not match your NIC in the VM)
hw.igb.tx_process_limit = -1 (these are hardware dependent and will probably not match your NIC in the VM)

Thx - have these. Helped me to increase the speed (as mentioned in one of my posts). But still far away from Gbit.

I think you are mixing two things in this thread:

This thread is about the optimization of APU-based hardware devices, which can only do 1GBit/s when specifically optimized on FreeBSD.

The other issue could be performance problems of 21.1 on XEN based virtualization at best. There are already more participants here in the forum with this observation.

I would rather not discuss the XEN issue in this APU thread, as you are more likely to meet users who are also concerned.

Understood that this is specifically on APU-based boards. I observe also performnce issues and couldn't find anything somehow related for Xen. That's why I am interested in your observations - I'd give the performance tuning tips a try.