Bug #10886
closedNAT64 allows to bypass pfBlockerNG IPv4 feed list
0%
Description
If NAT64 is used, the firewall first checks the rules and then translates IPv6 to IPv4.
In this case, if IPv4 feeds are used, they can be easily bypassed using the NAT64 representation.
Example:
pfBlockerNG PRI1 feed contains 1.1.1.1 address,
user can bypass it using NAT64 representation address: 64:ff9b::0101:0101
Solution:
add global pfBlockerNG options:
'Convert IPv4 addresses to NAT64 representations' - checkbox
'NAT64 prefix' - default 64:ff9b::/96 prefix
NAT64 feature: #2358
see also ipfw(8):
net.inet.ip.fw.nat64_direct_output: 0 Controls the output method used by ipfw_nat64 module: 0 A packet is handled by ipfw twice. First time an origi- nal packet is handled by ipfw and consumed by ipfw_nat64 translator. Then translated packet is queued via netisr to input processing again. 1 A packet is handled by ipfw only once, and after transla- tion it will be pushed directly to outgoing interface.
Updated by Rick Coats almost 4 years ago
I don't know if this is possible, but a more intuitive solution is to have a "interface" for NAT64 (non-intuitively it is ipv4), like is currently done for OpenVPN. This would give user flexibility to write firewall rules for it.
Otherwise, wouldn't this will cause the tables in pfblocker to more than double in size?
When I have used NAT64 (external device) with pfsense, I found that you do have to watch out for "bypassed" traffic via firewall rules.
Updated by Viktor Gurov almost 4 years ago
- Status changed from New to Closed
All good, no needs to change pfBlockerNG
https://github.com/pfsense/pfsense/pull/4405#issuecomment-708721849:
you need PF firewall rules that match the result AFTER translation (similar to how NAT44 works) or else it will drop it. Please make sure that works to pass traffic for you. I.E. NAT64 64:ff9b::/96 -> 10.0.6.0/24 you need a accept source net 10.0.6.0/24 on the IPv6 side and accept source net 64:ff9b::/96 on the IPv4 side.