[Openswan Users] NAT based upon tunnel

[Alexander Samad]

Hi

Going to jump in the deepend, I haven't tried this setup but something
similiar, I use the 2.6 with native stack, with some netfilter pom-ng
patches (NAT + native stack do not work properly with out these
patches), all this is done on a debian build.

if you are able to place linux boxes at each node in the wan, then the 2
remote office just need to have 1:1 static mapping placed on them, this
will remove the conflicting remote addressing seen by the head office

so static map Office A to 10.3.3.0/24 and office B to 10.4.4.0/24 
Then the tunnels can be setup with the different address.  Communication
will be able to be initiated in either direction.

This shouldn't be a hard exercise, the key is the 3 linux boxs at each
node of the wan.

Alex


On Wed, Oct 06, 2004 at 04:32:52PM +0200, Paul Wouters wrote:
> 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"
> _______________________________________________
> Users mailing list
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.openswan.org/pipermail/users/attachments/20041007/cead81d6/attachment.bin