Ah, I think I see what you're saying.
So, you match the subnets as small as possible, and then make a NAT entry for each destination network address? For example:
My network is 10.10.1.x, 255.255.255.0.
Client A's network is 192.168.1.x, 255.255.255.0.
Client B's network is 192.168.1.x, 255.255.255.0.
So, I NAT-map, you'll have to forgive some technical misgivings here, 10.10.1.x to Client A, and perhaps, 10.10.2.x to Client B. No, that's not right. Just a moment...
Aha, is this right?:
So, I create two more subnets on my local network. Smaller the better.
So I now have 10.10.2.x and 10.10.3.x. I NAT map each of them to Client A and Client B, respectively. The VPN can now address each subnet uniquely, and NAT translation of some kind handles translating the addresses between the client and our VPN network.
Using a smaller subnet would be advisable, but for simplicity sake, this is the basic idea, yes?
The thing I don't understand is how the routing works... how am I going to be able to route information from our network, over the VPN, and be able to uniquely route traffic to two IP's with the same IP address?
I had WAY too much coffee, it's hard to concentrate!
Thanks Diego,
I was able to find on some other sites people that are trying to acheive the same thing and people replying that this can be done on the ASA side but not providing much details on how this should be acomplished.
Here is what I was able to find:
"
|
I remember the 12.4 bug thing.
You don't. I'll use 1.0.0.0/8 (even though it is now public and potentially used) as my public network and 192.168.1.0 as the overlapping networks for customer A and customer B seperately. I do a VPN between A's public and my public interface (1.1.1.1/24) and B's public interface- and I nat 192.168.1.0 coming from anything behind A to 1.2.1.0/24 and then same thing for B except I use 1.3.1.0/24 (or whatever). Then to access anything on customer A from my net I instruct my support people to use 1.2.1.0/24 and for customer B use 1.3.1.0/24. You have to build the NAT (and sometimes double NAT) so that your users never see 192.168.1.0/24 and the customer just has your net block as interesting traffic. |
As erratick says, you don't. You send your traffic towards an address that sits in your routing space. That traffic handed off to your VPN router, where it is NAT'd. So let's say I have two customers 192.168.1.0/24 and 192.168.1.0/24 I create 10.1.1.0/24 as an encryption domain (via ACL) and add individual NAT entries (in that subnet) to the first customer's addresses that I'm interested in. I create 10.1.2.0/24 as an encryption domain (via ACL) and individual NAT entires (in that subnet) to the second customer's address that I'm interested in. You may also end up in a situation where inbound traffic may need to be sourced from a loopback, within *your* routing block, that sits on customer equipment, so you can differentiate inbound traffic. This may or may not apply to you, depending on how you are creating these tunnels. I support a wide variety of architectures, and this happens fairly often. |
"
Is there anyone else that ran into the same issue like me ? How did you fixed this.
PS: I know I can do this on the AWS end but is not really what I'm looking for as I would like to have everything centralized.
Kind regards,
Alex
