Todo #12025
open
Add 1:1 Validation to Notify Someone They are 1:1 NAT'ing an Interface Address
0%
Description
Although it is VERY rarely necessary, we should add a banner to the top of the 1:1 NAT page notifying end users that they have just 1:1 NAT'ed the WAN interface address and this is usually not recommended due to connectivity issues for dpinger, IPSec, etc. that may occur. Often we see users 1:1 NAT their WAN address out of lack of experience/understanding. Additionally, this should be useful if there was a way to verify against an HA member as well or CARP VIP as it can sometimes be easy to forget that your secondary unit is using the 1:1 NAT address you just configured on the primary and pushed it to the secondary (which then causes gateway monitoring to fail on that interface).
Updated by Jim Pingle over 3 years ago
- Priority changed from Normal to Very Low
- Target version set to Future
We used to prevent that in the past and had numerous complaints. There are many ways someone can shoot themselves in the foot, and I don't think this is one we need to go out of our way to prevent or warn against.
There are unintended side effects for all kinds of NAT scenarios, but trying to find and warn about them all is going to be a never-ending battle. There wouldn't be an automatic way to detect this before the make the error, but only when listing the rules or editing the rules, and there is a good chance they miss it in the list or don't go back and edit the rule later.
It's already documented here: https://docs.netgate.com/pfsense/en/latest/nat/1-1.html#nat-on-the-wan-ip-aka-dmz-on-linksys which is on the page users get if they click the help link while editing 1:1 NAT rules.
We don't have a facility for two-step confirmation after an input "error" to make the user confirm a choice, and technically this is not an error condition, so that kind of validation is not going to be viable.
We'd be burning a lot of development time and adding technical debt to prevent a relatively small number of misconfigurations, and it doesn't seem worth the effort.
At most we could add a note in the help below the field cautioning against using the "<interface> Address" macros or entering an interface IP address manually.