Duplicate remote networks and PAT - IOS VPN

Question

This question pertains to an IOS router running c3900e-universalk9-mz.SPA.152-4.M5.
We are deploying a new VPN termination router that will support multiple IPSec tunnels to multiple unrelated external organizations. We have many of these VPN routers in other regions hosting dozens of IPsec tunnels to dozens of unrelated external organizations. In the past, to allow for IPv4 uniqueness, we have suggested (required) these external organizations to PAT their source addresses to unique public addresses owned by the external organization. In some cases, my company has provided a public range of addresses to the external organization which the external organization uses to PAT their sources before presenting the traffic to our side of the VPN tunnel.
This has served us well and scales quite well.
However, we are now faced with an external organization (the very first organization on this new VPN termination router) that wants to present my company with non-unique addresses in the 10.0.0.0/8 range. This external organization has requested that we PAT their sources for them, which I understand that technically we can do.
My first question is, if my company decides to go into the business of PATing the 10/8 sources of other external organizations, how will this impact the IP network used at the remote end of the tunnel and could these remote networks be overlapping between two or more external organizations without using some flavor of VRF? I developed a scenario below that I'd like help in understanding:
interface Port-channel20.2900
description Internet Bound (Outside)
crypto map JIM                                               
ip address 130.96.10.243 255.255.255.248
ip nat inside 
interface Port-channel20.2901
*** Transit DMZ or LAN Bound (Inside)
ip nat outside
ip address 130.96.10.251 255.255.255.248 
If we had two crypto external organizations:
External Organization #1
crypto map JIM 100 ipsec-isakmp
description ***
set peer 1.1.1.1
set transform-set esp-3des-sha
set security-association lifetime seconds 28800
match address SCA
crypto isakmp key blah address 1.1.1.1
ip access-list extended SCA
permit ip host 130.96.10.92 host 130.96.10.223
access-list 7 remark *** SCA NAT List - SCA *** JMM
access-list 7 permit 10.254.0.0 0.0.255.255
ip nat pool SCA 130.96.10.223 130.96.10.223 prefix 30
ip nat inside source list 7 pool SCA overload
ip route 1.1.1.1 255.255.2552.255 130.96.10.241
ip route 10.254.0.0 255.255.0.0 130.96.10.241
External Organization #2
crypto map JIM 200 ipsec-isakmp
description ***
set peer 2.2.2.2
set transform-set esp-3des-sha
set security-association lifetime seconds 28800
match address SCB
crypto isakmp key blah address 2.2.2.2
ip access-list extended SCB
permit ip host 130.96.11.14 host 130.96.11.223
access-list 8 remark *** SCB NAT List - SCB *** JMM
access-list 8 permit 10.254.0.0 0.0.255.255
ip nat pool SCB 130.96.11.223 130.96.11.223 prefix 30
ip nat inside source list 8 pool SCB overload
ip route 2.2.2.2 255.255.2552.255 130.96.10.241
Imagine these flows are present:
Flow #
External Organization
Source
NAT Destination
Real Destination
1
1
130.96.10.92
130.96.10.223
10.254.10.10
2
2
130.96.11.14
130.96.11.223
10.254.10.10
Since our interesting traffic access-lists are based on PAT addresses, theoretically the flow could be positively associated with the crypto-map clause before PAT. Is it true that in the forward direction we have PAT, followed by routing, followed by encryption? If so, this would mean that after PAT and routing the egress interface would be the same for both flows (Port-channel20.2900) and the IP destination address would also be the same (10.254.10.10). However, the source IP address would be distinct for each flow. Since routing has already happened, isn’t the router smart enough to associate the post-PAT packet(s) with the correct crypto-map clause on the crypto-enabled interface which would be based on the access-list in the “match address” clause within the crypto-map:
ip access-list extended SCA
permit ip host 130.96.10.92 host 130.96.10.223
ip access-list extended SCB
permit ip host 130.96.11.14 host 130.96.11.223
In theory it seems this would allow duplicate IP networks at remote sites. Am I correct? If I'm wrong, where and how exactly does this fail?
Thanks,
Jim

Answer 1

Hey Nathan...
My VPN is down at the moment, but I think your going to have to manually configure all of the "clients" who are sharing the VPN to an IP range that your office uses. When you connect to your VPN, check your network prefs, and you'll see the IP addresses assigned to your VPN are similar to your network at the office. So, in a way, your sharing computer has 2 IP addresses... one from your modem or router at home, and one from the VPN server at the office. It's this 2nd IP address that allows you to appear to be on the network at the office.
So, if you can find a way to set up your shared clients the same way.... it might work. It will also be VERY helpful if your IP range at home is different from the IP range at the office....192.168... for one...and 10.0.0 for the other. (Whether traffic will pass thru your "sharing server" is a different matter altogether.)
Now, and I'm really guessing here.. if this works at all... you may be only able to access stuff from the office on your "shared clients" (ie no internet).... the way around that is to set up your VPN to allow VPN clients to pull stuff from the internet from the office thu the VPN... and for the life of me don't remember how that is done. But it will most likely be a bit slow.
I'd start with the basics... setup one client with a manual IP address/router/dns servers, and try to ping a computer at the office. If this works... at least part of your problem is solved.
With all that said... it may not work at all. Good Luck!