Messages

Hummm, I thought they had implemented that patch, but oh well. Thanks for putting it in for testing.
I haven't encountered any other problem as of yet.

[Problem:]

I had encountered this same problem with Version 24.7, and seeing that there was Version 25.1 in Beta, I thought to see if this problem was resolved.
Unfortunately that is not the case as the problem remains.
Fortunately there is a fix for it, which I will provide the steps below.

Problem:
When using OPNsense v25.1 (and v24.7) as a virtual machine within XCP-ng (and Xenserver) there is a problem of false reporting by FreeBSD v14 of Interrupts to Xen. This then causes health monitor checks with the CPU as reading high utilization while at idle (high 50%). When at the OPNsense Dashboard, the CPU widget indicates high usage, as well as, along with the Netdata plugin if used. Installing the Xen Tools plugin has no effect.
However, the hypervisor indicates minimal CPU utilization. Additionally Bandwidth performance is not impacted.

Mitigation:
Applying a patch and rebuilding the kernel from sources solves the problem. For long term purposes, is to recommend this patch corrections to the Xen files into the development repository for testing. If acceptable to be part of the production build.
So far after applying this patch have not experienced further problems.
This also worked for both versions of 24.7 and 25.1.

Patch Reference: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277231
Actual Patch: https://bz-attachments.freebsd.org/attachment.cgi?id=248948

Steps for Applying the Patch:
NOTE: These are the steps I took. For actual patching, many steps can be omitted.
Obtain the Patch
1. Go to:   https://bz-attachments.freebsd.org/attachment.cgi?id=248948
2. Copy the entire patch page as is.
2a. Select All (CTRL-A) and Copy (CTRL-C)

Implement Patch
1. Once OPNsense is ready, open PUTTY for SSH connection and login.
2. At the OPNsense Shell, type in "8" for Shell and hit Enter.
Perform Verifications:
3. Verify Interrupt usage:

Code Select Expand

top -P4. The top portion of the screen should indicate high readings of Interrupts.
4b. Hit CTRL-C to cancel the Top Monitoring.
5. Verify the current Kernel:

Code Select Expand

uname -aExample:

Code Select Expand

FreeBSD OPNsense.localdomain 14.2-RELEASE FreeBSD 14.2-RELEASE stable/25.1-n269579-cd5d25393d6 SMP amd646. Verify Disk Space Usage before patching.
6c. Check how much disk space is being used by build files:

Code Select Expand

du -h /usr/obj
du -h /usr/src6d. Make a note of the size, for example 512B (empty). Basically, should be empty.

Create the Patch File:
7. Navigate to a temporary directory

Code Select Expand

cd /tmp8. Create a new file called 277231.patch

Code Select Expand

vi 277231.patch9. Paste the entire patch content as-is:
9a. Press "i" to enter insert mode.
9b. Paste the patch content (right click only).
9c. Press Esc to exit insert mode.
9d. Type ":wq" to save and exit.

Apply the Patch to the Source Code:
10. Navigate to the source directory where the affected files are located:

Code Select Expand

cd /usr/src11. Download the OPNsense source code:

Code Select Expand

opnsense-code src12. After the source code has been transferred, verify that the required files now exist:

Code Select Expand

find /usr/src -name xen_intr.c
find /usr/src -name xen_arch_intr.c13. Apply the patch:

Code Select Expand

patch -p1 < /tmp/277231.patch
Build the New Kernel:
14. Create the OPNsense Kernel Config File, by copying the GENERIC kernel config as a starting point:

Code Select Expand

cp /usr/src/sys/amd64/conf/GENERIC /usr/src/sys/amd64/conf/OPNsense15. Rebuild the Kernel:

Code Select Expand

make buildkernel KERNCONF=OPNsenseNOTE: This will take some time to complete, approximately 35 minutes if using x12 CPUs and 12GB RAM.
16. If the build completes successfully, should see something like:

Code Select Expand

