[Openswan Users] NAT based upon tunnel

[Paul Wouters]

On Wed, 6 Oct 2004, John A. Sullivan III wrote:

> By the way, what mailing list supports questions about the native Linux
> IPSec implementation? I haven't really started experimenting with it yet
> but I need to soon.

I think that's on the netfilter list mostly.

> That's an outstanding idea.  I hesitate to add the complexity to the
> Head Office where a mistake could have very profound effects on large
> numbers of users but it sounds much simpler than my proposal above.

The head office seems to only place where you can create complexity :P

> That is, OfficeA is 10.1.1.0/24, OfficeB is 10.1.1.0/24 and the Head
> Office is 10.2.2.0/24.  I can bind 10.2.3.1/24 to the Head Office GW,
> create one policy between OfficeA's 10.1.1.0/24 and 10.2.2.0/24 and
> another between OfficeB's 10.1.1.0/24 and 10.2.3.0/24.  I think that's
> what you are suggesting.  Correct?

Yes.

> I would then, within the Head Office GW and on the decrypted packet on
> the ipsec interface, DNAT 10.2.3.0/24 to 10.2.2.0/24, as long as it does
> not break anything at the application layer.  I could conceivably now
> have two packets headed for the same server with the same IP address.  I
> assume that iptables is smart enough that they will never have the same
> source port, too.  The replies will come back and connection tracking
> within iptables will magically identify the reply packet for OfficeB and
> SNAT the reply back to 10.2.3.0/24.

I believe so, yes.

> That sounds like it will work.  Does anyone see any caveats?

That depends, are you billing per hour :)

> This leads to another off topic but interesting question.  I'm pretty
> sure this will work in *swan because of the complete traversal of the
> packet through the netfilter hooks on each interface (e.g., eth0 and
> ipsec0).  Will such a solution work if we are only using PLUTO and not
> KLIPS? When a packet comes in from OfficeB using native IPSec, we
> decrypt it and it is now destined for 10.2.3.0/24.  Can we catch it and
> DNAT it in the PREROUTING chain after it has been decrypted?

The whole ipsec+nat thing with netfilter is being heavily worked on as we 
speak. I wouldn't not recommend it for quite some time on production systems.

Paul
-- 
 	"Non cogitamus, ergo nihil sumus"