Feature #16241
open
Block non-global NAT64 addresses by default
Added by Raoul De Heer 3 months ago.
Updated 9 days ago.
Plus Target Version:
25.11
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
- 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
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).
We have some ideas on what could be done to make it easier. I'll ponder this some more.
- 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)
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
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
The system alias supports the info pop-up when used in user rules which describes each entry and matches those in _reserved4_:
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by