Port Forward reply to not getting set correctly

[EkiciLP]

Important notices

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

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] 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

Describe the bug

In a Multi-Lan setup with a VPN und a WAN: When Port-Forwarding (IPv4) from the VPN to any internal device the replies from that device always get routed through the default WAN (The Policy routing that should route all the traffic from that machine through VPN is ignored).

To Reproduce

Steps to reproduce the behavior:

1. Have a Wireguard VPN and normal WAN
2. Create a Port-Forward from the VPN to any machine in the local network.
3. See (using tcpdump) that replies to these requests get routed through the normal WAN

Expected behavior

The Replies should go back to their sender.

Describe alternatives you considered

When removing the auto-generated the traffic rule from the port forward and defining one myself setting reply-to to the VPN Gateway works. So maybe the reply-to in the auto generated rule is not set correctly?

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 24.7.a_388 (amd64). Intel® Core™ i3-4160 3.6Ghz Dual Core Network Intel® I350-T2

[Monviech]

Hey, you can read about what to do here, its explained in one of the notes:

https://docs.opnsense.org/manual/how-tos/nat_reflection.html#method-1-creating-manual-port-forward-nat-dnat-manual-outbound-nat-snat-and-automatic-firewall-rules

[EkiciLP]

Does that mean this is intended behavior? In my opinion its kind of tedious to always have to add both a Port Forward and a Firewall Rule. Can't that be automated?

[Monviech]

You could create the Port Forward and the Firewall rule manually, and use Aliases inside of them. Then if you update the aliases, for example adding another port/ip address, both the Port Forward and the Firewall rule would be updated automatically.

[pernu]

It seems a lot of people (including myself) have ran into this problem and probably spent an hour troubleshooting the issue and finding the reply-to solution eventually. It seems some small improvements could minimize this issue.

For one, I think it might be useful for the NAT doc page to explicitly talk about this issue (there's some mention in the reflection page, but it's an ambiguous explanation and a clear explanation belongs in the main NAT page). Secondly, the help string for "Filter rule association" in the Port Forward creation page, should probably also mention something in there as well. Those would be two very easy enhancements (I'm happy to contribute a change to the help string).

I think it would be very helpful in the Port Forward creation page, under the "Filter rule association" dropdown menu, if there was an additional option called something like "Add associated filter rule with symmetric routing", that would create an associated filter rule with the "reply-to" always set to the Interface chosen at the top of the form. The current approach of applying some logic (that's not clearly explained anywhere in the interface or the docs) to determine whether or not to use "reply-to" in the pf rule, is part of the problem, on some interfaces it works as expected on others, it doesn't.

Finally, the other issue that compounds this even further, is the fact that associated rules don't show the "reply-to" status in the Web UI (since you can't edit them, you can't see the details), so you have no visibility on what the logic that decides on whether or not to use "reply-to", has chosen to do for this interface. The only way you can find out is by using pfctl -sr and grepping for the rule that was created. It would be helpful to add a small icon or some other indication of the reply-to status (or allow the rule to be inspected, just not edited).

One other related suggestion is that it would be great if it were possible to clone associated filter rules (especially the ones that are unassociated, which surprisingly are not editable either, even though they created unassociated).

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.