IPv6 and NAT discussion
jonnytabpni last edited by
This isn't really related to pfsense, but I'd like to start a discussion on NAT and IPv6. It is my understanding that IPv6 is supposed to get rid of NAT, as most end users will be allocated a subnets which can be routed to their LAN. While this is great, I can think of one very big reason to still use NAT: failover/load-balancing.
With IPv4 NAT, since pfsense handles all translations between the local address and external address, it doesn't matter what the external IP is, NAT sorts that out.
However, with non-NAT solutions with IPv6, the two ISPs would have to co-operate and use RIP (or something else) which is just impossible.
Thoughts anyone? Will pfsense eventually support NAT for IPv6 for the purposes of load-balancing and failover?
bardelot last edited by
The recommended solution would be to use a provider-independent IPv6 prefix and ISPs that handle the routing of the address in the Internet (mostly using BGP).
As an alternative if you cannot get / afford a PI prefix and / or ISP that will route your prefix, NPt is probably the answer and is supported by pfSense.
There's also a wiki article:
cmb last edited by
Virtually every small to mid sized multi-homed network will have no option in the near future other than network prefix translation (NPT), for which we've had support for over a year. You'll have to NAT on one of your connections in such circumstances (but prefix translation rather than N:1 NAT of IPv4).
NPt works. I run IPv6 multi-wan (two tunnels) at home and it works great.
jonnytabpni last edited by
This is fantastic! Even better than NAT!
I guess the only caveat is that the subnets have to be of the same length for both WAN?
Also, are there any plans to introduce normal NAT for IPv6? I understand that NPT is a better solution, however there may be some situations where NPT is not feasible (example, you want an internal segregated network protected by pfsense, but your upstream router only has a single /64 assigned to it…
databeestje last edited by
Negative, we won't be spending that on that, there are a number of far higher priority issues that need ipv6 support.
And nat isn't one, NPt essential failover functionality, so that was added. The input validation is broken though.
Yes. the length must be the same for the WAN and LAN, but you can do smaller lengths, but the smallest is the common denominator.
Yes the subnets have to be the same length - but since most ISPs will be handing you a /64 it probably won't be an issue.
Not sure if there will be NAT for IPv6. It would have to be added into pf, I don't think it's currently supported there. It's really not necessary in most cases. People who have thought they needed it, really turned out to have an ISP deploying a broken/non-compliant setup and it was the ISP that needed fixing, not the client…
So far the only interesting use-case I've seen for it is the possibility of doing transparent proxying, since that requires a port forward to function.