Project

General

Profile

Actions

Bug #8410

closed

unable to use registered services by name and unable to define aliases for registered services using their name

Added by lists b over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Rules / NAT
Target version:
Start date:
03/31/2018
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

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.

Actions #1

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.

Actions #2

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.

Actions #3

Updated by Jim Pingle over 6 years ago

  • Status changed from Assigned to Feedback
  • % Done changed from 0 to 100
Actions #4

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.

Actions #5

Updated by Jim Pingle over 6 years ago

  • Status changed from Feedback to Resolved
Actions #6

Updated by Jim Pingle over 6 years ago

  • Target version changed from 2.4.4 to 2.4.3-p1
Actions

Also available in: Atom PDF