Apparently, the implementation of NPTv6 (Network Prefix Translation for IPv6) which is currently in Linux kernel is incompatible with connection tracking. This is quite disappointing, since I feel that NPTv6 is much more sane solution that NAT66, when you have dynamic IPv6 prefixes from the ISP and want to have stable internal IPv6 addresses.

I certainly don't want to do NAT66, but also need the stateful firewall, especially considering that NPTv6 preserves end-to-end connectivity, thus connection tracking is a must have.

My question is, does anyone know about any patches/add-ons/work-arounds that let me have NPTv6 and connection tracking for the translated flows, on the same host?

  • Where did you hear this rumor? Commented Dec 18, 2016 at 18:06
  • "man iptables-extensions" says this about DNPT: " You also have to use the NOTRACK target to disable connection tracking for translated flows."
    – haimg
    Commented Dec 18, 2016 at 18:09
  • Huh. I wonder what that's all about. Time to set up a lab, I suppose. Commented Dec 18, 2016 at 18:13
  • I don't get it at all. I tried searching on netfilter-dev, and found this: marc.info/?l=netfilter-devel&m=136787166726236&w=2 Patrick McHardy (who led development of netfilter for a while) says this: "If you're using conntrack anyways, why use NPT? The main benefit is that you don't have to use conntrack." -- I'm totally not getting what's going on here...
    – haimg
    Commented Dec 18, 2016 at 18:27

1 Answer 1


SNPT / DNPT was created specifically to be lightweight NPTv6, done exclusively in "mangle" table and is incompatible with connection tracking.

If connection tracking is employed, then there is a NETMAP target which can do IPv6 network prefix translation. So, the documentation is unclear on this, I suspect for political/religious reasons (NETMAP target is really a form of NAT66, which is disliked by many).

So, if 2607:xxx::/64 is external prefix, fda3:xxx::/64 is internal prefix, and eth0.99 is the outgoing interface, then the following does the job:

ip6tables -t nat -A POSTROUTING -o eth0.99 -j NETMAP --to 2607:xxx::/64 -s fda3:xxx::/64
ip6tables -t nat -A PREROUTING -i eth0.99 -j NETMAP -d 2607:xxx::/64 --to fda3:xxx::/64

Now, to be clear: NETMAP does 1:1 address translation (NAT), but I'm not sure it follows RFC6296 with regards to being checksum-neutral, or how it diverges from RFC-compliant NPTv6 in some other way, but it's good enough for me, and it works.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .