Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

duplicate remote networks and PAT - IOS VPN

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

34
Views
0
Helpful
0
Replies
CreatePlease login to create content