[Openswan Users] NAT based upon tunnel

[John A. Sullivan III]

Thanks very much for such a quick response, Paul.  I'll make some
comments in the text below.  

On Wed, 2004-10-06 at 04:08, Paul Wouters wrote:
> 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?
Alas, there is very little flexibility and very large numbers.  This is
an ASP connecting to clients for a single service and for generally
small, non-technical customers.  Thus mandating an IP address change is
out of the question.

They also use whatever equipment the client has so they are frequently
confronted with very cheap devices with virtually no functionality-
sometimes just little consumer level NETGEAR or D-Link devices.

There are potentially thousands of clients so the solution must scale to
handle many IP address conflicts.
> 
> > 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.
I lost you a bit here, Paul.  We normally do NAT before the tunnel but
we can't here. Of course, you may mean locally as the Head Office
Gateway.  If that is the case, how would I do such a thing.  I assume I
can change the IP before it hits KLIPS but that would merely act on the
ESP packet and be meaningless to the inside.  Have I misunderstood you?
> 
> > 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?
I suppose that's what I'm asking.  I do not know the code nor enough
about IPSec to see clearly here.  I assume what happens is something
like this (someone please correct me if I am wrong!):

1) The packet from the client at OfficeB, let's say 10.1.1.9, sends a
packet to 10.2.2.2.  It arrives at the OfficeB GW.  The GW examines its
security policy database and finds a match for 10.1.1.0/24 ->
10.2.2.0/24 and then looks in the security association database to find
the options to propose for an SA.

2) The transforms (options) are sent to the Head Office GW.  It selects
the most secure mutual option for the traffic between 2.2.2.2 and
3.3.3.3.  Oh, I see we've cut out the diagram.  I'll add it back in so
others know what I'm talking about.

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      |
           -----------------
3) Now that the Head Office GW can look into the packet, it checks its
security policy database for a security policy from 10.1.1.0/24 ->
10.2.2.0/24.  

Here's where I get lost.  Is the tunnel end point information included
in the security policy? If KLIPS first sees the security policy which
uses 1.1.1.1 and 3.3.3.3 rather than 2.2.2.2 and 3.3.3.3 (since both are
defined for traffic between 10.1.1.0/24 and 10.2.2.0/24), does it fail
immediately or does it continue to search for a security policy which
matches both internal end points and tunnel end points?
> 
> > 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.
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?
> 
> > 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.
Hmm . . . I was afraid of that.  I think that means the end of the road
for this solution.  Does anyone have an authoritative answer?
> 
> > 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? 
Alas, it is not a given that the other side will support NAT-T.

> Or if you have enough real IP space, just setup
> a second box to terminate/nat the second office?
Unfortunately (or fortunately if you are the sales person), there may be
hundreds of these scenarios.
> 
> Or can you split up the /24 in two or smaller chunks? 
No, they do not have engineering control of the other side.
> 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'.
As an ASP, I'm afraid they can't be quite so demanding of their clients.
Thanks again - John
> 
> Paul
-- 
John A. Sullivan III
Open Source Development Corporation
Financially sustainable open source development
http://www.opensourcedevel.com