Question regarding NPT
-
I got a question about IPv6 Network Prefix Translation
WAN -> ISP Router -> internal LAN with /64 Subnet -> pfSense with NPT and internal ULA prefix.
The pfSense is behind the ISP router (with it's /64 subnet a
c:d) and translates it's intenral ULA (let's call it e:f:g:h) IPs to the public IPv6 LAN.
The hosts in the internal LAN calculate their IPs und the hosts behind the pfSense calculate their ULA ips also.
How does pfSense prevent that IPs are used two times?Example:
behind the ISP router is a host that calculates ac:d:1:2:3:4, behind the pfSense a hosts calculates e:f:g:h:1:2:3:4 that would be translated to a
c:d:1:2:3:4 via NPT, so I would get an adress conflic on the ISP router subnet.
Does NPT recognize that? -
NPt is not meant to be used that way.
NPt is to be used with a routed subnet, delivered only to the firewall. It will NOT work with your firewall's "WAN" subnet.
For that to work you'd need something akin to "Proxy NDP" which does not yet exist.
-
OK thanks.
So there is no way to use a pfSense behind another router that doesn't support prefix delegation?
NAT66 becomes more and more an option… -
Static routing, prefix delegation, or (ick) bridging.
NAT66 isn't an option currently.
-
-
It's a necessary evil for some things, such as transparent proxies and other such trickery that isn't specific to PAT and the like.
I would love to never see it, too, but unfortunately there are some valid use cases for having it. Ugly as it may be.
-
I talked to CMB a few weeks ago and he probably will consider NAT66…
There really are use cases for NAT66. As i told earlier especiallay if you have to use ISP hardware that cannot be changed, doesn't get reconfigured, too small delegated prefix etc...Thanks for the bridging Firewall info, that could be of help. Didn't think of that :-)
Allthough NAT is bad in general it wouldn't be too hard to implement it in pfSense; PF supports NAT66 and it would only require small change to the GUI.
There has been even code for the pfSense GUI
https://github.com/pfsense/pfsense/pull/427 <- even discussed on the forum here…