Bug #6945
closed
Firewall alias naming restrictions are too limiting
0%
Description
In Firewalls > Aliases, when creating/editing an alias there is a 'name' field. This field disallows most characters, which is unfortunate. I was trying to use a hostname with a '-', but even that was denied, no say nothing of Unicode in general.
No doubt this restriction is not arbitrary, and required by some low level utility.
Still, these days we have (so called) "internationalized domain names", my web browser has no trouble visiting www.bücher.ch, and I think it quite reasonable that pfsense should support such things.
The 'description' field at lest seems to support Unicode.
See also attached image.
Files
Updated by Jim Pingle over 8 years ago
- Status changed from New to Rejected
We are bound by the limits in pf. We can only allow what they allow. (A-Z, a-z, 0-9, and _)
Use the description field for your own more detailed note
Updated by Sean McBride over 8 years ago
I figured it would be something like that.
Do you know where I should file this upstream then?
Updated by Kill Bill over 8 years ago
Sean McBride wrote:
Do you know where I should file this upstream then?
https://bugs.freebsd.org/ if you insist on having another bug rejected.
Updated by Sean McBride over 8 years ago
Thanks for the link. Hopefully they won't reject the bug. Why do you think they would? (You do know that the majority of people on Earth don't know English, right? How would you like it if you couldn't use English letters?)
Updated by Kill Bill over 8 years ago
This is how's www.bücher.ch represented in DNS: www.xn--bcher-kva.ch; believe it or not, people do NOT want to deal with completely needless complexities when it comes to critical things such as an firewall. Another piece of reading: https://en.wikipedia.org/wiki/IDN_homograph_attack
Updated by Sean McBride over 8 years ago
I am well aware of DNS's Punycode encoding and of the homograph problem. The former is alas needed for backwards compatibility; presumably if DNS were invented today they'd use UTF-8 or UTF-32. The latter is certainly a hard problem.
I absolutely agree these are "complexities", but I disagree they are "needless": again, ASCII is insufficient for almost all human languages. But anyway, it hardly matters what you or I think: IDNs exist, they are an official IETF thing, and we can't pretend otherwise.
But it's just occurred to me that maybe this problem is bigger than just the 'name' field in the alias rules...
I've just tried to make a firewall rule blocking an IDN and: "www.bücher.ch is not a valid host address, FQDN or alias." Oh dear.
Shall I open a separate bug for that or will it just be closed? Is it again a pf limitation?
Updated by Phillip Davis over 8 years ago
What happens if you use www.xn--bcher-kva.ch as the name to block in the rule?
Is that effective?
I wonder if pf supports Unicode IDNs, or if it can/has to be fed the Punycode version?
Depending on the answer to that, pfSense could be enhanced to accept Unicode input for FQDNs, store it as Unicode but convert to Punycode when writing the pf rule set.
Note: This is actually off-topic for this particular bug report - if it becomes a long discussion it should move to the forum until a decent proposal is decided and then a bug/feature request can be made.
Updated by Sean McBride about 8 years ago
Pillip, yes, using "www.xn--bcher-kva.ch" as the FQDN in the alias works. ex:, with such a rule, a traceroute from my Mac doesn't go farther than my pfsense:
$ traceroute www.bücher.ch
traceroute to www.xn--bcher-kva.ch (87.98.150.101), 64 hops max, 52 byte packets
1 pfsense (192.168.1.1) 0.454 ms 0.251 ms 0.286 ms
And indeed this is off-topic for this bug. I will create a new bug suggesting that pfsense accept unicode in the UI and convert to punycode to pass down to lower levels.