Bug #14354
closed
Outbound NAT rule input validation error when attempting to manually specify "Other Subnet" with a valid address
Added by Sum Fox over 1 year ago.
Updated over 1 year ago.
Plus Target Version:
23.05.1
Affected Architecture:
amd64
Description
I believe I have stumbled upon a bug within the WebUI while attempting to create brand new outbound NAT rule with a manually specified IPv4 translation address.
Selecting the "Other Subnet (Enter Below)" address option and specifying a valid IPv4 address and CIDR in the Other Subnet input fields results in the following error message:
The following input errors were detected:
A valid target IP address must be specified.
I have discovered a workaround which I would prefer to not have to do.. You can manually go into the config.xml file and type the correct IPv4 translation address and CIDR there and pfsense takes the change no problems.Doing this even results in the NAT entry displaying the address correctly as well.
Files
I can confirm this bug. This can be easily worked around by adding a VIP with a type of "Other" and then using that to map it, but we should still fix this even if the "Other" field is rarely used.
- Project changed from pfSense Plus to pfSense
- Subject changed from Manual Outbound NAT Rules to Outbound NAT rule input validation error when attempting to manually specify "Other Subnet" with a valid address
- Category changed from Rules / NAT to Rules / NAT
- Assignee set to Jim Pingle
- Target version set to 2.7.0
- Affected Plus Version deleted (
23.01)
- Plus Target Version set to 23.09
Looks like it might just be one inverted test tripping it up but it needs more time/testing to ensure this change doesn't break other combinations of options.
[incorrect diff removed]
The patch is allowing to add a CIDR and seems doesn't affect anything at first glance. But I found the typo on the NAT address field
Update it produces the following error:
There were error(s) loading the rules: /tmp/rules.debug:172: could not parse host specification - The line in question reads [172]: nat on $WAN inet from 172.22.100.0/24 to any -> ther-subnet/32 port 1024:65535
OK, now I see what the original cause of the issue is. The old diff is the wrong fix. Revert that and remove it if you tried it. This is the right fix
diff --git a/src/usr/local/pfSense/include/www/firewall_nat_out.inc b/src/usr/local/pfSense/include/www/firewall_nat_out.inc
index b8ff028e78..a471551099 100644
--- a/src/usr/local/pfSense/include/www/firewall_nat_out.inc
+++ b/src/usr/local/pfSense/include/www/firewall_nat_out.inc
@@ -661,7 +661,9 @@ function build_target_list() {
$list['H' . $alias['name']] = gettext('Host Alias: ') . $alias['name'] . ' (' . $alias['descr'] . ')';
}
- $list['Other-subnet'] = gettext('Other Subnet (Enter Below)');
+ /* First character is the type code, remainder is the internal name.
+ * See https://redmine.pfsense.org/issues/14354 */
+ $list['Oother-subnet'] = gettext('Other Subnet (Enter Below)');
return($list);
}
- Status changed from New to Feedback
- % Done changed from 0 to 100
- Plus Target Version changed from 23.09 to 23.05.1
Looks good after the fix, no more errors and typos.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by