[Openswan Users] NAT based upon tunnel

[John A. Sullivan III]

Thanks again, Paul, this is really helping me out of a bit of a jam.

On Wed, 2004-10-06 at 09:02, Paul Wouters wrote:
> On Wed, 6 Oct 2004, John A. Sullivan III wrote:
> 
<snip>
> 
> > There are potentially thousands of clients so the solution must scale to
> > handle many IP address conflicts.
> 
<snip>
> Just to clarify, the problem is not in receiving packets on the head end
> or sending packets on the branch. The problem is in distinguishing and
> sending packets from the head office to the correct branch office.
> 
> So you will need to immediately NAT the packets when you decrypt them and
> still know where the packets came from (as you said, perhaps with marking?)
> so that answers to these packets are done on the NAT'ed range so you know
> which branch office these packets are.
Yes, exactly.
> 
<snip>
> >> AFAIK, klips has no idea about marking packets. You might get the desired
> >> result by using hidetos=no but it likely won't be copying all the IP options
> >> of the plaintext packets. Perhaps Michael can answer this question.
> > Ouch! If that's the case, then I am probably forced into the KAME,
> > Racoon and the native IPSec implementation unless someone else can
> > figure out how to distinguish the packets from OfficeB from the packets
> > from OfficeA within iptables.
> >
> > Does anyone know authoritatively if the mark survives decryption?
> 
> Michael?
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.
<snip>
> Another thought. Can you add more networks at the head office, and then have
> seperate tunnels from the same remote 10.a.b.0/24 networks to different *local*
> subnets, and then perform NAT locally?
> 
> So officeA becomes 10.0.2.0/24 to 10.a.0.0/24 and officeB becomes 10.0.2.0/24
> to 10.b.0.0/24. Then you can SNAT the 10.0.2.0/24 range based on the destination
> range of the packet, and on the way back DNAT them back to 10.0.2.0/24 before
> encrypting them and sending them over the tunnel. Since the head office network
> is then different, these two offices have non-identical tunnels, and no special
> marking needs to happen.
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.

This is a little off topic but I'll bounce it off anyone still following
this thread:
I think I would not run a virtual network on the same media because I
would not want to have to add IP addresses to every back end server
every time there is another conflict for the same IP address space
(e.g.,in the illustration we've been using, a third client comes along
with 10.1.1.0/24).  However, I would imagine that I could bind any
number of addresses to the gateway private interface and set up security
policies between the conflicting offices and these alternative
addresses.

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?

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.

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

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?

Thanks - John
> 
> Paul
-- 
John A. Sullivan III
Open Source Development Corporation
Financially sustainable open source development
http://www.opensourcedevel.com