Bug #8410
closedunable to use registered services by name and unable to define aliases for registered services using their name
100%
Description
related to some degree to bug 8409, i've found that i'm unable to create aliases for registered services using their actual name - for example, mdns [udp/5353]. this led me to expect that, when creating a firewall rule, i would be able to use the symbolic name for this service [e.g. "mdns"], rather than having to use the port number integer ["e.g. "5353"]. however, this does not appear to work. pfsense doesn't complain, but ignores what has been provided and sets the port field to "any".
if registered services cannot be defined using aliases, then their existing symbolic names from the services(5) database should be available for use to me it would make sense to use the autocomplete mechanism for this, since inclusion in the port drop down would be impractical].
conversely, if registered services cannot be referenced by symbolic name, then an admin should be able to define an alias for a given service.
Updated by Jim Pingle over 6 years ago
- Category set to Rules / NAT
- Status changed from New to Assigned
- Assignee set to Jim Pingle
- Target version set to 2.4.4
- Affected Version set to All
- Affected Architecture All added
- Affected Architecture deleted (
)
It should be rejecting that input rather than switching to 'any'. The only text allowed in those boxes should be valid alias names.
Updated by Jim Pingle over 6 years ago
is_port()
from /etc/inc/util.inc tests a string against known services by name to determine validity, not just numbers. Then pconfig_to_address()
checks the value in such a way that it must be a numeric port number or an alias, ignoring the well-known/registered service ports that the input validation allowed earlier. Thus it ends up empty.
I have a fix, will push shortly.
Updated by Jim Pingle over 6 years ago
- Status changed from Assigned to Feedback
- % Done changed from 0 to 100
Applied in changeset 885e9b2a1df256f4d50367f96b4d39c1106b2448.
Updated by Anonymous over 6 years ago
Tested on latest 2.4.4 CE snapshot gitsync'd to master, works as expected. Setting port to other and using the name, like 'ssh', then saving the rule does not result in the port being set to any.
Updated by Jim Pingle over 6 years ago
- Target version changed from 2.4.4 to 2.4.3-p1