[SOLVED] Port Forward rules do not respect the "Interface" field

[REB00T]

When adding a port forwarding rule for a certain interface or set of interfaces, the expected behaviour would be for that rule to apply only for the interface(s) selected, even if the source field contains a "superset" of the subnets of those interfaces. In essence, the rule should apply to the "intersection" of the "source" and "interfaces" fields, assuming I understand the meaning of the "interfaces" field correctly.

Currently, the interfaces field seems to be ignored when applying said rules, leading to unexpected results.

There is an issue reported on GitHub (https://github.com/opnsense/core/issues/7952) that has, erroneously in my opinion, received the "support" label. Since it does not seem to be getting any attention, I assume because of that, I thought posting this here would help in bringing some much wanted attention, or at the very least acknowledging, said issue.

[dseven]

Is it possible that you have NAT reflection enabled? If it's enabled globally, it'll apply by default to any new port forward that you create, unless you explicitly disable it.

[REB00T]

Reflection is turned off in the Firewall->Advanced menu, following a piece of advice I had read on here some time ago.

[dseven]

Hmm. I can't reproduce this so far, then. When I create a port forward with reflection disabled for my guest network (VLAN 5), the result is:

Code: [Select]

root@opnsense:~ # pfctl -s nat | grep -i '^rdr .* port = domain'
rdr on vlan0.5 inet proto tcp from any to ! (self) port = domain -> 10.1.5.1 port 53
rdr on vlan0.5 inet proto udp from any to ! (self) port = domain -> 10.1.5.1 port 53
root@opnsense:~ #

and if I try to do DNS to some random IP address from my LAN, it doesn't get redirected (just times out), but if I create the same port forward on my LAN interface, DNS does get redirected (and works).

[Bob.Dig]

even if the source field contains a "superset" of the subnets of those interfaces.

What Source Field. Maybe share a screenshot of your discoveries. 

[REB00T]

I sincerely apologise, it was late when writing this. Turns out the service I was testing with was being accessed via ipv6, making me think the redirect was working but not being logged for some reason. It didn't occur to me at the time of writing that I had set it up for ipv6. Very sorry for being a hassle.

[Patrick M. Hausen]

No problem. The NAT reflection checkbox and its surprising results is in good company of quite a number of other things that perform "unintuitive magic" in OPNsense. Like the anti lockout rule or the whole name server for OPNsense itself thing, or automatic firewall rules that open UDP 500/4500 for IPsec peers.

I hope that step by step we can get rid of most of this in future versions. There has been some progress already from which I read that the lead developers agree to at least some degree. Still this needs to be done with care and step by step.

I guess all of these "automagic" functions come from an intention to provide a smooth experience to less knowledgable users. Like in the typical consumer router product.

As an experienced network engineer I absolutely prefer explicit configuration over implicit "magic". One reason being that explicit configuration is to a certain extent self documenting.

OK, I walked entirely off-topic. Enough for now.

Kind regards,
Patrick