Source NAT based on destination for VPN topologies ( Lan2Lan connections cisco ASA )

In a hosted vendor business application scenario,  the needs for source-NAT ( SNAT ) might exist for VPN connections within the classic lan2lan vpn concept. This scenario might  create an ip_address management  issues if all customers are using rfc1918 address.  Overlapping rfc1918 blocks could cause a collision between customers address blocks.

1st lets look at a typical vendor hosted-business-server topology

Topology

The problem

Each client LAN network address needs to be unique. Clients that are using rfc1918 addressing , has no means to delegate and ensure unique address are being used between customers. So cust1 might be using the same 192.168.1.0/24 block as cust2 or cust3, and you have no control as to what the customer may or may not be using.

If the vendor grows his business-server  environment by adding more customers, this problem could be a nightmare to manage.

So how do we ensure that each customer who access the business servers domain, are using a unique address?

The Solution 

By source NAT'ing the client machines to a public address that he/she owns, we can ensure that all customers  are unique from the vendor's hosted business server perspective. In  a true remote business-server application farm that supports multiple customer, this is how they ensure uniqueness.


In this blog, I will demo a configuration that you can use just  for this & that's typically deployed within the cisco ASA firewall.  It would allow any one of the 3 above customer to use the same local lan subnet addressing, and all client's machines would be NAT'd to a public address that they own.

This address would  than be present to all connections to the business-server domain across the vpn-tunnel.

Cust & Vendors Details


Let's say Customer1 owns a public address of "1.0.0.1".  And their local lan is 192.168.1.0/24. So customer 1 will NAT his rfc1918 space behind the  "1.0.0.1" address and present this to the business servers located  at 192.168.254.0/24 for all connections establishment.

The Vendor firewall is located at 10.1.1.1 and  requires AES128/256, DHgrp2, no PFS. They are using a PSK of "cust1psk", and will allow the customer  full access to  the 192.168.254.0/24 block.


 Cust configuration  (  Cisco ASA ipsec type L2L vpn  )


 Tunnel-group

 Crypto Ikev1 policies

 

 The Encryption ACL

NOTE: This encryption ACL will encrypt the sNAT  global outside address across the encryption domain.

 Crypto-map & Transform-set

 
 NAT-control-SourceNAT

      (1st) objects

    
     (2nd) NAT  rules for SNAT based on the destination of  192.168.254.0/24

    
To summarize this SNAT scenario;

 Ken Felix
 Freelance Network & Security Engineer
 kfelix -a--t- socpuppets ---d--o--t--- com

   ^      ^
=( *   * )=
      o 
     /  \