On Monday 06 May 2013 22:21:01 you wrote: > On Mon, May 06, 2013 at 04:38:19AM +0200, Oliver wrote: > > Hi all, > > > > Currently, the DNPT target is restricted to the mangle table; this means > > that it is effectively impossible to utilise NPT in tandem with conntrack > > since it's impossible to rewrite the destination prefix prior to > > conntrack taking a look at the skb. > > > > Please consider allowing the use of DNPT from the raw table so that it's > > possible to do prefix translation without having to forego the benefits of > > conntrack. > > The raw table doesn't have a POSTROUTING chain, which is where SNPT is > performed on order to catch both local and forwarded traffic. > > If you're using conntrack anyways, why use NPT? The main benefit is that > you don't have to use conntrack. Right, I wanted to use NPT to avoid having to use conntrack for the translation. imagine the following: local internal subnet is 2001:db8:1::/64 local subnet is 2001:db8:aaaa::/64 remote is 2001:db8:ffff::/64 if my local hosts initiate a TCP connection to fc00::1 , they first send a packet with 2001:db8:1::x as source. This then passes through the raw table and causes a conntrack entry to be created - then at mangle/POSTROUTING, SNPT will translate to 2001:db8:aaaa::/64 At this point conntrack has an entry setup for 2001:db8:1::x rather than 2001:db8:aaaa::x when the reply returns, it will have a destination of 2001:db8:aaaa::x which will be considered to have a ctstate of INVALID since it has not been mangled. If I wished to avoid this scenario, I would need to use DNPT within raw/PREROUTING in order to restore the original destination IP prior to the conntrack lookup - thus giving me the benefits of both stateless prefix translation and stateful TCP connection tracking. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
