[Openswan Users] NAT based upon tunnel

[John A. Sullivan III]

This is a nasty problem and I can use some pretty expert guidance. 
Please do not trouble yourself to test a possible solution if you do not
know the answer off the top of your head.  If no one knows the answer,
I'll take the time to set up a test lab to test possible solutions.  I'm
hoping someone can save me the hours or days it will take to do that if
they just happen to know the answer. So much for the preamble -- I just
didn't want to unfairly impose on anyone.

I am confronted with the classic scenario of a VPN WAN with two branch
offices with conflicting IP address space. Normally, we resolve this
problem by NETMAPping one of the sites at the remote gateway and before
the traffic enters the tunnel.  In this case, we do not have the ability
to NAT on the remote site and must handle the conflict resolution at the
head office.

The proposed solution is to spend a pile of money on a high end Cisco
Catalyst, handle each tunnel completely separately and NAT them in the
Catalyst.  I'd like to find a Linux alternative.  I think the key will
be to be able to identify the traffic based upon which tunnel it comes
from and then NAT the traffic from one of the tunnels.  I think I see
how it could work but there are several potential stumbling blocks along
the way.  I would appreciate it if someone could give me answers to each
potential pitfall.

First, a quick ascii diagram.

Office A              Office B
10.1.1.0/24           10.1.1.0/24
    |                     |
    |                     |
--------------      ---------------
| 10.1.1.1   |      | 10.1.1.1    |
| Gateway A  |      | Gateway B   |
| 1.1.1.1    |      | 2.2.2.2     |
--------------      ---------------
      |                 |
      |                 |
       \               /
         \            /
           \         /
             Internet
                 |
                 |
           ------------------
           | 3.3.3.3 eth0   |
           | Head Office GW |
           | 10.2.2.1 eth1  |
           ------------------
                 |
                 |
           ----------------
           | 10.2.2.2      |
           | Server 1      |
           -----------------

So Office A and Office B are using the same network address.   Let's say
that I want to NAT Office B's traffic to 10.3.3.0/24.  Let me walk
through the scenario where a user in Office B wants to communicate with
Server1.

I would think I could create two separate connection definitions in
ipsec.conf on the Head Office Gateway.  I'll leave out lots of detail
for brevity's sake but here is the rough idea of the ipsec.conf

conn %default
	left=3.3.3.3
	leftnexthop=3.3.3.1
	leftsubnet=10.2.2.0/24

conn OfficeA
	right=1.1.1.1
	rightsubnet=10.1.1.0/24

conn OfficeB
	right=2.2.2.2
	rightsubnet=10.1.1.0/24

So the subnets are the same but the tunnel endpoints are different.  I
could also specify a unique rightid or a preshared key.  I know this
configuration will load without error.  But I do not know if it will
work.  

My first question is will the packet from GatewayB choose the correct SA
based upon the tunnel end point addresses or will it simply choose the
first security policy which matches the internal addresses and, if it
happens to be associated with the right SA it will work and if it
happens to be the wrong one it will fail? Am I dead yet?

The next challenge is to distinguish the traffic. I know that I can use
the iptables MARK target in the mangle table and it will stay with the
decrypted packet using the native 2.6 kernel IPSec.  Will it also work
with KLIPS, i.e., if I mark the packet on the physical interface, will
it still be marked on the ipsec interface?

If so, I can do something like:

iptables -t mangle -A PREROUTING -i eth0 -s 2.2.2.2 -p 50 -j MARK
--set-mark 1
iptables -t nat -A POSTROUTING -o eth1 -m mark --mark 1 -s 10.1.1.0/24
-j NETMAP --to 10.3.3.0

So now the packet exits the Head Office Gateway bound for Server 1 at
10.2.2.2 with a source address of 10.3.3.x.  Server 1 replies with a
packet destined for 10.3.3.x via the Head Office Gateway.  The gateway
receives the packet and, due to the magic of connection tracking,
properly DNATs the packet to now have a destination address of
10.1.1.x.  Here is the point where I am really in the dark.  Will the
Head Office Gateway realize which SPI this reply packet should use and
place it in the correct tunnel or will it merely choose the first tunnel
based upon the route to the destination address and sent the packet that
way for better or worse?

I think, if I get past this point, it will all work.  But I'm really
unsure about those sticking points.  Does anyone know the answer or have
an alternative solution? Thanks very much - John

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