NAT reflection rules being overruled by default deny rule

[ltcptgeneral]

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.

[ltcptgeneral]

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

[cookiemonster]

Not clicking on links but... I would check that you have disabled "block private networks" on the WAN intrface configuration and that your nat rule prob should work better with "wan address" as the destination.

[ltcptgeneral]

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).

[cookiemonster]

Reflection for port forwards should be enabled in this case I think, and you might (on this I am not certain) need to see if you need to disable the force gateway.

[ltcptgeneral]

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 both without any changes to behavior.