Feature #16241
open
Block non-global NAT64 addresses by default
100%
Description
In the current version (2.8.0) of pfsense is it possible to contact rfc1918 addresses using nat64, for example ping '64:ff9b::192.168.1.1'. This is insecure according to RFC6052.
Is there a setting to ensure behavior according to RFC6052? I've temporary added a firewall rule above blocking RFC1918 subnets translated to nat64.
I believe this is a security vulnerability that could lead to bypassing of firewall rules.
[RFC6052 Section 3.1](https://www.rfc-editor.org/rfc/rfc6052#section-3.1) says:
The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918](https://www.rfc-editor.org/rfc/rfc1918) or listed in Section 3 of [RFC5735](https://www.rfc-editor.org/rfc/rfc5735#section-3). Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non-global IPv4 address; they MUST drop these packets.
Files
Updated by Marcos M 22 days ago
- Status changed from New to Not a Bug
- Assignee deleted (
Marcos M)
This is not the only way that pfSense can be configured to break RFCs. The default rule policy on pfSense is to block all incoming and allow all outgoing; beyond that it's up to the firewall administrator to create rules appropriate for their environment.
We can improve the documentation around NAT64 based on this info however. Thanks for reporting it - docs request opened here:
https://redmine.pfsense.org/issues/16371
Updated by Raoul De Heer 22 days ago
I agree on the default rule policy, but when I add a firewall rule for an IPv4 address. I would have to add a second rule for the NAT64 mapped address. Is it possible to add a checkbox to the IPv4 rule to do this automatically or some way to apply the IPv4 rules after the NAT64 translation? Currently all IPv4 rules are bypassed when having a NAT64 translation rule.
For example:
If I have a rule blocking all to '192.168.1.1' and a NAT64 rule.
Then '192.168.1.1' will still be fully available via '64:ff9b::192.168.1.1'.
Last time I checked (version 2.8.0).
Updated by Marcos M 14 days ago
- Tracker changed from Bug to Feature
- Subject changed from NAT64 Doesn't drop RFC1918 to Block non-global NAT64 addresses by default
- Status changed from Not a Bug to In Progress
- Assignee set to Marcos M
- Target version set to 2.9.0
- Plus Target Version set to 25.11
- Affected Version deleted (
2.8.0)
Updated by Marcos M 13 days ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Applied in changeset 90b6e959994692863a71f454785ac7f364054fbe.
Updated by Alhusein Zawi 8 days ago
Firewall-generated ruleset shows:
table <_nat64reserved_> { 64:ff9b::0/104 64:ff9b::a00:0/104 64:ff9b::6440:0/106 64:ff9b::7f00:0/104 64:ff9b::a9fe:0/112 64:ff9b::ac10:0/108 64:ff9b::c000:0/120 64:ff9b::c000:200/120 64:ff9b::c058:6300/120 64:ff9b::c0a8:0/112 64:ff9b::c612:0/111 64:ff9b::c633:6400/120 64:ff9b::cb00:7100/120 64:ff9b::e000:0/100 64:ff9b::f000:0/100 64:ff9b::ffff:ffff/128 }
nat64reserved = "<_nat64reserved_>"
Is there a way to make it clearer for rfc 1918? (for example 64:ff9b::192.168.0.0/112 instead of 64:ff9b::c0a8:0/112)
tested on 25.11.a.20250827.0600
