Project

General

Profile

Actions

Bug #3444

closed

IPv6 network alias input validation lacking

Added by Chris Buechler almost 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Rules / NAT
Target version:
Start date:
02/11/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1-IPv6
Affected Architecture:

Description

via Brian Candler on mailing list.

When creating a network alias which contains an IPv6 address, some additional data validation is required. Specifically, it lets you enter the following:

Firewall > Aliases > [+]
Name: foo
Type: Network(s)
Network(s): [+]
[fc00:123::/48 ] [ /48 ]

This happened to me for real when copy-pasting a subnet into the first field.

The data is accepted, and the alias then has value "fc00:123::/48/48". However, this prevents the ruleset from loading. More seriously, the entire ruleset is left empty. That is: after clicking Apply, 'pfctl -sr' shows nothing at all, and the firewall is open.

If you then navigate to another page, you do see an error notification:

"
02-10-14 17:11:31 [ There were error(s) loading the rules: /tmp/rules.debug:26: syntax error - The line in question reads [26]: table { fc00:123::/48/48 } ]

Actions #1

Updated by Ermal Luçi almost 8 years ago

Fixed as part of ee41ab022d92cf7d0a1b75e1d85aca7162648292

Actions #2

Updated by Ermal Luçi almost 8 years ago

Actions #3

Updated by Ermal Luçi almost 8 years ago

  • Status changed from New to Feedback
Actions #4

Updated by Chris Buechler almost 8 years ago

  • Target version changed from 2.2 to 2.1.1
Actions #5

Updated by Brian Candler almost 8 years ago

Yes, this works, thank you:

The following input errors were detected:

fc00:123::/48 is not a valid network alias.

Interestingly: the /48 suffix is stripped when the page is re-displayed with the error message - and the CIDR drop-down is updated to show /48. So, simply clicking Save a second time is sufficient to get the (now valid) alias accepted. Same is true for IPv4 prefixes.

Actions #6

Updated by Renato Botelho almost 8 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF