Thread (1 message) 1 message, 1 author, 2003-12-07
  • (off-list ancestor, not in this archive)
  • Re: 2.6 IPSEC + SNAT · Herbert Xu <herbert@gondor.apana.org.au> · 2003-12-07

Re: 2.6 IPSEC + SNAT

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2003-12-07 09:33:24
Also in: netfilter-devel

On Tue, Oct 07, 2003 at 04:51:22PM +0400, kuznet@ms2.inr.ac.ru wrote:
I thought about this (ages ago, so this can be stale)
The verdict was that self-consistent picture is possible only
when NAT rules are integral part of SPD. It does not look like
a stimulating idea. :-)
I've hit this issue again recently [1] so I'd like to know if
you've had any new revelations on this.

It seems to me that for the forward path at least, there is no issue
with breaking the routing/xfrm_lookup couple, and turning it into
routing/FORWARD/POSTROUTING1/xfrm_lookup/xfrm_output/POSTROUTING2.
Do you agree with this?

If so, then the problem is restricted to the case of locally generated
packets.  Which leads us back to the previous discussion about what
you're going to do with the xfrm_lookup calls on TCP/UDP/RAW sockets.
Can you give an update on your work on that?

Thanks,

[1] The setup is as follows:

Client <-----> Gateway <-----> Internet
	IPSEC

If the gateway does SNAT and the client starts an active FTP connection,
then the TCP sequence numbers may have to be modified.  This is OK on
the way out, but on the way back to the client, the sequence change can
only occur in POSTROUTING which unfortunately occurs after IPSEC
encapsulation.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help