[Openswan Users] NAT based upon tunnel

[Paul Wouters]

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

> Alas, there is very little flexibility and very large numbers.

right.

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

right.

> There are potentially thousands of clients so the solution must scale to
> handle many IP address conflicts.

forget my suggestion of adding a machine then.

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

I was more thinking of a seperate ipsecX device here, eg bound to an IP
alias, as the means to 'tag' the traffic before encryption.

>> 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!):

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.

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

It will just grab the encrypted packet, check if it is valid and comes in
through proper tunnel ipsec policies, then decrypt it and put it on the cable.
If two tunnels claim to be able to send packets of soruce foo, then if a packet
with source foo arrives through one of them it is accepted. Receiving the
packets at the main office isn't the problem.

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

> As an ASP, I'm afraid they can't be quite so demanding of their clients.

:)

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.

Paul
-- 
 	"Non cogitamus, ergo nihil sumus"