Why is port forwarding not easier?

[Patrick M. Hausen]

Destination is what is in the destination field of the IP header of the packet in question. Same for source.

[franco]

My good colleague pointed out the help labels are missing (ironically similar to pfSense). We could change that, but again to reiterate it would be best to change all NAT types and firewall rules labels for source /destination options and update the documentation accordingly to avoid future reports about the same thing.


Cheers,
Franco

[flac_rules]

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

I can only speak for myself, I am just a guy answering what i personally found less clear than it could be in the interface. I have never used pfsense.

[SecCon]

Since I have an SFTP server running and need that Port Forward to work transferring encrypted files from my web server (Internet) to my backup server (LocalLan) I do have some pointers in regards to this.

(I come from Asus Consumer Routers and latest from Mikrotik, that I dumped because of too much "details and cli" dependencies. I can't work with that. Currently running a standalone OPNSense on a vMachine as a kinda test bed. I intend for the OPNSense to handle "everything" on my network.)

1. Automation is not bad, provided you can control what it did and see all the details of it. It is synonym to simplification and removing error sources.
2. Looking at NAT > Port Forward interface in OPNSense there are to many "optional" things you just don't know if they are required or not. There is not much to tell you what fields are the mandatory required ones. I find myself wondering what these do, despite getting some basic info about them:

• No RDR
• Source / Invert
• Destination / Invert
• Category
• Set local tag
• Match local tag
• No XMLRPC Sync
• NAT reflection
• Filter rule association

I don't need an explanation of them, I will just ignore them. I wish the Interface could hide them behind an "advance for nerdy geeks options" or some such.

3. You list well known ports, but I can not find SFTP in that. Regardless I am using a custom non-default port so I am not even looking at that menu and I have over time (30 years in the business) many recommendations against using well known ports. Always use custom, if possible. (Perhaps another discussion)

All in all there are room for improvements. You can have a BASIC selection that is a no nonsense THIS IS NEEDED and then an advanced selection for those who might wanna dig in to that. I am not among the diggers, just want it to work and have the basic stuff to edit. Everything else is just toppings.

[somniture]

May I ask why SFTP should be in the well-known port list when SSH is already there?

FWIW I found the port forwarding configuration interface a little confusing, too. You couldn't pay me to go back to pfSense but I think the configuration there was a little clearer.

[SecCon]

May I ask why SFTP should be in the well-known port list when SSH is already there?

Not everyone knows that SFTP is FTP over SSH. Could perhaps be written SSH/SFTP instead, but that may be another can of worms.

[cookiemonster]

Since I have an SFTP server running and need that Port Forward to work transferring encrypted files from my web server (Internet) to my backup server (LocalLan) I do have some pointers in regards to this.

(I come from Asus Consumer Routers and latest from Mikrotik, that I dumped because of too much "details and cli" dependencies. I can't work with that. Currently running a standalone OPNSense on a vMachine as a kinda test bed. I intend for the OPNSense to handle "everything" on my network.)

1. Automation is not bad, provided you can control what it did and see all the details of it. It is synonym to simplification and removing error sources.
2. Looking at NAT > Port Forward interface in OPNSense there are to many "optional" things you just don't know if they are required or not. There is not much to tell you what fields are the mandatory required ones. I find myself wondering what these do, despite getting some basic info about them:

• No RDR
• Source / Invert
• Destination / Invert
• Category
• Set local tag
• Match local tag
• No XMLRPC Sync
• NAT reflection
• Filter rule association

I don't need an explanation of them, I will just ignore them. I wish the Interface could hide them behind an "advance for nerdy geeks options" or some such.

3. You list well known ports, but I can not find SFTP in that. Regardless I am using a custom non-default port so I am not even looking at that menu and I have over time (30 years in the business) many recommendations against using well known ports. Always use custom, if possible. (Perhaps another discussion)

All in all there are room for improvements. You can have a BASIC selection that is a no nonsense THIS IS NEEDED and then an advanced selection for those who might wanna dig in to that. I am not among the diggers, just want it to work and have the basic stuff to edit. Everything else is just toppings.

Respectfully I disagree.
The options are not just for geeks but for users that have a need or want to have the power and flexibility a business-grade firewall is expected to provide as opposed to a consumer-grade one.
OPN is the closest we can get to it without having to manage most over a terminal with or without proprietary OS. To top it all, it has very good documentation for instance here https://github.com/opnsense/docs/blob/master/source/manual/firewall.rst

[SecCon]

Respectfully I disagree.
The options are not just for geeks but for users that have a need or want to have the power and flexibility a business-grade firewall is expected to provide as opposed to a consumer-grade one.
OPN is the closest we can get to it without having to manage most over a terminal with or without proprietary OS. To top it all, it has very good documentation for instance here https://github.com/opnsense/docs/blob/master/source/manual/firewall.rst

That's ok, I never said get rid of it, but categorize it in another way. I do not handle FW for a business so what may be relevant for a large organization may not be for home office users. As with most of this tech it's a learning threshold and I choose OPNSense because I believe in the way it is being developed and the strength of a community of developers.