[c-nsp] IPSEC sanity check

[Peter Rathlev]

On Sun, 2011-01-23 at 19:38 -0500, Justin M. Streiner wrote:
> 2. Create a static NAT to an unused address on their outside network and 
> use that as the tunneled host.  I have reason to believe that won't work 
> either.

That's typically what we do, and it works just fine if I understand you
correctly. You can also policy-NAT so only access towards that specific
tunnel uses this translation, falling back to some generic global
otherwise.

Assuming that Company A could use 192.0.2.240/28 and Company B is
198.51.100.0/24:

access-list PNAT_Host_01 permit ip host 10.20.30.40 198.51.100.0 255.255.255.0 
access-list PNAT_Host_02 permit ip host 192.168.1.1 198.51.100.0 255.255.255.0 
access-list PNAT_Host_03 ...
...
static (inside,outside) 192.0.2.240 access-list PNAT_Host_01
static (inside,outside) 192.0.2.241 access-list PNAT_Host_02
static ...
...
access-list All_PNAT_Hosts permit ip 192.0.2.240 255.255.255.240 198.51.100.0 255.255.255.0
crypto map IPsec_Outside 50 match address All_PNAT_Hosts
crypto map IPsec_Outside 50 ...
...

> 3. Land this VPN on Company A's external router (a Cisco 2801), rather 
> than the ASA.  That should allow them to use the NAT'd outside interface 
> on the firewall as a tunneled address without problems.  The router might 
> need a code/license upgrade to handle the IPSEC, but the more I think 
> about it, the more this seems like the least kludgey solution.

This might give you one advantage compared with 2 though; any
IPsec-related problems on the ASA (e.g. incompatibility with the other
end) that tears down the tunnel also tears down the Xlates, so even if
the tunnel could be established instantaneously again all existing
Xlates through the tunnel are dropped.

-- 
Peter