Before describing the problem with NAT, I'll briefly explain my network infrastructure:
1. The network is entirely based on IPv6. The provider assigned me a public /54 IPv6 block, from which I've created several /64 subnets.
2. The physical network consists of a Proxmox server and the router provided by the ISP (a ZTE model H6745 V3). Unfortunately, despite its advanced capabilities, this device has some major limitations, including:
-----------
- It does not allow the management of more than one LAN network. Both the Wi-Fi interface and all Ethernet ports must belong to a single network.
- Although the router allows static routes to be configured, any packets with a source IP address not belonging to the main LAN are blocked by a routing policy that I cannot find anywhere in the GUI, and therefore cannot disable. Here's the evidence:
Currently, the main network is 2xxx:xxx:xxxx:bf00::/64, which is derived from the public /56 IPv6 block assigned by the provider (2xxx:xxx:xxxx:bf00::/56).
Pinging www.google.com from a host on the 2xxx:xxx:xxxx:bf00::/64 network works fine, but doing the same ping from a host on the 2xxx:xxx:xxxx:bf01::/64 subnet (another /64 from the same /56) fails. In this case, the ZTE router (where I've already set static routes for return traffic) responds with the following error message:
from ZTE_H6745_V3.xxx.internal (2xxx:xxx:xxxx:bf00:xxxx:xxxx:xxxx:eb3c) icmp_seq=1 Destination unreachable: Source address failed ingress/egress policy
This message indicates that the router is blocking traffic via a routing policy. I could not find any option in the GUI to disable this behavior. The same issue occurs even when I try to ping the router itself! I also tried configuring a firewall policy on the router to allow the traffic, but it didn't help. This confirms it's a routing policy, not a firewall rule.
This issue is resolved only if I implement Source NAT on OPNsense under Firewall → NAT → Outbound, using the firewall's WAN interface IP as the NAT address.
End of the premise.
-----------
I've explained all of this so you understand that, in order to expose one of my internal servers (protected by OPNsense) to the internet, I'm forced to implement Destination NAT, even though all of my addresses are IPv6 Global Unicast Addresses (GUA) public and globally unique.
Here's where the problems begin:
If I try to configure a Destination NAT under "Firewall → NAT → Port Forwarding", or even under "Firewall → NAT → NPTv6", the NAT rule for my web server doesn't work. On the firewall's WAN interface, I also had to assign a Virtual IP (the public IPv6 address used for NAT), otherwise the firewall wouldn't respond to Neighbor Solicitation (NS) packets sent by the router.
When I run a tcpdump on the WAN interface, I can see that packets are indeed reaching the virtual IPv6 address, but Destination NAT is never applied. The firewall simply responds with a TCP RESET, and the session is closed. My internal server never receives any packets.
Obviously, the firewall rules are correctly configured, otherwise I wouldn't even see the incoming packets on the WAN interface.
Quote from: turboc on August 09, 2025, 07:26:37 PMI also had to assign a Virtual IP (the public IPv6 address used for NAT), otherwise the firewall wouldn't respond to Neighbor Solicitation (NS) packets sent by the router.
Yes, this is a fact/feature for both IPv4 and IPv6. You need to assign all addresses that you want to be reachable for e.g. port forwarding as aliases on the interface in question - most of the time WAN.
I don't see a problem with that - the commercial product I used before OPNsense behaved exactly the same. First define IP address, then port forward.
I will have to find some time to test for your other concerns. With IPv6 I do not use port forwarding but simply firewall rules for the destination host - which of course has on or more GUA(s).
HTH,
Patrick
Thanks Patrick, let me know how the test on port forwarding with IPv6 addresses goes. it doesn't work for me. I think there's a bug in the OPNsense system, in my case:
OPNsense 25.1-amd64
FreeBSD 14.2-RELEASE
Here is a setup that might be interesting for reference:
https://docs.opnsense.org/manual/ndproxy.html#offering-services-behind-nat-cloud-setup