>>> Kernel build for OPNsense completed on Sat Jan 6 12:34:56 UTC 2025
Install the New Kernel:
17. After the build completes, install the new kernel:

Code Select Expand

make installkernel KERNCONF=OPNsenseNOTE: This will take some time, but much less than the previous build.
18. Once the kernel is installed, reboot the system:

Code Select Expand

reboot
Verify the New Kernel
1. After OPNsense comes back online, log in via the Web GUI.
2. The CPU Widget should now appear with low CPU Utilization.
3. Open up a SSH connection and login.
4. Verify that OPNsense is running the new kernel:

Code Select Expand

uname -aExample:

Code Select Expand

FreeBSD OPNsense.localdomain 14.2-RELEASE FreeBSD 14.2-RELEASE #0 stable/25.1-n269581-b4fca65e6b8-dirty: Sun Jan  5 02:41:21 UTC 20255. Verify that the interrupts issue is resolved by running:

Code Select Expand

top -P6. Check the intr column to ensure that interrupt usage has decreased.

Clean Up Build Artifacts
With the new build completed, now it is time to clean up.
1. Run the following commands:

Code Select Expand

cd /usr/src
make clean
rm -rf /usr/obj/*
rm -rf /usr/src2. Verify Disk Space Usage

Code Select Expand

du -h /usr/obj
du -h /usr/src3. Reclaim Space from Old Kernel Files, by running the following commands:
3a. Check the size of old kernels:

Code Select Expand

ls -lh /boot/kernel.oldIf there is a return of files, then perform the following command to remove them:

Code Select Expand

rm -rf /boot/kernel.old
That completes the steps for the patching.


Of note, I tested v25.1 directly on the hardward and did not have this issue. Appears to be only with Xenserver related systems.

Ah, perhaps like this:
- WAN1 (11.11.11.11) receives the packets and passes onto WAN2
- WAN2 (22.22.22.22) then sends the packets to the Website
- The Website (33.33.33.33) processes and returns the packets back to WAN2
- WAN2 receives  the packets and passes back to WAN1
- WAN1 sends the packets back to the user

I was able to get it working... well, with multiple devices in between, rather than a single firewall. Mush like a Port Forwarding daisy chain with NAT Outbound Rules.
But for two interfaces on the same firewall, I haven't been able to try yet.
But it does look like it is of:
- WAN1 Port Forward to WAN2
  (WAN2 will then send the packets to the website on its own, as it has its own Gateway)
- NAT Outbound to Manual, with Rule set:
-- Interface: WAN2, Source: Any, Source Port: Any, Destination: The Website's IP, Dest Port: HTTP (as example), Translation: Default, Trans Port: Default
--- Repeat for any other Ports

At that point there should be no rules needed for the returning packets, as the NAT Outbound would be returning those packets to WAN1.

Does that make sense?
I am hoping to give that a try later in the week.

I have been able to send traffic, but only with one interface (not ideal for a few reasons).
- Port Forward from WAN (11.11.11.11) from Source: ANY to Destination: WAN Address (11.11.11.11) Port HTTPS, Redirect: 33.33.33.33 Port HTTPS
- NAT Outbound to Hybrid (or manual)
-- Rule set with WAN Interface, Source: ANY, Destination: 33.33.33.33, mapped to WAN Address

But to get it to the Second WAN Interface (22.22.22.22), though it should work similar to above:
- Port Forward, same as above, but Redirect to the Second WAN (22.22.22.22) Port HTTPS
- NAT Outbound similar, but replace First WAN with the Second WAN in both cases.

Trying to load balance for incoming traffic from an external source, well that is different as normally for outgoing traffic from internal sources. I think you may need to explore a plugin for that purpose.
But may work... though not likely, have you tried to use just, "This Firewall" as the Destination?

If I understand correctly, you are using a dual firewall arrangement (OPNsense and Cisco ASA), which therefore likely to have Double NAT'ting going on. Assuming that both the OPNsense and ASA are set to NAT'ting.
If that is the case, you can either place the ASA or OPNsense to use Static Routing, depends which is easier.
In this arrangement, the ASA would be best to do so as it has just one internal link.
Unfortunately, I do not know how to do the Static Route for the ASA.

I have done static routes for a forward OPNsense firewall, but since this is at the backside, it should be the one handling the NAT'ting. Reason would be due to the amount of manual work needed for it and if different networks are involved.

For the ASA, the Static Route would need to designate then internal network (the link between the ASA and OPNsense; example 10.1.1.0/30 - ASA:10.1.1.1 OPN:10.1.1.2) and likely need a Gateway with it. Then if the ASA has something like OPNsense NAT Outbound, it would be to (in OPNsense terms) set to Manual and create a Rule in which the WAN interface is tied to Source Address of the Internal Network (10.1.1.0/30), the Destination Address would be blank.

Ah, glad you got it working.
I would recommend though to update to the latest version, unless there are legacy reasons not to of course.

Thank you for the reply.
M'yeah, NAT'ting is the issue for me trying to solve, which if disabled, then would static routes be used?
Outside of that trying to figure of how to pass the traffic from the 11.11.11.11 Interface (in the diagram, from user) to then go out from the 22.22.22.22 interface for its way through the Internet to 33.33.33.33 webserver. As the 33.33.33.33 IP Address is out of the 22.22.22.22 subnet.

I used "Client" to refer to as a remote site, that is not part of the internal or local network. When using the word "remote", majority of the searches lead to "remote access", hence avoid using it. In this case, can replace 'client' with 'remote site'.

If an IPSec tunnel is used, I think would make things easier (and secured) as it would be then a matter of Port Forwarding or Static Routing as the IPSec tunnel would have its own private IP network. Unfortunately, not able to take that option.

A couple of possibilities:
- Just in case this was not done, to be Capt. Obvious... shutdown the machine and remove the ISO. Power up and see if it works.
- Otherwise, the WAN's IP Address with DHCP may be of the same subnet (192.168.1.0/24) and I have seen causes issues when it is the same as the LAN's IP. Before installing, log in as "root" and change the LAN IP schema to something else, like 192.168.2.1 /24. Then log out and log in as "installer".

When changing the WAN Static IP, for the Gateway, have you tried with creating a new Gateway from within the WAN Interface?
That is, at the WAN Interface Config page, scroll down to IPv4 Upstream Gateway (I assume IPv4), and click the Plus sign (+).
- Select Default Gateway (checked)
- Provide a unique name (ex: WAN_GW_New)
- Gateway IPv4, set to the ISP's Gateway IP

This may work rather than creating a Gateway in the Gateways Menu (within System).

I am attempting to see of how to implement OPNsense as a WAF in which the target system is an external site and not internal. I have provided a simple diagram to help better explain it.
I have done searches and reviewed of HAProxy and Nginx, but have not been able to crack the puzzle of using another Public IP and not a Private IP, and especially of when the Public IP's are all different from another. So a networking issue I am trying to solve.

So the problem is:
A user types in a domain name (URL), which then goes to the assigned Public IP (ex: 11.11.11.11) from the DNS Records. This IP is the WAF's WAN, from which it exits from another interface (ex: 22.22.22.22) to then go back to the Internet to the client's Public IP. I assume that the WAF will need two Public IP's to support this.

I do understand there are some weaknesses, such as an attacker will discover the client network's IP and bypass the WAF.

So what is the setting or requirements to allow for this work properly?
Example, one WAN and an OPT (or LAN) configured with their own Public IP's, but then is there a 1:1 NAT involved? Or use HAProxy/Nginx with the target IP being the Public IP of the client.
Or is there material that helps to explain this that I have not yet found (And if so... where)?

I concur with the increase in CPU utilization, system loading and unstable packet performance with the latest update.
Using a virtual platform (Xenserver) with pass through network interfaces and clean install. Disabling Suricata and Netflow seems to help, but the WAN gateway is unstable (packet losses). Bandwidth also seems to be impacted as well.