Strange issue with NAT64 - does not work for private IPv4 addresses
-
NetGate 6100 running pfSense+ 26.03
My ISP (WAN) connection is dual stack as are all my internal networks/subnets. I'm experimenting with an IPv6 only client in my LAN subnet (10.0.200.0/24, 2a02:390:62fb:1::/64).
I followed the NAT64 recipe in the pfSense+ documentation for NAT64/DNS64 to NAT64 enable my LAN subnet. That is working fine in as much as I can now send traffic from the IPv6 only LAN client to IPv4 only hosts on the internet by way of NAT64.
One of my other subnets (IoT) - dual stack (10.150.200.0/24, 2a02:390:62fb:5::/64) - contains some legacy IPv4 only clients. Things are set up (firewall rules) such that both IPv4 and IPv6 traffic originating in LAN can flow to IoT (but not vice versa). So in many ways LAN <-> IoT is very much like LAN <-> WAN.
My (possibly naive) expectation was that since NAT64 is configured on the source subnet (LAN) it should also apply to traffic to my other subnets, but this doesn't seem to be the case. If the LAN client ping6s the NAT64 translated address for an IPv4 only client in the IoT subnet then there is no response. Tcpdump on the LAN interface shows the ICMPv6 packets arriving at the LAN interface but nothing relevant exits from the IoT interface. The system log firewall section doesn't show anything blocking the traffic (there should not be anything doing that anyway). Same result if I ping6 the NAT64 translated address of the router's IoT interface.
Now comes the interesting part. If I (temporarily) assign a non-private IPv4 address (IP alias VIP) to the IoT interface (193.10.15.1) I am then able to successfully ping6 the NAT64 translated IPv6 version of that from the LAN. So it seems that:
- pfSense+ NAT64 for some reason does not work for NAT64 translated IPv4 private addresses (or at least for 10.x.x.x addresses at any rate).
OR
- It does work but something else in pfSense+ is (incorrectly) blocking the traffic.
OR
- It does work but the resulting IPv4 traffic is not then routed to the correct interface (IoT in this case).
OR
- Something else...
I can't see anything in the relevant RFC (6146) nor the pfSense documentation to indicate that NAT64 only works for non-private IPv4 addresses so I can only assume that either there is a bug here or that there is some other issue at work.
I'd like to get this working so grateful for any useful input.
-
@ChrisJenk This is deliberate.
See https://github.com/pfsense/pfsense/commit/90b6e959994692863a71f454785ac7f364054fbe and https://redmine.pfsense.org/issues/16241That's based on RFC6052 Section 3.1 which says:
The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in RFC1918 or listed in Section 3 of RFC5735. 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. -
@kprovost Ouch, that's annoying. Seems like a rather strict restriction. Would a workaround be to use a different prefix (i.e. not the Well Known prefix)? if so would that still work for Internet traffic too (since my DNS64 / NAT64 is being done in my router)?
EDIT: Seems this is not an option since (a) there is no longer an option to set the NAT64 prefix in the DNS Resolver advanced settings and (b) When creating a NAT64 firewall rule you cannot specify any prefix there other than the default one. Sigh.
-
So I found this option, which solves all my problems:
