Messages

Yep, its not throwing the error anymore. Thanks!

@franco Any steps to trying this patch? Should I just copy the changes to the file locally and then restart the web interface?

I've managed to successfully migrate the FW rules to the new interface, but Opnsense throws the following error if I try to do step 5 (deleting the legacy rules):

Code Select Expand

[28-Feb-2026 00:05:49 America/Los_Angeles] ReflectionException: Class "OPNsense\" does not exist in /usr/local/opnsense/mvc/app/library/OPNsense/Core/ConfigMaintenance.php:62
Stack trace:
#0 /usr/local/opnsense/mvc/app/library/OPNsense/Core/ConfigMaintenance.php(62): ReflectionClass->__construct('OPNsense\\')
#1 /usr/local/opnsense/mvc/app/library/OPNsense/Core/ConfigMaintenance.php(42): OPNsense\Core\ConfigMaintenance->loadModels()
#2 /usr/local/opnsense/mvc/app/controllers/OPNsense/Firewall/Api/MigrationController.php(48): OPNsense\Core\ConfigMaintenance->__construct()
#3 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Dispatcher.php(166): OPNsense\Firewall\Api\MigrationController->flushAction()
#4 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(156): OPNsense\Mvc\Dispatcher->dispatch(Object(OPNsense\Mvc\Request), Object(OPNsense\Mvc\Response), Object(OPNsense\Mvc\Session))
#5 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(139): OPNsense\Mvc\Router->performRequest(Object(OPNsense\Mvc\Dispatcher))
#6 /usr/local/opnsense/www/api.php(36): OPNsense\Mvc\Router->routeRequest('/api/firewall/m...', Array)
#7 {main}

This happens with or without legacy rules. There also seems to be ghost floating rules (which don't actually exist in the legacy floating rules list). As far as I can tell, this is just an API issue, and the migrated FW rules are working fine.

Update:

I have at least isolated the problem. The nginx server has multiple interfaces, one on the LAN and DMZ VLAN. Nat reflection does NOT work when mapping to the DMZ VLAN address, but DOES work when pointed to the LAN address. However, a different nat port forward works just fine on a different host which only has one interface on the DMZ VLAN. Additionally, no VLAN clients can connect to the nginx server (when mapped to the LAN) even though LAN hosts can connect to the nginx server without issue.

Basically:
port forward WAN -> LAN: only LAN clients can access, VLAN clients cannot connect

For the time I've figured out the following workaround:
- NAT port forward to nginx on the LAN interface
- attach any required nginx upstream backends to the LAN interface

I have already created a floating rule allowing any net to the NAT target. And as I mentioned, I have already disabled block private networks. Opnsense still claims that the connection is being denied due to default deny / state violation rule.

Reflection is set to "use system default" in the NAT rule, as is the case for the documentation for NAT reflection (I'm following method 1). I've tried enabling reflection and disabling force gateway without any changes to behavior. If you reference the screenshot, it seems that the rdr is applied correctly, but the firewall blocks the traffic redirected to 10.0.1.2.

I've attached the linked image, I just had to downscale it a bit. Block private addresses is already off on WAN, and the WAN address for opnsense is always 192.168.86.2 (dhcp reservation).

Adding that from the same LAN client, I am able to directly use wget/curl to 10.0.1.2:80 without any issue, and there is not generally any other firewall rules blocking LAN -> DMZ connections. Looking at the firewall log, I can see that the same connection (from the POV of the firewall) is blocked when the result of the rdr rule, but passed if it is a direct connection.

Firewall log: https://drive.google.com/file/d/1fHwGOXNZeLku4mB2D3xY2U96TWPebs2T/view?usp=sharing

I'm following the documentation guide on setting up NAT reflection. Like in the guide, I have an nginx server and want to use NAT reflection to allow WAN, LAN, and DMZ clients to use the reverse proxy. The only difference I can tell from the documentation is that my nginx server has multiple interfaces, including one on the LAN.

I have set up the DNAT rule:
Interface - WAN, LAN, DMZ_VLAN
Source - Any:Any
Destination - 192.168.86.2:8080 (the opnsense WAN address, as it is currently behind another NAT)
NAT - 10.0.1.2:80 (the nginx DMZ IP address)

This should already allow LAN and WAN clients to connect to the server. WAN clients are able to connect. However, this is not working for LAN clients, and I can see in the firewall log that the default deny rule is being applied. I enabled the automatic firewall rule generation like in the documentation, which I can see has already created a floating rule that should allow LAN and WAN clients through to the DMZ address.

However, this is not the case, and when I use wget/curl from a LAN client fetching http://192.168.86.2:8080, I can see that the firewall is blocking the traffic using the default deny rule. This is despite the generated rule allowing any source to 10.0.1.2:80 on LAN, WAN, and DMZ interfaces.

Strangely, another port forward to another host on port 22 is working properly from both WAN and LAN clients, although this host does not have multiple interfaces.

Seriously, if you want fine grained control, the firewall rules are where you enforce it. There is no higher level abstraction in OPNsense.

I agree, but surely for a large number of VPN connections reflecting the OpenVPN options to the firewall automatically would be more secure than having a human manually perform this?

I could do this, but I would need to create rules for each OpenVPN interface because each one gets access to a different LAN subnet. I would like to avoid setting up individual rules for each connection because I've already specified which subnets i want to give access in the "local network" setting.

I have several OpenVPN server (legacy) setups with specific attached Local Network options for each one. However, a connected user can still connect to anything on the LAN network because of the "let out anything from firewall host itself" floating rule regardless of the Local Network value. Is there any way I can block this behavior without setting up individual rules for each VPN interface. Also, this behavior only started when I updated to 24.7.

I put the VPN server on its own interface and subnet range and bridged it with the existing VLAN. I also enabled interclient communication. Neither allowed the client to get a gateway

I'm already using VLANs regardless of the OpenVPN setup, it automates routing permissions. My hope is to attach clients to their VLAN directly, avoiding extra manual work in defining rulesets for each client.

I will take a look at your suggestions using a bridge between the OpneVPN interface and VLAN interface.

Another observation, the client has received IP address 10.0.2.6 with a subnet mask of 255.255.255.252.
In the configuration, the client's tunnel network should be 10.0.2.0/24