Feature #4496
closed
IPv6 outbound NAT support
0%
Description
I have an IPv4 address from my ISP and I'm using Hurricane electric tunnel for IPv6 addresses. I want to NAT my IPv6 addresses that Im using internally to the public IPv6 address I have on my pfSense box, however the outbound NAT page only has source networks that are IPv4 (source network shows (/0 to /32).
On a side note the automatic outbound NAT rules show IPv4 address, but no IPv6 addresses for both my WAN interface and for my IPv6 Hurriance Electric interfaces.
Files
| Automatic_Outbound.PNG (28.6 KB) Automatic_Outbound.PNG | |||
| Outbound_NAT.PNG (6.17 KB) Outbound_NAT.PNG |
Updated by Kill Bill over 9 years ago
Sigh. Seems like you missed the point of IPv6 altogether.
Updated by Chris Buechler over 9 years ago
- Project changed from pfSense Packages to pfSense
- Category set to Rules / NAT
- Priority changed from Normal to Low
- Affected Version deleted (
2.0) - Affected Architecture added
- Affected Architecture deleted (
amd64)
Kill Bill wrote:
Sigh. Seems like you missed the point of IPv6 altogether.
Yes. You do NOT NAT IPv6 in the manner described for Internet access. Just don't.
There is a legit usage case for source NAT on v6 though. Where you use source NAT to work around routing problems or complications in v4, the same scenarios will be applicable at times with v6. For instance reaching your CARP backup status system via VPN from master system. It can't return route to your VPN since you're not connected to it, so you source NAT it to the primary's LAN IP. Sometimes you run into situations where a target device's routing is just broken. Happens from time to time with some APs and IP cameras for instance, where they have firmware bugs breaking off-subnet routing. Sometimes are just misconfigured, but can't be reconfigured for whatever reason.
I thought we already had a feature request open for this, but can't seem to find one now.
While it does have legit uses, I'm tempted to not implement such functionality because I'm willing to bet a majority of its uses would be completely unnecessary garbage like NATing all your Internet to one IP. Most of the NAT requirements of v6 (multi-homed small networks, primarily) are covered by nPT, which we've had for years.
Updated by
Updated by Chris Buechler over 9 years ago
Dmitriy K wrote:
afaik, NPt does this, no?
No, that's only prefix translation. This specifically is referring to many:1 source NAT under Outbound NAT. Which you almost never want to do with IPv6, but it has its use cases.
Updated by Kill Bill over 9 years ago
Dmitriy K wrote:
afaik, NPt does this, no?
No. NPt is like 1:1 NAT (globally routable prefix => ULA prefix). It does not hide the entire LAN behind a single IPv6 at all.
Updated by Richard Yao over 3 years ago
Dmitriy K wrote in #note-3:
afaik, NPt does this, no?
Sadly, NPt does not work for my use case. I have a situation where a network service is utterly broken on IPv4 due to network congestion, is intermittently broken on the HE IPv6 tunnel broker due to network congestion and works fine on Cloudflare Warp+. The device that must access it supports IPv6, but not Wireguard, so I set up Wireguard on my pfSense router. I decided to workaround the network congestion and device limitations by routing traffic Cloudflare Warp+ through my pfSense router, so I:
1. Configure wireguard on pfsense using the output of wgcf
2. Assign the interface while setting the upstream gateways to the IPv4 /32 and IPv6 /128 provided by cloudflare.
3. Add an outbound hybrid NAT rule for both IPv4 and IPv6.
4. Make policy based routing rules for the device so that all traffic is routed over Cloudflare Warp+.
Then I observe that only IPv4 traffic is routed over Cloudflare Warp+ while IPv6 traffic is still going over the HE tunnel broker. Oddly enough, `sudo pfctl -s nat` seems to have the same rules for IPv4 and IPv6, so it is not clear to my why this is working for IPv4, but not for IPv6:
nat on tun_wg0 inet from <tonatsubnets> to any port = isakmp -> 172.16.0.2 static-port
nat on tun_wg0 inet6 from <tonatsubnets> to any port = isakmp -> fd01:5ca1:ab1e:xxxx:xxxx:xxxx:xxxx:xxxx static-port
nat on tun_wg0 inet from <tonatsubnets> to any -> 172.16.0.2 port 1024:65535
nat on tun_wg0 inet6 from <tonatsubnets> to any -> fd01:5ca1:ab1e:xxxx:xxxx:xxxx:xxxx:xxxx port 1024:65535
I noticed that different devices get different /128 IPv6 addresses, so I censored the IPv6 address. Also, I probably should look into why there are isakmp rules, but getting back to my problem, I cannot use NPt because Cloudflare does not give me a /64 (maybe I'll try using one without permission and see how that goes). I have been frustrated over the poor routing situation over which I have no control, found a way to route around it and then hit a wall because pfSense does not support IPv6 outbound NAT.
I know that NAT is problematic when you do peer to peer connectivity, which is why the IPv6 developers wanted to do away with it. That is great in theory, but in practice, it does not let me work around poor routing when I am too small to have my own ASN, negotiate peering and do BGP. If everyone did the right thing, none of that would be necessary, but I find that expecting everyone to do the right thing is unrealistic. I suppose cloudflare could just provide a /64 to let me use NPt, but they do not have any reason to do that (although I will probably ask). For my application, I do not need peer to peer connectivity, so using NAT should work around the network congestion without any obvious downsides.
Here is what I see myself doing if I do not figure out a way to make this work on pfSense:
1. Setup a Linux machine.
2. Have pfSense send IPv6 traffic for this device to it.
3. Have the Linux machine do outbound IPv6 NAT to send traffic over Cloudflare Warp+.
Updated by Richard Yao over 3 years ago
Upon closer inspection, NAT over IPv6 is working.
Cloudflare Warp+ advertises not hiding IP addresses and it does this by passing your real IP address over HTTP headers to clients of their CDN. However, connections to Warp only tell it either your IPv4 address or your IPv6 address. If you are connected to Warp over IPv6 (e.g. through the HE tunnel broker) and connect to a website behind the cloudflare CDN over IPv4, cloudflare will tell the website a Warp IPv4 address. However, if you then connect to the website over IPv6, cloudflare will tell the website your real IPv6 address.
This caused me to incorrectly conclude that there was a NAT issue when www.whatismyip.com reported my real IP address. Doing `traceroute -6 www.whatismyip.com` revealed the truth in that IPv6 traffic was being properly routed.
Sorry for the noise. I think it should be safe to close this issue.
Updated by 
