Why is port forwarding not easier?

[Patrick M. Hausen]

But that is no different ???

Interface, destination address, protocols, ports, ... all required just the same.

I don't get it this time  ;)

[Demusman]

Look at the picture he posted of the NAT page then look at the one I posted... You really don't get it??

Also, I would love to know what you can't give in pfSense.

[Patrick M. Hausen]

I'll take the time to do a visual comparison with comments this evening.

My problem with pfSense is not the config dialogs. One can argue they have a better structure and more helpful texts. But it always takes me an eternity to find things in that mess of a menu. It's the menu structure (or the lack of structure) that's bothering me where for me OPNsense does it way better. Once I'm on a config page, I know what I want to do and what all these fields mean, so ...

Kind regards,
Patrick

[franco]

Look at the picture he posted of the NAT page then look at the one I posted... You really don't get it??

No, which is part of the issue. Conceptually a software once written by the same authors cannot be all that fundamentally and conceptually different. The only difference is representation and your brain will fool you to think it knows everything and everyone else must be blind to see. Don't trust your brain. Explain what explicit change you seek.


Cheers,
Franco

[Patrick M. Hausen]

As far as I'm concerned the dialogs are 100% identical and the OPNsense one has got a much nicer and easier to read left-aligned layout. See attachment, please. I really don't understand what's preferable about the pfSense version.

[Demusman]

Don't trust your brain. Cheers,
Franco

"It's better to sit in silence and be thought a fool, than to open your mouth and remove all doubt."

[Demusman]

As far as I'm concerned the dialogs are 100% identical and the OPNsense one has got a much nicer and easier to read left-aligned layout. See attachment, please. I really don't understand what's preferable about the pfSense version.

Yeah, like we both already eluded to, it comes down to personal preference and there's no way to please everyone.
To me, the OPN version just all blurs together. There's no real "separation" between fields.

[Patrick M. Hausen]

The initial claim - and I really appreciate how we can debate potential UI issues in a civilised manner here - was that the dialog should be easier to use, especially for the novice user. I am still not sure how this can be achieved given the complexity of the task. Minor reordering and improvement of help texts - of course, if it helps.

[Demusman]

The initial claim - and I really appreciate how we can debate potential UI issues in a civilised manner here - was that the dialog should be easier to use, especially for the novice user. I am still not sure how this can be achieved given the complexity of the task. Minor reordering and improvement of help texts - of course, if it helps.

Agreed that we're probably getting off topic but I think it's still related.
As I said previously, NAT isn't he problem in my opinion. IOW, it is what it is, you have to know what you're doing to do it. But looking at your image, don't you think if it wasn't a big white page with some text and boxes on it, which really does just blur together, the "flow" would be much easier?
Could be just putting some dark lines between field to differentiate them would help.

I'm not saying I have all the answers and "my way is best", but I can guarantee you I'm not the only one who says the interface needs improvements. Just speaking from people I personally know who've pointed out the same things I'm saying.

[franco]

Hmm, I think there are multiple "dark" themes to install if that helps improve the experience already.


Cheers,
Franco

[lilsense]

Hmm, I think there are multiple "dark" themes to install if that helps improve the experience already.


Cheers,
Franco

I wish there were a bunch of themes like freshtomato... :)

https://tomatothemebase.eu/

[flac_rules]

Partly agree to the ordering issue and the help texts csn definitely be improved. Destination ... well ... systems outside can't talk to your internal private address hosts. That's why you need a port forwarding NAT in the first place. So drom the point of view of the systems outside they talk to one WAN address of the firewall. And there might be a couple of them, so the admin needs to pick one.

Every firewall product I used in the last decades worked exactly this way.

Pick from leases ..  well, that's a matter that has the potential to lead to heated debate. Common consumer routers like the ubiquitous (in Germany) Fritzbox do this. I for one don't want any of that. Neither do I want any DHCP lease leading to an automatic DNS entry. I hate it when random devices connected to my network create artefacts in my carefully curated DNS zone or firewall policy.
Worst of all theses products create port forwards to deviced with dynamic leases and are completely intransparent about how they address and track those devices. Device gets new IP address - does the port forward follow? New device gets old IP address - what now?

I really want the thought process

- ok so my son wants to run Minecraft and open it up for his friends
- that means static IP address internally
- that means DNS entry for bookkeeping
- that means firewall object (alias in OPNsense) with that IP address
- and finally port forwarding rule

That's exactly how it should be in my book. Magic automatic things like assigning a firewall rule to a dynamic lease tend to explode and make a mess at some time in the future.

Thanks for the feedback!

Patrick

I know why it is needed, but it is imho not clearly worded. What is the "destination", destination of what? It could just as well be the destination on the LAN.

I don't think a list is complicated, you choose some suggested ips from the list, because (at least me) you don't rember every single IP on your network. The port forwarding goes to the IP. If people don't understand dynamic and static leases they certainly won't understand the rest of the dialogue imho.

I like the other suggestion for the setup as well, it groups related things together in a more understandable manner.

[franco]

It's rather simple really. Destination is the address of the packet in the destination address field at the time of the rule evaluation. This is basic matching on IP header information. Not magic.

I understand the motivation to make it simple, but without basic networking knowledge port forwarding makes no sense whatsoever.


Cheers,
Franco

[flac_rules]

It's rather simple really. Destination is the address of the packet in the destination address field at the time of the rule evaluation. This is basic matching on IP header information. Not magic.

I understand the motivation to make it simple, but without basic networking knowledge port forwarding makes no sense whatsoever.


Cheers,
Franco

I have basic networking knowledge. I know what port forwarding does. That doesn't make "destination" non-ambiguous in a network setting. The machine you are sending to on the LAN is also a destination address with an IP in the header. Understanding the concept of the address in the incoming packet isn't the problem, the problem is that it is not clear enough that "destination" talks about this particular thing. (and that the default isn't the "most normal" choice.)

[franco]

I would tend to disagree, unless you want to imply the concept of "source" and "destination" in all NAT types and firewall rules is ambiguous. I might agree, but I haven't witnessed a single discussion that brought that particular argument.

You may think this qualifies as a strawman, but I'm simply wondering why nobody brought this up before in clarity after decades of this code existing. It's strange.


Cheers,
Franco