Allow DNPT target from raw table?

Allow DNPT target from raw table?

[Oliver]

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.

Kind Regards,
Oliver

Re: Allow DNPT target from raw table?

[Florian Westphal]

Oliver <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa> wrote:
> 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.

Could you please elaborate?
Shouldn't conntrack rather be disabled for such flows?

Where do you put the SNPT rules?

Re: Allow DNPT target from raw table?

[Patrick McHardy]

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.

Re: Allow DNPT target from raw table?

[Oliver]

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.