(If you work for Netgate – would a paid support subscription include helping me diagnose the problem here, and get this working? I’m not 100% clear if this is in scope or not.)
I’ve encountered an – apparently – unusual problem when trying to enable 1:1 NAT for IPv6. I’m also having a similar problem with NPt, actually, and since they both seem to use the same pf(4) “binat” directive, I suspect they might be related. All IPs here are obfuscated because the list gets archived, but the last two octets/hextets[1] and subnet masks are all coped as-is. I’ll be happy to provide actual IP addresses in private emails, if you think that’s where my problem lies. Scenario: * OVH private cloud (so same non-delegated, NDP-only IPv6 address space I’ve mentioned previously) * pfSense VM was deployed from official OVA file * OVH has allocated 1:2:3:4::/56, 1.2.3.48/28 and a few more IPv4 subnets, all bound to the same router interface on their end, connected to the WAN VLAN on the pfSense VM. The IPv6 allocation is *NOT* delegated, it’s a simple interface binding on their router. * pfSense WAN address is 1.2.3.49/28 and 1:2:3:4::49/56. Default gateways are 1.2.3.62 and 1:2:3:4::ffff:ffff:ffff:ffff. * pfSense LAN address is 10.1.1.1/24 and fd60::1/64. It is the default gateway. * One other VM exists on the “LAN” V(X)LAN[2], providing public services over tcp/80, tcp/443 and tcp/22. * Firewall rules are trivial for debugging purposes: Allow Any/Any/Any on WAN and Allow Any/Any/Any on LAN. * IPv4 Proxy ARP VIP exists for 1.2.3.50/28 * 1:1 NAT for 1.2.3.50/32 <- -> 10.1.1.2/32 exists, seems to work fine. Notes: * I have multiple tenants within my OVH private cloud. * I want them all on separate VLANs, both to slightly increase security (no sniffing/snooping/spoofing attacks) and also to simplify IPSec tunnel setup. * I can’t use NPt because OVH isn’t delegating or routing that /56 to me. (If they would just &^%$#@! *route* the blocks to me, I’d be done a month ago…) * I’m “allocating” /64s out of that /56 for each customer purely administratively, i.e. on paper What’s happening (that I think is a bug) * pfSense itself has IPv6 connectivity at this point, yay. * I create a VIP for 1:2:3:4::50/56. * If and only if the VIP type is “IP Alias”, then: * Other VMs on the same WAN segment can ping :50. * External nodes cannot ping :50, until I force a “gratuitous NDP” (that shouldn’t even be a thing…) by pinging the default gw with the source address set to :50. There might be a timer involved and I’m too impatient? Dunno, anyway this gets global traffic routing working. * The moment I create a 1:1 NAT entry for 1:2:3:4::50/128 <- -> fd60::2/128, all IPv6 on the WAN stops working. pfSense no longer replies to Neighbour Solicitations packets from the gateway, which… well… breaks IPv6 pretty thoroughly. I can still see the incoming NDP packets using tcpdump, but no responses. But: * If I do this with “Proxy ARP” VIP instead of “IP Alias” VIP, I can never ping :50, but creating the 1:1 NAT entry still breaks IPv6 on the WAN interface. * If I set the WAN interface address to something elsewhere in the range (e.g. 1:2:3:5::1/56) and then set up NPt between, say, 1:2:3:4:0/64 (WAN) and fd60::/64 (LAN), IPv6 from pfSense itself does not break, but pfSense also does not respond to Neighbour Solicitations for IPs in that range, so I don’t have functional IPv6 to or from the LAN. This is a documented limitation, and it’s not supposed to work. So I’m lost. Why on earth would *creating* a 1:1 NAT entry for a pair of /128s break IPv6 (NDP, anyway) for the firewall itself? Why does creating the equivalent NPt mapping *not* break the firewall? While I’m pissed at OVH for refusing to delegate or route the /56, it seems this should still be *possible*, even if awkward, to deploy. But my IPv6 breakage seems very weird – but what on earth could I be doing SO differently that it breaks for me but no-one else? Thanks, -Adam [1] https://en.wikipedia.org/wiki/Hextet - you got a better word? Let me know! [2] From pfSense’s perspective, it’s just another segment. Internally, OVH uses VMware NSX VXLANs to emulate VLANs to emulate broadcast domains. As far as I can tell, this “just works”. It doesn’t seem to be part of the problem, anyway. _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
