[Openswan Users] NAT based upon tunnel

[Paul Wouters]

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

> 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.

Eww. You also cannot remap the other remote side?

> 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.

It might work, if you do your NATing locally before it hits the ipsec
machinery (eg klips/ipsecX interfaces). But you need to somehow ensure
that OfficeA and OfficeB are treated differently.

> 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?

How can it choose the correct one? How can it know?

> 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?

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.

> 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

if the marking survives, this should work.

> 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 don't think the gateway realises anything about SPI on a nonencrypted
packet. And AFAIK you can't pick spi based on a marked encrypted packet,
though the 2.6 stuff is under heavy development so you never know.

> 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

Can't you use a second linux box at the headoffice, and setup a NAT-T
tunnel termining behind the currently deployed ipsec gateway, and then
running NAT on that box? Or if you have enough real IP space, just setup
a second box to terminate/nat the second office?

Or can you split up the /24 in two or smaller chunks? 
Also, even if using NAT, I really hope office a and b do not ever need to do
something like mounting a windows share across the tunnels.

Frankly, I think this is more a management problem then a technical problem.
You have been too nice and should say 'this is not possible, one location must
renumber'.

Paul
-- 
 	"Non cogitamus, ergo nihil sumus"