DNAT auto firewall [Register Rule/Pass] fails in multi-gw setups + how to fix it [26.1 series]

[seccentral]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

On deployments - 26.1 series - with multiple gateways, opting for automatic firewall rule creation via "Register rule" or "Pass" creates rules that do not include the advanced mode "Reply-to:" configured, so if a query comes via GW1 it will probably return via GW0 and be dropped.

Describe the solution you like

Solution is to set to manual and enter your desired reply-to gateway in the dropdown.

Describe alternatives you considered

N/A

Additional context

https://forum.opnsense.org/index.php?topic=50571.0

[AdSchellevis]

are you sure the proper pre-requisites are set? On my end (with a WAN interface including a gateway) the reply-to is nicely added in the same way as it would with the old code when using register rule (and adding a dnat rule on the same wan interface).

[evilantishad0w]

@AdSchellevis I've been having the same issue and setting reply-to isn't working right. I did notice that communications is also hitting the outgoing autogenerated rule "let out anything from firewall itself" and that it might be breaking the reply-to chain somehow.

I really wish the automatic "pass" setting in the Destination NAT entry would also add the "reply-to" setting automatically.

[AdSchellevis]

pass is a pf feature and doesn't add reply-to see also man pf.conf, the "Register rule" mode should add reply-to as it does on my end.

[evilantishad0w]

Okay. I'd tried it on all three modes (pass, register rule, and with a manually generated rule) and none worked to pass traffic properly.

[AdSchellevis]

relevant information would be:

• last known working version
• current interface settings
• rules created related to the case
• generate pf rules of the problem in question (extracted from /tmp/rules.debug)

[evilantishad0w]

I currently have things worked around switching the gateway I use for service to primary and routing all my internal traffic out the other gateway, which breaks my failback but works for now, and I don't want to revert everything to generate this information and knock my servers out again.

Please replicate by:

1. Installing fresh copy of opnsense, updating to latest version
2. Adding 2nd WAN gateway
3. Adding simple server to LAN
4. Creating Destination NAT entry for server from secondary gateway

If this does work as expected please give details on the firewall rules you added.

[AdSchellevis]

and I don't want to revert everything to generate this information and knock my servers out again.

ok, so your asking us to spend time which you don't want to do to fix your problem. Community support is certainly not intended for that.

[evilantishad0w]

@AdSchellevis I guess you didn't notice I wasn't the one to create this topic. There are several other people who've run into this issue who've posted about it on the opnsense forums. I was just contributing my observations and my workaround. Sorry that was insufficient for you.

[AdSchellevis]

could be same as #9750

[evilantishad0w]

In my case it was the same port, so no.