IPSec S-2-S with ASA and overlapping IP-Ranges

roland.sonder · ‎02-03-2008

I do meanwhile have two customers urged to to interconnect different partner companys using the same RFC1918 address ranges as they use themself. All of the involved parties claim not beeing able to readdress their systems.

How could this situation be resolved the most efficient way ?

| Company | Partner-A

| +------+ \----------/ +------+ |

| | | / \-------+ ASA +-----+ 192.168.1.0/24

| | ASA | / \ +------+

+-----+ 5510 +------\ INTERNET /

| | VPNC | / \ +------+ | Partnet-B

| | |[=======IPsec-VPN=======]| ASA | |

| | | / \-------+ VPNC +-----+ 192.168.1.0/24

| +--+---+ \----------/ +------+ |

| |

|

[------] DMZ

| 192.168.1.0/24

|

+----+

|SRV |

+----+

Hint: for best viewing results use fixed width font.

skint · ‎02-04-2008

Hi,

What you're looking for is policy static NAT translation.

http://www.cisco.com/en/US/docs/security/asa/asa80/asdm60/user/guide/nat.html#wp1055485

You create an ACL that matches the translated network for the remote site and reference it to translate the local site. Your SA's reference the new translated ranges. Just be sure to add the static translations first.

As an example, I translated partner a to 192.168.2.0/24 and partner-b to 192.168.3.0/24.

on partner-a:

access-list to-partner-b permit ip 192.168.1.0 255.255.255.0 192.168.3.0 255.255.255.0

static (inside,outside) access-list to-partner-b

on partner-b:

access-list to-partner-a permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

static (inside,outside) access-list to-partner-a

Since NAT is performed before SA access-list matching, your ACL between partner-a and partner-b would be the following:

access-list vpn-partner-b permit ip 192.168.2.0 255.255.255.0 192.168.3.0 255.255.255.0

partner-b:

access-list vpn-partner-a permit ip 192.168.3.0 255.255.255.0 192.168.2.0 255.255.255.0

Obviously, the users will have to be trained to use 192.168.3.0 and 192.168.2.0 to access resources...

-ryan

roland.sonder · ‎02-04-2008

Hi Ryan,

Thank's for your posting.

On none of the outside interface of the firewalls involved I do have additional official spare IP-addresses left.

In my opinion the only way to cope with this is to create additional logical interfaces on the hub firewall for each of the partners. This would allow me to create NAT translations for the server on the hub site.

At the hub site for example I'd have to add additional sub-interfaces in order to translate the real servers IP-addresses into for example 192.168.10.0/24. This would then allow me to create differen crypto acl's as well as site specific NAT translation rules.

Do you believe that this could be working ?

roland

skint · ‎02-05-2008

Roland,

Just reread the post from before. With that setup there is no reason to use anymore devices or sub-interfaces. You have already committed to using a different range of IP addresses, the translations I mentioned in my post will accomplish that.

In fact, you should be able to just cut and paste the config snippets add your appropriate peers and isakmp key entries.

Here's a Cisco link:

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9950.shtml

-ryan