Bug #7745
closed
1:1 NAT is somehow broken for IPv6 (corner case??)
0%
Description
Steps to reproduce:
1. configure (e.g.) WAN interface as 2607:5300:79:501:167:114:147:49/56. Configure default gateway. IPv6 from firewall works.
2. add fw rule allowing inbound traffic to fd60:7f9c:65d8:1::2. IPv6 from firewall still works.
3. add 1:1 NAT entry specifying WAN, from 2607:5300:79:501:167:114:147:50 to network fd60:7f9c:65d8:1::2/128 (because of bug #7442). IPv6 suddenly breaks from firewall because of NDP adjacency loss.
4. disable NAT entry. IPv6 from firewall is STILL broken.
5. delete NAT entry. IPv6 from firewall is STILL broken.
6. Reboot firewall. IPv6 works from firewall again. (NDP adjacency works again.)
I have no idea what's going on here. The rules in /tmp/rules.debug look fine. The output from pfctl -s all looks fine. I can't see how/why IPv6 is still broken after disabling and deleting the 1:1 NAT entry!
(I can't even tell why it breaks upon creation of the 1:1 NAT entry, the pf rule /tmp/rules.debug looks 100% correct as long as I specify "Network" and a /128 masklen.)
Remote access can be provided for debugging purposes if needed.
Updated by Adam Thompson over 6 years ago
Update: it only breaks when the WAN interface is in the same "subnet" (possibly /64, haven't confirmed the affected prefix length yet) as the translated address.
So basically the same limitation as with NPt exists, but isn't documented, and is (maybe) accidental in this case.
Workaround, where possible: put the WAN interface into a different IPv6 address range.
So in my case, setting the WAN to 2607:5300:79:500::1:1/56 and NAT'ing 2607:5300:79:501:167:114:147:50/128 works, but
setting the WAN to 2607:5300:79:501:167:114:147:4/56 and NAT'ing 2607:5300:79:501:167:114:147:50/128 does not work.
If this either isn't a bug, or isn't something that can be readily fixed, please update https://portal.pfsense.org/docs/book/nat/1-1-nat.html to document the limitation.
Updated by Jim Pingle over 6 years ago
- Status changed from New to Not a Bug
I don't see a bug here. It works just like IPv4. IPv4 1:1 would also fail if you added a mapping for some other IP address in the WAN subnet but didn't add a VIP.
Did you add a VIP for the additional address in the WAN subnet?
Did you clear/reset states after removing the rule that didn't work?
Without more information about your networks, I can't say for sure what you might have done wrong. But this is not the place to discuss and diagnose problems. Please work these through on the forum until a specific bug can be identified and confirmed.
Updated by Adam Thompson over 6 years ago
Perhaps I could have been clearer: the complaint here is that:
- creating a 1:1 NAT entry and then removing it somehow persistently broke all IPv6 on the WAN until a reboot.
The secondary point isn't that the 1:1 NAT entry didn't work - fully expected, since there was no VIP in place yet - but that:
- merely creating the 1:1 NAT entry broke WAN connectivity in a completely unexpected way.
If I was connecting to this firewall only via IPv6, I would have just locked myself out with no way to recover.
Updated by Adam Thompson over 6 years ago
If this need to be better documented on the public Wiki, I can make those changes myself. I can't update the official book, however. And there's nothing in the official book to suggest this would happen. Or even a way this could happen.
Updated by Jim Pingle over 6 years ago
It shouldn't happen that way, but again, you have not yet identified a specific bug, only a symptom. We need a lot more information about the specific settings you used, networks involved, type of IPv6 WAN, etc, etc. This is not the place to discuss it, however.
Something in your environment or settings is causing it to trigger. I can't reproduce the problem here at all.
Updated by Adam Thompson over 6 years ago
Hmm. It's 100% trivially reproducible for me. When it's 100% reproducible for me, most of the time it's 100% reproducible for you guys, too, so I hadn't included all the details. I'll summarize settings etc on mailing list and return here with more info.