Bug #12440
closedZero-value prefix IPv6 addresses are mishandled
100%
Description
Zero-value prefix IPv6 addresses on the type ::/96 are mishandled when used in pfSense firewall or NAT rules.
For example an address such as ::192.168.10.10 used in a NAT rule:
<rule> <source> <any></any> </source> <destination> <address>::192.168.10.10</address> <port>45678</port> </destination> <ipprotocol>inet6</ipprotocol> <protocol>tcp</protocol> <target>::10:0001</target> <local-port>45678</local-port> <interface>wan</interface> <descr><![CDATA[v6 test]]></descr> <associated-rule-id>nat_614dcdfc0fb0d6.83146982</associated-rule-id> <created> <time>1632488956</time> <username><![CDATA[admin@172.21.16.5 (Local Database)]]></username> </created> <updated> <time>1633728663</time> <username><![CDATA[admin@172.21.16.5 (Local Database)]]></username> </updated> </rule>
Results in a generated pf rule:
rdr on vtnet0 inet6 proto tcp from any to ::1921681010 port 45678 -> ::10:0001
That is invalid and prevents the ruleset loading:
There were error(s) loading the rules: /tmp/rules.debug:79: could not parse host specification - The line in question reads [79]: rdr on vtnet0 inet6 proto tcp from any to ::1921681010 port 45678 -> ::10:0001 @ 2021-10-08 23:13:08
IPv6 addresses of that format appear to be deprecated though pf itself appears to be able to handle them.
Either the input validation should should reject zero prefix addresses or the ruleset should be created correctly to include them.
Updated by Viktor Gurov about 3 years ago
Steve Wheeler wrote:
IPv6 addresses of that format appear to be deprecated though pf itself appears to be able to handle them.
Either the input validation should should reject zero prefix addresses or the ruleset should be created correctly to include them.
Firewall rules with zero prefix can be used with dynamic delegated prefix, see #6626
Updated by Viktor Gurov about 3 years ago
fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/469
example:
fw rule on IPv6 interface with fc00:88::99 address for ::192.168.10.10 dst address:
pass in quick on $LAN inet6 proto tcp from any to fc00:88::c0a8:a0a port 636 tracker 1637420076 flags S/SA keep state label "USER_RULE"
Updated by Jim Pingle about 3 years ago
- Status changed from New to Pull Request Review
- Assignee set to Viktor Gurov
Updated by Jim Pingle almost 3 years ago
- Target version changed from 2.6.0 to CE-Next
- Plus Target Version changed from 22.01 to 22.05
Updated by Marcos M almost 3 years ago
Tested on 22.05.a.20220311.0600
with the patch.
The IP ::192.168.10.10
and ::ffff:192.168.10.10
is being converted to 0:c0a8:a0a
which results in the error:
There were error(s) loading the rules: no IP address found for 0:c0a8:a0a - The line in question reads [0]: @ 2022-03-13 10:11:59
Updated by Viktor Gurov almost 3 years ago
Marcos Mendoza wrote in #note-5:
Tested on
22.05.a.20220311.0600
with the patch.The IP
::192.168.10.10
and::ffff:192.168.10.10
is being converted to0:c0a8:a0a
which results in the error:There were error(s) loading the rules: no IP address found for 0:c0a8:a0a - The line in question reads [0]: @ 2022-03-13 10:11:59
Fixed, please retest the updated MR
Updated by Viktor Gurov almost 3 years ago
- Status changed from Pull Request Review to Feedback
- Target version changed from CE-Next to 2.7.0
Updated by Jim Pingle almost 3 years ago
- Subject changed from zero-value prefix IPv6 addresses are mishandled. to Zero-value prefix IPv6 addresses are mishandled
Updating subject for release notes.
Updated by Viktor Gurov over 2 years ago
- % Done changed from 0 to 100
Applied in changeset 02004e7ad1ef9ed56b035b4a821b5951e6a05125.
Updated by Christopher Cope over 2 years ago
- Status changed from Feedback to Resolved
Testes and working as expected on
22.05-BETA (amd64) built on Fri May 13 06:28:24 UTC 2022 FreeBSD 12.3-STABLE
Marking resolved.